Open access to the Proceedings of the 15th USENIX Symposium on Networked

Systems Design and Implementation is sponsored by USENIX

zkLedger Privacy-Preserving Auditing for Distributed Ledgers

Neha Narula MIT Media Lab Willy Vasquez University of Texas at Austin Madars Virza MIT Media Lab

httpswwwusenixorgconferencensdi18presentationnarula

This paper is included in the Proceedings of the 15th USENIX Symposium on Networked

Systems Design and Implementation (NSDI rsquo18)April 9ndash11 2018 bull Renton WA USA

ISBN 978-1-939133-01-4

zkLedger Privacy-Preserving Auditing for Distributed LedgersNeha Narula

MIT Media LabWilly Vasquez

University of Texas at AustinlowastMadars Virza

MIT Media Lab

AbstractDistributed ledgers (eg blockchains) enable financial in-stitutions to efficiently reconcile cross-organization trans-actions For example banks might use a distributed ledgeras a settlement log for digital assets Unfortunately theseledgers are either entirely public to all participants re-vealing sensitive strategy and trading information or areprivate but do not support third-party auditing withoutrevealing the contents of transactions to the auditor Au-diting and financial oversight are critical to proving insti-tutions are complying with regulation

This paper presents zkLedger the first system to protectledger participantsrsquo privacy and provide fast provably cor-rect auditing Banks create digital asset transactions thatare visible only to the organizations party to the transac-tion but are publicly verifiable An auditor sends queriesto banks for example ldquoWhat is the outstanding amountof a certain digital asset on your balance sheetrdquo andgets a response and cryptographic assurance that the re-sponse is correct zkLedger has two important benefitsover previous work First zkLedger provides fast richauditing with a new proof scheme using Schnorr-type non-interactive zero-knowledge proofs Unlike zk-SNARKsour techniques do not require trusted setup and only relyon widely-used cryptographic assumptions Second zk-Ledger provides completeness it uses a columnar ledgerconstruction so that banks cannot hide transactions fromthe auditor and participants can use rolling caches toproduce and verify answers quickly We implement a dis-tributed version of zkLedger that can produce provably-correct answers to auditor queries on a ledger with ahundred thousand transactions in less than 10 millisec-onds

1 IntroductionInstitutions engage trusted third-party auditors to provethat they are complying with laws and regulation Tradi-tionally this is done by auditing companies like DeloittePricewaterhouse Coopers Ernst and Young and KPMG(known as the ldquoBig Fourrdquo) which together audit 99 of

Work completed at the MIT Media Labdagger Source code and full version of the paper zkledgerorg

the companies in the SampP 500 [19] This type of audit-ing is laborious and time-consuming so regulators andinvestors do not get real-time access to information aboutthe financial status of institutions In addition trustedthird parties can make mistakes The most well-knownexample of this is the collapse of Arthur Anderson in2002 after it failed to catch Enronrsquos $100 billion account-ing fraud

Recently financial institutions are exploring distributedledgers (or blockchains) to reduce verification and recon-ciliation costs in an environment with multiple distrustingparties Distributed ledgers enable real-time validationby all participants (known as public verifiability) but atthe cost of privacymdashevery participant must downloadall transactions in order to verify their integrity This isuntenable for institutions that rely on secrecy to protectstrategy and intellectual property (eg trading strategies)and for organizations that have to comply with laws andregulation around data privacy (for example the GeneralData Protection Regulation in Europe [24])

Distributed ledgers that support privacy generally op-erate in one of two ways either by only committing tohashes of transactions on the ledger using trusted thirdparties to independently verify transactions [22 23] orby using cryptographic commitment schemes to hide thecontent of transactions [17 42 47 51] The former classof ledgers suffers from the fact that participants can nolonger verify the integrity of private transactions elimi-nating the distributed ledger benefit The latter class stillhas public verifiability but either reveals the transactiongraph [17 42] or requires trusted setup which if compro-mised would let an adversary undetectably create newassets [47 51] None of the existing privacy-preservingdistributed ledgers offer an important property for real-world systemsmdashefficient auditing

This paper presents zkLedger the first distributedledger system to support strong transaction privacy pub-lic verifiability and practical useful auditing zkLedgerprovides strong transaction privacy an adversary cannottell who is participating in a transaction or how much isbeing transacted and crucially zkLedger does not revealthe transaction graph or linkages between transactionsThe time of transactions and the type of asset being trans-ferred are public All participants in zkLedger can still

USENIX Association 15th USENIX Symposium on Networked Systems Design and Implementation 65

zkLedger Privacy-Preserving Auditing for Distributed LedgersNeha Narula

MIT Media LabWilly Vasquez

University of Texas at AustinlowastMadars Virza

MIT Media Lab

AbstractDistributed ledgers (eg blockchains) enable financial in-stitutions to efficiently reconcile cross-organization trans-actions For example banks might use a distributed ledgeras a settlement log for digital assets Unfortunately theseledgers are either entirely public to all participants re-vealing sensitive strategy and trading information or areprivate but do not support third-party auditing withoutrevealing the contents of transactions to the auditor Au-diting and financial oversight are critical to proving insti-tutions are complying with regulation

This paper presents zkLedger the first system to protectledger participantsrsquo privacy and provide fast provably cor-rect auditing Banks create digital asset transactions thatare visible only to the organizations party to the transac-tion but are publicly verifiable An auditor sends queriesto banks for example ldquoWhat is the outstanding amountof a certain digital asset on your balance sheetrdquo andgets a response and cryptographic assurance that the re-sponse is correct zkLedger has two important benefitsover previous work First zkLedger provides fast richauditing with a new proof scheme using Schnorr-type non-interactive zero-knowledge proofs Unlike zk-SNARKsour techniques do not require trusted setup and only relyon widely-used cryptographic assumptions Second zk-Ledger provides completeness it uses a columnar ledgerconstruction so that banks cannot hide transactions fromthe auditor and participants can use rolling caches toproduce and verify answers quickly We implement a dis-tributed version of zkLedger that can produce provably-correct answers to auditor queries on a ledger with ahundred thousand transactions in less than 10 millisec-onds

1 IntroductionInstitutions engage trusted third-party auditors to provethat they are complying with laws and regulation Tradi-tionally this is done by auditing companies like DeloittePricewaterhouse Coopers Ernst and Young and KPMG(known as the ldquoBig Fourrdquo) which together audit 99 of

Work completed at the MIT Media Labdagger Source code and full version of the paper zkledgerorg

the companies in the SampP 500 [19] This type of audit-ing is laborious and time-consuming so regulators andinvestors do not get real-time access to information aboutthe financial status of institutions In addition trustedthird parties can make mistakes The most well-knownexample of this is the collapse of Arthur Anderson in2002 after it failed to catch Enronrsquos $100 billion account-ing fraud

Recently financial institutions are exploring distributedledgers (or blockchains) to reduce verification and recon-ciliation costs in an environment with multiple distrustingparties Distributed ledgers enable real-time validationby all participants (known as public verifiability) but atthe cost of privacymdashevery participant must downloadall transactions in order to verify their integrity This isuntenable for institutions that rely on secrecy to protectstrategy and intellectual property (eg trading strategies)and for organizations that have to comply with laws andregulation around data privacy (for example the GeneralData Protection Regulation in Europe [24])

Distributed ledgers that support privacy generally op-erate in one of two ways either by only committing tohashes of transactions on the ledger using trusted thirdparties to independently verify transactions [22 23] orby using cryptographic commitment schemes to hide thecontent of transactions [17 42 47 51] The former classof ledgers suffers from the fact that participants can nolonger verify the integrity of private transactions elimi-nating the distributed ledger benefit The latter class stillhas public verifiability but either reveals the transactiongraph [17 42] or requires trusted setup which if compro-mised would let an adversary undetectably create newassets [47 51] None of the existing privacy-preservingdistributed ledgers offer an important property for real-world systemsmdashefficient auditing

This paper presents zkLedger the first distributedledger system to support strong transaction privacy pub-lic verifiability and practical useful auditing zkLedgerprovides strong transaction privacy an adversary cannottell who is participating in a transaction or how much isbeing transacted and crucially zkLedger does not revealthe transaction graph or linkages between transactionsThe time of transactions and the type of asset being trans-ferred are public All participants in zkLedger can still

USENIX Association 15th USENIX Symposium on Networked Systems Design and Implementation 65

verify transactions are maintaining important financialinvariants like conservation of assets and an auditor canissue a rich set of auditing queries to the participantsand receive answers that are provably consistent with theledger zkLedger supports a useful set of auditing primi-tives including sums moving averages variance standarddeviation and ratios An auditor can use these primitivesto measure financial leverage asset illiquidity counter-party risk exposures and market concentration for thesystem as a whole or for individual participants

A set of banks might use zkLedger to construct a set-tlement log for an over-the-counter market trading digitalassets In these markets buyers and sellers are matchedvia electronic exchanges trades are frequent and fast set-tlement helps lower counterparty risk Once a trade isconfirmed a bank can initiate the transfer of the asset asa transaction in zkLedger which when accepted in theledger settles the transaction Each bank stores plain-texttransaction data in its own private datastores In zkLed-ger instead of storing plain-text transactions participantsstore value commitments on the distributed ledger Im-portantly these commitments can be homomorphicallycombined A bank can prove to an auditor how much ofan asset it has on its balance sheet by opening up the prod-uct of all transaction commitments it has referencing thatasset The auditor can confirm that the opened productis consistent with the product of the commitments on theledger

Designing zkLedger required overcoming three keychallenges

Providing privacy and auditing The first challengeis to preserve privacy while still allowing an auditor tocompute provably correct measurements over the datain the ledger zkLedger is the first system to simultane-ously achieve this by combining several cryptographicprimitives To hide values zkLedger uses Pedersen com-mitments [41] Pedersen commitments can be homomor-phically combined so a verifier can for example confirmthat the sum of the outputs is less than or equal to thesum of the inputs conserving assets More than thatan auditor can combine commitments to compute linearcombinations of values in different rows in the ledgerPrevious confidential blockchain systems also use Ped-ersen commitments to hide values but end up revealinglinkages between transactions and do not support privateauditing [17 34 42]

zkLedger uses an interactive mapreduce paradigm overthe ledger with non-interactive zero-knowledge proofs(NIZKs) to compute measurements that go beyond sumsThese are Generalized Schnorr Proofs [48] which are fastand rely only on widely accepted cryptographic assump-

tions Banks can provably recommit to functions overvalues in the ledger such as f vrarr v2 which lets theauditor compute measurements like variance skew andoutliers without revealing individual transaction details

Auditing completeness Since an auditor cannot deter-mine who was involved in which transactions zkLed-ger must ensure that during auditing a participant can-not leave out transactions to hide assets from the audi-tor We call this property completeness At the sametime we do not want to reveal to the auditor who wasinvolved in which transactions zkLedger uses a noveltable-construction in the ledger A transaction is a rowwhich includes an entry for every participant and anempty entry is indistinguishable from an entry involving atransfer of assets All of a participantrsquos transfers are in itscolumn in the ledger An auditor audits every transactionwhen auditing a participant meaning a participant can-not hide transactions This presents efficiency challengeswhich zkLedger addresses by using commitment cachesand audit tokens described below

Efficiency The third challenge is supporting all of thisefficiently zkLedger implements a number of optimiza-tions every participant and the auditor keeps commitmentcaches which are rolling products of every participantsrsquocolumn in the ledger this makes it fast to generate assetproofs and to answer audits To reduce communicationcosts zkLedger is designed so that participants do nothave to interact to construct the proofs for the transac-tion the spender can create the transaction alone (this issimilar to how other blockchain systems work) But amalicious spender could try to encode incorrect values inthe commitments for other banksmdashwe must ensure all ofthe commitments and proofs are correct and that everyparticipant has what they need to later respond to an auditTo do this we designed a set of proofs that everyone canpublicly verifymdashtransactions with incorrect proofs will beignored These proofs ensure that every participant has anaudit token which they can use to later open up commit-ments for that row and that all proofs and commitmentsare consistent The audit token and the consistency proofsare publicly verifiable but do not leak any transactioninformation They are also non-interactive so zkLedgermakes progress even if banks cannot communicate andthey are encoded for a specific bank so a token for onebank cannot be used by another bank to lie to the auditor

The slowest part of transaction creation and validationare range proofs which ensure that an assetrsquos value is ina pre-specified range and prevent a malicious attackerfrom undetectably creating new assets Range proofs are10times the size of the other proofs and take 5times as muchtime to prove and verify A naive implementation of

66 15th USENIX Symposium on Networked Systems Design and Implementation USENIX Association

zkLedger might require multiple range proofs but byusing disjunctive proofs we can multiplex different valuesinto one range proof per entry

In summary the contributions of this paper are

bull zkLedger the first distributed ledger system to achievestrong privacy and complete auditing

bull a design combining fast well-understood cryptographicprimitives using audit tokens and mapreduce to com-pute provably correct answers to queries

bull an evaluation of zkLedger showing efficient transactioncreation and auditing and

bull an analysis of the types of queries zkLedger can supportsuggesting that zkLedger can efficiently handle a usefulset of auditing measurements

2 Related WorkzkLedger is related to work in auditing or computing onprivate data and privacy-preserving blockchains zkLed-ger achieves fast provably correct auditing by creatinga new distributed ledger table model and applying a newscheme using zero-knowledge proofs

21 Computing on Private DataPrevious work proposed a multi-party computationscheme in which participants use a secure protocol tocompute the results of functions which answer questionsabout systemic financial risk the same problem which zk-Ledger aims to address [3 10] and network security [14]This work provides privacy benefits over existing analyt-ics systems by allowing participants to keep their datasecret However it only supports overall system auditingit is not a solution to audit individual participants Thereis also nothing preventing participants from lying in theinputs to the multi-party computation they do not achievecompleteness

Provisions [21] is a way for Bitcoin exchanges to provethey are solvent without revealing their total holdingsProvisions uses Proof of Assets and Proof of Liabilitieswhich are very similar to the zero-knowledge proofs weuse in zkLedger However in Provisions an exchangecould ldquoborrowrdquo private keys from another Bitcoin holderand thus prove assets they do not actually hold in factmultiple exchanges could share the same assets More-over Provisions does not provide completeness By usinga columnar construction with a distributed ledger zkLed-ger achieves completeness

In Prio [18] untrusted servers can compute privatelyon mobile client data Prio does not operate on distributedledgers and thus does not guarantee public verifiability

Prio requires all servers to cooperate in order for clientproofs to validate zkLedger can tolerate non-cooperatingparticipants

Several systems provide private and correct computingusing trusted hardware [4ndash6 49 52] In our setting wecannot guarantee that all participants will trust the samehardware provider In addition it would be a conflictof interest to use such a system to audit the companyproviding the trusted hardware

There are many systems which compute on encrypteddata to protect user confidentiality in the event of a servercompromise [25 31 32 40 43 44 50] These systemsaddress a different problem than what zkLedger is tryingto solve Instead we provide interactive provably correctauditing over private data generated by many parties

22 Privacy-preserving blockchainsBitcoin a decentralized cryptocurrency released in 2009was the first blockchain [37] Many companies have ex-plored using a blockchain to record the transfer of assetsThese systems are marked by the following characteris-tics (1) Multiple possibly distrusting participants allwith write permissions and no single point of failure orcontrol (2) A consensus protocol to construct an append-only globally ordered log with a chain of hashes to pre-vent tampering with the past and (3) Digitally signedtransactions to indicate intent to transfer ownership

In Bitcoin and most other blockchains all transactionsare public every participant receives each transactionand can verify all the details Users create pseudonymsby generating one-time use public keys for payment ad-dresses but transaction amounts and the links betweentransactions are still globally visible Confidential Trans-actions [34] and Confidential Assets [17 42] are exten-sions to Bitcoin which blind the assets and amounts intransactions while still ensuring that all participants canvalidate transactions Though these systems hide assetsand amounts they leak the transaction graph and do notsupport private auditingmdashan auditor would require ac-cess to all plain-text transactions in order to ensure com-pleteness The transaction graph alone leaks substantialinformation [36 38 45 46] for example the FBI fol-lowed linked transactions to trace bitcoins and used thisas evidence in court [28] zkLedger provides strongertransaction privacy and private auditing but at the costof scalability Transactions in zkLedger are sized orderthe number of participants in the whole system requiringmore time to produce and verify as the number of par-ticipants grows This makes zkLedger more suitable toledgers with fewer participants who require more privacy

Solidus [16] is a distributed ledger system that usesOblivious RAM to hide the transaction graph and trans-

USENIX Association 15th USENIX Symposium on Networked Systems Design and Implementation 67

action amount between bank customers While this con-struction also provides private transactions Solidus canonly support auditing by revealing all of the keys used inthe system to an auditor and opening transactions zk-Ledger achieves performance similar to Solidus whileproviding private auditing

R3rsquos Corda [22] and Digital Asset Holdingrsquos GlobalSynchronization Log (GSL) [23] are distributed ledgersgeared towards financial institutions that rely on trustedthird parties to pass through information In Corda no-taries verify transactions and maintain privacy of partici-pants while GSL segments its ledger only storing a hashof the values globally and limiting access to fine-grainedtransaction data Neither support private auditing

Another approach is that of Zerocash [47] and its re-lated implementation Zcash [51] an anonymous cryp-tocurrency based on Bitcoin Zerocash uses zk-SNARKs[7] to hide transaction amounts participants and thetransaction graph The zk-SNARKs as used in Zcashcan be extended to handle policies to enforce regulationsKYCAML laws and taxes [27] These policies do notsupport arbitrary queries but instead put limits on thenew types of transactions that can take place These ideashave not yet been implemented in a practical system

zk-SNARKs are quite efficient for some statementsbut unfortunately the price of this efficiency is paid insetup assumptions as of now all concretely efficientzk-SNARKs require a trusted third party for setup Theconsequences of incorrect or compromised setup are po-tentially disastrous an adversary who can learn the secretrandomness used during setup can make fraudulent proofsof false statements that are indistinguishable from proofsof true statements In our setting (international bank-ing) such proofs would permit unrestricted creation ordestruction of financial assets or liabilities There maynot even be a viable party to perform the one-time trustedsetup For example Russia might not trust the FederalReserve or the European Central Bank or it might notbe politically expedient to be seen as doing so While itis possible to mitigate this concern eg by distributingthe setup between multiple parties [8 11 12] this processis onerous and expensive Ideally the financial integrityof the system would not rely on trusted setup at all Wechoose to base consensus-critical portions of zkLedgerrsquosdesign on standard NIZKs

3 zkLedger Overview31 Architecture

System participants There are n participants which wecall banks that issue transactions to transfer digital assetsBank1 Bankn and an auditor Auditor that verifies

certain operational aspects of transactions performed bythe banks (eg ldquois a particular bank Banki solventrdquo)These roles are not distinct a bank could also audit ADepositor or set of Depositors can issue and withdrawassets from the system for example the European Cen-tral Bank might issue 1M C to Banki in the system Is-suance and withdrawal of all assets are controlled by theDepositors and are global public events

Transactions Banks exchange assets by creating trans-fer transactions whose details are hidden A transfertransaction captures an event where Banki is transferringv shares of asset t to Bank j Our scheme supports a banktransferring to multiple other banks but for simplicity weassume there is one spending and one receiving bank ineach transaction Banks determine the details of a trans-fer transaction outside of zkLedger perhaps through anexchange We assume they use encrypted channels

Append-only ledger Banks submit transactions to anappend-only ledger which globally orders all valid trans-actions If a digital asset only exists on the ledger thentransfer on the ledger is change in legal custody of the dig-ital assets not merely a record of ownership change andan Auditor is guaranteed a Bank is not hiding assets Thisledger could be maintained by a trusted third party by thebanks themselves or via a blockchain like Ethereum orBitcoin Maintaining a fault-tolerant globally ordered logis outside the scope of this paper but can be done usingstandard techniques [15 30 39]

32 Cryptographic building blocks

Commitment schemes To protect their privacy partici-pant banks do not broadcast payment details such as thetransaction amount in plain Instead the banks post hid-ing commitments to the append-only ledger in particularzkLedger uses Pedersen commitments [41] Let G be acyclic group with s = |G| elements and let g and h be tworandom generators of G Then a Pedersen commitment toan integer v isin 01 sminus1 is formed as follows pickcommitment randomness r and return the commitmentcm = COMM(vr) = gvhr

Pedersen commitments are perfectly hiding the com-mitment cm reveals nothing about the committed value vIn a similar way the commitments are also computation-ally binding if an adversary can open a commitment cmin two different ways (for the same r two different valuesv and vprime) then the same adversary can be used to computelogh(g) and thus break the discrete logarithm problem inG In zkLedger we choose G to be the group of points onthe elliptic curve secp256k1

A very useful property of Pedersen commitments isthat they are additively homomorphic If cm1 and cm2 are

68 15th USENIX Symposium on Networked Systems Design and Implementation USENIX Association

Use Commitment 13Cache to prove answer13

013 $13113 euro13213 $13

TX DB13

Commitment Cache13

Bank of America13

130558 2171813

130559 2171813

130601 2171813

Add transaction13Notify of new transaction13

Determine 13trade 13

details13

Commitment Cache13

Auditor13

Notify of new transaction13

TX DB13

Commitment Cache13

JPMorgan13

Respond to Audit13 Audit13

Use Commitment 13Cache to verify audit13

Bank of America13 Goldman Sachs13 JP Morgan13

transaction commitments and proofs13

Figure 1 Overall zkLed-ger system design showingthe interactions between thethree main entities (banksauditor and the sharedledger) in our system Eachbank maintains private stateconsisting of the transactiondatabase for transactions thebank originated and thebankrsquos secret key

two commitments to values v1 and v2 using commitmentrandomness r1 and r2 respectively then cm = cm1 middotcm2is a commitment to v1 + v2 using randomness r1 + r2 ascm=(gv1hr1) middot(gv2hr2)= gv1+v2 hr1+r2 To speed up trans-action generation and auditing zkLedger makes extensiveuse of the ability to additively combine commitments

Public-key encryption Every bank i also generates aSchnorr signature keypair keypair consisting of a secretkey ski and public key pki = hski and distributes thepublic key pki to all other system participants

Non-interactive zero-knowledge proofs To makeprivacy-preserving assertions about payment details zk-Ledger relies on non-interactive zero-knowledge proofs(NIZKs) [9] In brief zero-knowledge proofs concerntwo parties the prover who holds some private data andthe verifier who wishes to be convinced of some propertyabout this private data For example the prover mightknow the opening of a commitment cm and wish to con-vince the verifier that the committed value v is in somerange eg 0 le v lt 106 Using NIZKs the prover canproduce a binary string π the proof that simultaneouslypersuades the verifier yet does not reveal anything elseabout v Verifying π does not require any interactionbetween the prover and the verifier and the prover canappend π to the ledger where it can be verified by anyparty of the system

In theory NIZK proof systems exist for all propertiesin NP whereas the practical feasibility of NIZKs is highly-dependent on the complexity of the property at hand Inparticular algebraic properties in cyclic groups such asknowledge of discrete logarithm equality of values com-mitted in Pedersen commitments or similar have veryefficient NIZK proof systems The design of zkLedger iscarefully structured so that all NIZK proofs have particu-larly efficient constructions

33 Security GoalsThe goals of zkLedger are to hide the amounts partici-pants and links between transactions while maintaining averifiable transaction ledger and for the Auditor to receivereliable answers to its queries Specifically zkLedger letsbanks issue hidden transfer transactions which are stillpublicly verifiable by all other participants every partici-pant can confirm a transaction conserves assets and assetsare only transferred with the spending bankrsquos authorityFor example if Banki transfers 10000 C to Bank j boththe banks and amount are hidden The asset (C) and timeof the transaction are not hidden zkLedger also hides thetransaction graph meaning which previous transaction(s)supplied the 10000 C to Banki in the first place

An Auditor can query a Bank about its contents on theledger for example ldquoHow many euros does Bank j holdrdquoA bank should be able to produce commitments whichwill convince the auditor that the bankrsquos answer to theauditing query is correct meaning consistent with thetransactions on the ledger zkLedger ensures that if a bankgives the Auditor an answer that is inconsistent with theledger the Auditor will catch such attempt of cheatingwith high probability (and of course a trustworthy answermust always be accepted)

34 Threat modelzkLedger does not assume that banks will behavehonestlymdashthey can attempt to steal assets hide assetsmanipulate their account balances or lie to auditors Weassume banks can arbitrarily collude zkLedger keeps theamounts and participants of transactions private as longas neither the spender nor receiver in a transaction colludewith an observer like the Auditor We assume that theledger does not omit transactions and is available zkLed-ger does not protect against an adversary who observestraffic on the network for example if only two banksare exchanging messages itrsquos reasonable to assume thetransactions in the ledger involve those banks Nothing

USENIX Association 15th USENIX Symposium on Networked Systems Design and Implementation 69

beyond what is necessarily leaked by an audit is revealedHowever frequent auditing might reveal transaction con-tents eg if an auditor asks for banksrsquo assets after everytransaction

4 DesignThe challenge in creating zkLedger is to practically sup-port complete confidential auditingmdashan Auditor shouldnot be able to see individual bank transactions but a Bankshould not be able to hide assets from the Auditor dur-ing an audit and the auditor should be able to detect anincorrect answer

Figure 1 shows a general overview of zkLedger Thereare banks which determine transactions out of band andthen settle them by appending transactions to the ledgerThe ledger makes sure all banks and any auditors seenew transactions Each bank and auditor maintains acommitment cache which are commitments to summedvalues used to make creating transactions and respondingto audits faster Each bank also has private stores of plain-text transaction data

The rest of this section describes the zkLedger trans-action format how banks create transactions and how abank can answer a simple query from the auditor

41 TransactionsThe ledger in zkLedger is a table where transactions cor-respond to rows and Banks correspond to columns Eachtransaction has an entry for each Bank Figure 2 shows aledger with n banks Each entry in a transaction includesa commitment to a value which is the amount of the assetthat is being debited or credited to the bank For exam-ple if Banki wants to transfer 100 shares of an asset toBank j irsquos entry in the transaction would contain a com-mitment to -100 and jrsquos would contain a commitment to100 All other entries in the transaction would containcommitments to 0 since none of the other bank balanceswere changed This scheme has the nice property thatan outside observer can look at a bankrsquos entire columnand know that this represents the entirety of the bankrsquosholdings

Hiding amounts As described in sect32 zkLedger doesnot include the value in plain-text in the transaction In-stead zkLedger uses Pedersen commitments to committo the value in transfer transactions This makes valuecommitments completely indistinguishablemdashan outsideobserver cannot tell the difference between a commitmentto a positive value a negative value or 0 Recall that acommitment to a value v is cm = COMM(vr) = gvhrIf desired a prover can reveal v and r to a verifier whoknows cm and the verifier can confirm this is consistent

Since a transaction in zkLedger contains an entry forevery Bank there is a size-n vector ~cm committing tovalues in ~v Each commitment cmk uses a fresh com-mitment randomness rk Most of the entries will containcommitments to 0 for banks that are not involved with thetransaction but this is not apparent to an outside observer

zkLedger maintains the following financial invariants

bull A transfer transaction cannot create or destroy assets

bull The spending bank must give consent to the transferand must actually own enough of the particular asset toexecute this transaction

In a public blockchain the validators could simplyconfirm that these things are true by looking at the historyof transactions and the current transaction and makingsure the spending bank has the funds to spend Howeverin zkLedger these values are not public Instead wecreate a set of proofs that the spender can create to provethe invariants are maintained The spender can createa transaction without interacting with any of the otherbanks

First zkLedger introduces a Proof of Balance (πB)This is a proof that the transaction conserves assets noassets are created or destroyed (of course public is-suance and withdrawal transactions do not have suchproofs) More formally the committed values shouldsatisfy sum

nk=1 vk = 0 To prove this the prover chooses the

rk carefully it should also be the case that sumnk=1 rk = 0

If this is true and the values also sum to 0 then the ver-ifier can check to make sure that prod

nk=1 cmk = 1 for the

commitments in the rowNext zkLedger must ensure that the spending bank

actually has the assets to transfer To do this zkLedger in-troduces a Proof of Assets (πA) Other privacy-preservingblockchain systems use Unspent Transaction Outputsor UTXOs to show proof of assets and prevent doublespending For example if Alice wants to send a coin toBob she chooses one of her coins creates a new trans-action addressing the coin to Bob and includes a pointerto the previous transaction where she received the coinThis previous transaction is an output All of the valida-tors in the system maintain the invariant that outputs canonly be spent once Unfortunately in systems without zk-SNARKs this leaks the transaction graph In zkLedger abank proves it has assets by creating a commitment to thesum of the values for the asset in its column includingthis transaction If the sum is greater than or equal to 0then the bank has assets to transfer Note that this is truesince the bankrsquos column represents all the assets it hasreceived or spent and the Pedersen commitments can behomomorphically added in columns as well as in rows In

70 15th USENIX Symposium on Networked Systems Design and Implementation USENIX Association

order to produce a proof with the correct sum the bankmust have seen every previous transaction This impliesthat banks must create transactions serially In its ownentry where the value is negative the bank includes proofof knowledge of secret key to show that it authorized thetransaction This requires creating a disjunctive proofmdasheither the committed value for entry i has vi ge 0 or thecreator of the transaction knows the secret key for Banki

Range proofs Because commitment values are in anelliptic curve group and rely on modulus we need to makesure that the commited values are within an acceptablerange To see why note that if N is the order of thegroup then COMM(vr) = COMM(v+Nr) there is noway to distinguish between the two Without a checkto make sure the commited value is within the range[0N minus 1] a malicious bank could undetectably createassets To address this we use range proofs as describedin Confidential Assets [42] which uses Borromean ringsignatures [35] zkLedger supports asset value amountsup to a trillion Range proofs are the most expensivepart of the transaction as described our scheme requirestwo range proofsmdashone for the commitment value andanother for the sum of assets in the column We cansquash the two range proofs down to one range proof byintroducing an auxiliary commitment cmprimei cmprimei is eithera re-commitment to the value in cmi or the sum of thevalues in the column up to row m sum

mk=0 vk which can be

achieved by computing the product of the commitmentsin the column prod

mk=0 cmk Then we can do one range

proof on the value in cmprimei Either this is the spendingbank in which case cmprimei must be a commitment to thesum or it is another bank which is receiving funds or notinvolved in which case cmprimei could be either (and it doesnot matter which it is)

This satisfies the financial invariants described aboveHowever a particular design choice we made in zkLedgeris that a spending bank can create a transaction spendingits own assets without interacting with other banks Thismeans that a malicious bank could create transactionswhich maintain financial invariants but are ill-formed Wewill address this problem after describing how auditingworks

Once created a bank broadcasts the transaction andit will be appended to the ledger If the banks are main-taining the ledger each bank is responsible for validatingthe transaction before accepting it to the ledger If a thirdparty is maintaining the ledger then the third party shouldverify the proofs in a transaction before accepting it

Example transaction Figure 2 shows a transactionwhere Bank of America is transferring one million eurosto Goldman Sachs Bank of America creates the transfer

transaction publishing the transaction id timestamp andasset type (euros) publicly Bank of America commits tothe amount deducted from its own assets minus1000000in its own entry and 1000000 in Goldman Sachsrsquos en-try For every other bank Bank of America commits to0 This serves to hide the banks involved in the transferno one except Bank of America can distinguish betweenthe commitments to determine which are commiting tononzero values Bank of America then broadcasts thetransaction to the ledger The ledger maintainer validatesthe transaction and appends it to the ledger Once ac-cepted to the ledger this serves as a complete transferof 1000000 euros from Bank of America to GoldmanSachs

42 Auditing ProtocolThe Auditor has a copy of the ledger and interacts withthe banks to calculate functions on their private data inorder to get a view of the financial system represented bythe ledger

The Auditor audits Banki by issuing a query to Bankifor example ldquoHow many euros do you hold at time trdquoBanki responds to the auditor with an answer and a proofthat the answer is consistent with the transactions on theledger The Auditor multiplies the commitments on theledger in Bankirsquos column for euros and verifies the proofand answer with the total This is a commitment to thethe total amount of euros Banki holds

The key insight here is that given this table constructionthe Auditor can read bank irsquos column and know that itis seeing every asset transfer involving i There is noway for i to ldquohiderdquo assets on the ledger without actuallytransferring assets and giving control to another bank Incontrast during a traditional audit a bank could simplynot show the auditor some of its balance sheet

Banks could collude to hold assets for each other tem-porarily for example Bank j might transfer assets toBanki and take them back later For that time periodthe assets would be part of Bankirsquos holdings But bankscannot collude after an Auditor poses a query becausethe Auditor has already specified the time t at which thequery applies Any transfer would necessarily have to beafter t So at this point it is too late for a malicious bankto create a new transaction transferring assets to anotherbank

As described above a bank can create a transactiontransferring its own assets without any interaction Thisis common with most blockchain systems where onlythe signature of the sender is required to create a validtransaction There is no in-protocol way for a receiver toobject to a transfer Given our table construction everybank is affected by every transaction because a bank must

USENIX Association 15th USENIX Symposium on Networked Systems Design and Implementation 71

Metadata Bank1 Bank2 Bank3 BanknID Asset Time (Bank of America) (Goldman Sachs) (JPMorgan) (Citigroup)

1 e 130601 COMM(minus106r1) COMM(106r2) COMM(0r3) middot middot middot COMM(0rn)21718 Token1 Token2 Token2 middot middot middot Tokenn

πA1 π

B1 π

C1 πA

2 πB2 π

C2 πA

3 πB3 π

C3 middot middot middot πA

n πBn π

Cn

Figure 2 Contents of the ledger pertaining to a transaction that sends 106 euros from Bank1 to Bank2 Note that while asset type (euro) is visibleas part of the metadata the transaction amount (106 e) and participating institutions (Bank of America and Goldman Sachs) remain private Weuse Pedersen commitments so the commitment part of the row has values gminus106

hr1 g106hr2 and hr3 hrn Similarly audit tokens pictured

have values (pk1)r1 (pk2)

r2 For each bank Banki the corresponding column also includes proof-of-assets πAi proof-of-balance πB

i andproof-of-consistency πC

i

total all of the commitments in its column to respond tothe Auditormdasheven commitments for transactions in whichit was not involved A malicious Banki could create atransaction and not inform the another Bank j of the r jused in its entry even if it is not transferring assets toBank j Bank j would be unable to respond to the Auditorbecause it would not be able to open up the product of thecommitments in its column

In order to prove the integrity of a transfer transactionzkLedger must ensure an additional invariant

bull All banks have enough information in the transactionto open up commitments for the Auditor

zkLedger does this by requiring the spending bank toinclude a publicly verifiable Token in every entry Thisis defined as Tokenk = (pkk)

rk Bankk uses this token toopen up the product of its commitments for the Auditorwithout needing to know rkUsing audit tokens Consider a query for a sum of valuesin a bankrsquos column One way of answering this querywould be to reveal sumvk and sumrk Then the auditor wouldsimply check that these plain values are consistent withthe homomorphically computed value prodcmk = gsumvk hsumrk

However a bank does not necessarily know all thecommitment randomnesses rk (in particular these valuesare unknown for any transaction that the bank was notparty to) so the naive approach does not work

One approach could be to ask the preparer of the trans-action (ie the sender) to encrypt rk so that the non-participating bank Bankk can decrypt it To prevent thesending bank from placing a ldquogarbagerdquo ciphertext on theledger (and thus making Bankk fail the auditorrsquos queries)one would need a zero-knowledge proof of consistencybetween the encrypted value and the commitment Con-structing a concretely efficient proof for this statement isnon-trivial in a nutshell standard encryption schemes(eg ElGamal) embed plain-text in a group element whilePedersen commitments would have this value in the expo-nent

Our insight is that Bankk does not need to open sumrkto prove that sumvk is correct Instead suppose that Bankk

wants to claim that s = gsumvk hsumrk opens up to a valuesumvk To do so the bank computes sprime = sgsumvk = hsumrk andt = prodk Tokenk = hsksumrk Note that the auditor can alsocompute the values of sprime and t from the ledger and theclaimed answer sumvk

It suffices for the bank to prove that logsprime t = logh pkObserve that both logarithms evaluate to sk so a bank canproduce this proof without knowing sumri Moreover ifthis equation holds then t1sk = sprime = sgsumv but if the sumvwas incorrect then knowledge of sk would reveal a linearrelationship between g and h which is ruled out by oursecurity assumption

To show that the r in the Tokenk is the same as ther in rk we require an additional Proof of Consistency(πC) This is a zero-knowledge proof asserting that foreach k the value rk used to form cmk and Tokenk is thesame (See Appendix B for details of how such proof isconstructed)

Note that audit tokens are only useful to the bank open-ing its commitment though public a malicious bankcannot use another bankrsquos Token to successfully open anincorrect result or learn information about other bankrsquostransactions

43 Final transaction constructionFor a transfer transaction in row m each entry i containsthe following itemsbull Commitment (cmi) (gvihri) a Pedersen commitment

to the value we are transferringbull Audit Token (Tokeni) (pki)

ri This is used to answeraudits without knowing the randomness used in thecommitment

bull Proof of Balance (πB) a zero-knowledge proof assert-ing that the committed values satisfy sum

nk=1 vk = 0

bull Proof of Assets (πA) a new commitment cmprimei corre-sponding token Tokenprimei and a zero-knowledge proofasserting that either cmprimei is a re-commitment of thevalue in cmi or a recommitment to the sum of the val-ues in prod

mj=0 cm j and cmprimei is in range [0240) If the

committed value in cmi is negative the proof assertsbank i consented to the transfer

72 15th USENIX Symposium on Networked Systems Design and Implementation USENIX Association

bull Proof of Consistency (πC) two zero-knowledgeproofs asserting the randomness used in cmi and Tokeniare the same and the randomness used in cmprimei andTokenprimei are the same This is to prevent a maliciousbank from adding data to the ledger that would stopanother bank from being able to open its commitmentsfor the AuditorTransactions may contain additional metadata in plain-

text or not For example banks might want to includeencrypted account numbers addresses or identifying in-formation on behalf of a customer to satisfy the TravelRule specified in the Bank Secrecy Act of 1970 [1] zk-Ledger supports auditing over metadata in the transactionas well but it does not have a way to publicly verifyadditional metadata

44 Adding or removing bankszkLedger can support dynamically adding or removingbanks if done so publicly The participants (or anotherauthority) append a signed transaction to the ledger indi-cating which banks and thus columns should be addedor removed For example to add a new bank to theledger shown in Figure 2 the involved banks would ap-pend a transaction to the ledger indicating an intent toadd Bankn+1 From that point forward all transactionsshould contain n+ 1 entries The Proof of Assets forBankn+1rsquos entry in each transaction will start at the rowwhere Bankn+1 was added Similarly if a bank is re-moved later transactions should not include entries forthat bank Since all participants can see which bankswere added or removed they can adjust their proofs andverifications accordingly

45 OptimizationszkLedger employs several optimizations to make produc-ing and verifying these proofs faster and to support fasterauditing First caching the product of the commitmentsin a bankrsquos column improves auditing and proof creationspeed Each bank stores a rolling product of commitmentsby row and by asset so that it can quickly produce proofsof assets and answer queries from auditors Using thesecaches a bank can quickly answer an auditorrsquos query ona subset of rows in the ledger

Most transactions in zkLedger do not include everybank Every bank can pre-generate many range proofsfor the value 0 We speedup transaction throughput byparallelizing range proof generation and validation

5 AuditingAuditing is a critical component of the financial systemand regulators use various techniques to measure systemicfinancial risk Through the use of sums means ratios

variance co-variance and standard deviation an auditorin zkLedger can determine the following among othermeasurementsbull Leverage ratios zkLedger can show how much of an

asset a bank has on its books compared to its otherholdings This is helpful to estimate counterparty risk

bull Concentration Regulators use a measure called theHerfindahl-Hirschman Index (HHI) to measure howcompetitive an industry is [29]

bull Real-time price indexes Auditors can get a sense ofthe price of assets that are traded over-the-counter andthus not tracked through exchangesNatively zkLedger supports sums which means linear

combinations of values stored in the ledger This comesfrom the additive structure of Pedersen commitmentsBut zkLedger also supports a more general query modelwhich can be considered in two parts A map step and areduce stepBasic auditing Consider the basic example where anauditor wants to determine how much of an asset a bankhas on its books As described in sect42 the auditor willfilter the rows by asset multiply the entries in the bankrsquoscolumn and then ask the bank to open the commitmentproduct This only requires one round of communica-tion between the auditor and the bank and the messagesare a constant size independent of the number of rowsBecause of zkLedgerrsquos commitment caches this is veryfastMapreduce An auditor can issue more complex queriesthat might require the exchange of more data or mightrequire the participants to look at most of the rows in theledger Letrsquos consider an auditor which wants to know themean transaction size for a given bank and asset An au-ditor cannot verify a bankrsquos answer by simply totaling thebankrsquos column of commitments and dividing the openedvalue by the number of rows because such a computationwould have an incorrect denominator Namely when thebank is not involved in a transaction its column in therow will be commitment to 0 and should be discountedIn order to determine the correct denominator the auditorand the bank run the following protocol1 Filter The bank will filter the rows by asset2 Produce new commitments For each row the bank

will commit to a single bit b 1 or 0 depending on ifthe bank was involved in the transaction or not and cre-ate a proof that the bank has done this recommitmentcorrectly Crucially the auditor cannot distinguishbetween these commitments and so the bankrsquos trans-actions are not revealed We call this act of producingnew commitments the map step The map step alsorequires producing proofs that the new values were

USENIX Association 15th USENIX Symposium on Networked Systems Design and Implementation 73

correctly computed in our example for each transac-tion the bank would produce a NIZK proof that b = 1if and only if the transaction value was not equal to 0

3 Compute number of non-zero transactions Thebank computes the homomorphic sum of the new com-mitments to bits~b and opens it to reveal how manytransactions were non-zero This is the reduce stepThis is the correct denominator to compute the meantransaction size The auditor cannot tell anything aboutthe values in~b beyond what is revealed by the sum

4 Respond to auditor The bank then sends the auditorthe sum of the values in its column the vector of bitcommitments and corresponding NIZK proofs thenumber of its non-zero transactions n and the sum ofthe r values in the commitments

5 Verification The auditor verifies the map step byverifying the commitments were done correctly andverifies the reduce step and the number of non-zerotransactions by confirming that the product of the vec-tor of bit commitments is gnhsum

Nk=1 rk

6 Compute answer The auditor computes the meanfrom the sum of the bankrsquos column and the number ofnon-zero transactionsAn auditor could ask a bank for outlier transactions

using a similar technique For each row the bank willcommit to a bit b where b = 1 if a transactionrsquos value forthat bank is outside a specified range As when computingthe mean the auditor can verify these commitments wereproduced correctly and obtain the sum The bank can thenopen only the transactions where b = 1 and the auditorknows exactly how many transactions should be opened

More complex auditing queries require multiple mapand reduce computations For example here is howan auditor can learn the variance of transaction valuesv1 vN

1 Compute the average transaction value Executethe protocol described above to compute the numberof non-zero transactions n and their average value v

2 Apply the squaring map For each entry vi in its rowthe bank produces a fresh commitment cmprimei to v2

i andsends these commitments to the auditor The bank alsosupplies NIZK proofs that the value hidden in eachcmprimei is exactly the square of the value vi committed toon the ledger

3 Apply the reduce step The auditor computes theproduct of the commitments cmprimei and the bank opensup this commitment as V = v2

1 + middot middot middot+ v2N by revealing

R = sumNi=1 ri The auditor confirms that the product of

the commitments is equal to gV hR

The auditor now computes the variance σ as followsσ2 = 1

n sumvi 6=0(viminus v)2 = 1nV minus v2

We note that whereas the square mapping used abovecorresponds to the second moment (variance) zkLedgercan also compute higher statistical moments (eg skew-ness and kurtosis) using similar techniques and usingcubing and fourth power mappings respectively See Ap-pendix A for a list of measurements zkLedger supports

zkLedger can support limited information release byusing more complex reduce mappings For example in-stead of releasing the sum of values the bank can producea commitment to the rounded sum of values (eg to thefirst two decimal places) and use range proofs also im-plemented in zkLedger to show that the rounding wasdone correctly Revealing just the order of magnitude ofthe quantity at hand lets the parties balance the granularityof information disclosure6 ImplementationTo evaluate zkLedgerrsquos design we implemented a pro-totype of zkLedger in Go Our prototype uses a modi-fied version of the btcec library [2] that contains the pa-rameters and methods to compute with the elliptic curvesecp256k1 We use Gorsquos built-in SHA-256 implementa-tion for our cryptographic hash function and determin-istically pick g and h by applying point decompressionto the ldquonothing-up-my-sleeverdquo strings SHA256(0) andSHA256(1) Our prototype consists of approximately3200 lines of code of which 40 implement crypto-graphic tools used by zkLedger (zero-knowledge proofsrange proofs etc)

The implementation of the curve in zkLedger uses GorsquosbigInt type which we make no effort to compress orserialize in an efficient way A more optimized imple-mentation could compress curve points Our range proofsimplement the protocol used in Confidential Assets [42]Our NIZKs are based on Generalized Schnorr Proofswhich are three move interactive protocols to make themnon-interactive we apply the Fiat-Shamir heuristic [26]where we instantiate the random oracle using the SHA-256 hash function Our prototype implementation doesnot implement the complex queries described in sect5 andthus we do not evaluate them in sect7

7 EvaluationOur evaluation answers the following questionsbull How expensive is it to store prove and verify the differ-

ent proofs in zkLedger (sect72)bull How does auditing scale with the size of the ledger

(sect73)bull How does zkLedger scale with the number of banks

(sect74)

74 15th USENIX Symposium on Networked Systems Design and Implementation USENIX Association

Component Create Verify Size

2k Commitment 05 ms 05 ms 64 B2k Consistency 07 ms 08 ms 224 Bk Disjunctive 09 ms 09 ms 288 Bk Range 47 ms 35 ms 3936 B

Table 1 Number of each proof component in a transaction for k banksSize of and time to create and verify the components with 12 cores Therange proof create and verify benefit from the additional cores

71 Experimental setup

Microbenchmarks We run microbenchmarks on a 12core Intel machine with i7-X980 333 GHz CPUs and24GB of RAM running 64-bit Linux 440 on Ubuntu16043 Each microbenchmark runs the same code aBank runs to create and validate transactions

Distributed experiment We run the distributed experi-ments on a set of 12 virtual machines each with 4 cores ofIntel Xeon E5-2640 25 GHz processors 24GB of RAMand the same software setup as above There is one au-ditor one server providing the service of the ledger anda varying number of banks one per server Servers com-municate using the netrpc Go package over TCP Allexperiments use Go version 19

72 Proof overhead in zkLedgerTable 1 shows the time to prove and verify the proofs in atransaction in zkLedger There are two commitments twoconsistency proofs and one each of the disjunctive andrange proofs in a transaction entry There is a transactionentry per Bank Table 1 also shows the sizes of the variousproofs in bytes These sizes are estimated based on thesize of the underlying fields in the struct in memorythese proofs could be further compressed Range proofsdominate the size of the transactions

The left graph in Figure 3 shows the time it takes tocreate and verify a transaction varying the number ofoverall banks which increases the number of entries pertransaction This indicates that as we increase the numberof banks both transaction creation and verification timesper bank increase linearly but parallelization helps Prov-ing and validating range proofs dominates transactioncreation and verification but this cost is also highly paral-lelizable 12 cores gives a 28times speedup when creating atransaction with 20 banks a bank can create or validate atransaction for up to 20 banks in less than 200ms

As described in sect41 zkLedger uses Borromean ringsignatures to prove that a value is in a certain range andsupports values up to 240 Reducing the supported rangeof values would reduce range proof cost since that cost islinear in the number of bits in the size of the range Thereare also newer proof systems such as Bulletproofs which

might create much smaller range proofs [13] We plan toevaluate zkLedger with Bulletproofs in future work

73 Cost of auditing ledgersThe left graph in Figure 4 shows that for certain func-tions the time to audit is independent of the number oftransactions in the ledger This is because the Auditorand Banks maintain commitment caches which alreadyhave the commitment product necessary to prove to theauditor the sum of the values in its column The auditfunction is measuring the Herfindhal-Hirschman Indexso the auditor communicates with each bank

When the auditor cannot use a commitment cache per-haps because it was offline it must process the wholeledger to compute the commitment product This alsoapplies to more complex auditing like the types describedin sect5 when the auditor has to verify recommitments forevery row in the ledger These costs are shown in themiddle graph in Figure 4 This graph shows how long ittakes the auditor to compute the Herfindahl-HirschmanIndex on a ledger of varying sizes without using the com-mitment caches so the auditor must process every row ofthe ledger In these measurements the auditor does notverify each row As expected this time increases linearlywith the number of rows This indicates that maintainingcommitment caches is important for real-time auditingHowever even without commitment caches auditing timeis reasonable 35 seconds for 100K transactions Thissuggests the complex auditing queries in which the au-ditor computes a similar set of operations per row willalso be on the order of many seconds zkLedger currentlyonly maintains commitment product caches per asset perbank but could maintain more

For a fixed size ledger this audit function costs orderthe number of banks The right graph in Figure 4 demon-strates the auditing costs of computing the Herfindahl-Hirschman Index on a ledger of 2000 transactions as wevary the number of banks both with and without com-mitment caches The auditor audits the banks in parallelAuditing cost for this function grows slightly with thenumber of banks since more banks increase the variabil-ity in parallel auditing and the auditor must wait for thelast bank to respond before computing the final answer

In these figures each point is the mean of running theauditing query 20 times with error bars representing onestandard deviation from the mean

74 Scaling with more banksThere are two significant costs that grow with the numberof banks in zkLedger a serial step to create transactionsthat increases linearly and verifying transactions whichincreases quadratically with the number of banks As

USENIX Association 15th USENIX Symposium on Networked Systems Design and Implementation 75

0

100

200

300

400

500

600

2 4 6 8 10 12 14 16 18 20

Tim

e (

ms)

number of banks

verify-1create-1verify-12

create-12

0

200

400

600

800

1000

2 3 4 5 6 7 8 9 10

Tim

e (

ms)

number of banks

complete transactions

0

2

4

6

8

10

12

2 3 4 5 6 7 8 9 10

Th

rou

gh

pu

t (t

xn

ss

ec)

number of banks

all banks transactingone bank transacting

Figure 3 Transaction creation and verification time for one bank (left) varying the number of entries in the transaction Single-threaded andmulti-threaded performance with 12 threads Time to fully process a transaction including creation broadcast to ledger banks and auditor andverification by all parties (middle) Throughput (right) varying the number of banks

0

2

4

6

8

10

12

0K 20K 40K 60K 80K 100K

Au

ditin

g t

ime

(m

s)

Transactions in ledger

online auditor

0

500

1000

1500

2000

2500

3000

3500

0K 20K 40K 60K 80K 100K

Transactions in ledger

offline auditor

0

20

40

60

80

100

120

2 3 4 5 6 7 8 9 10

Number of banks

offline auditor

online auditor

Figure 4 Time to audit ledgers of different sizes (4 banks) and with a varying number of banks (2000 row ledger) Audit time is independent of thesize of the ledger (left) thanks to commitment caches maintained by the online auditor When commitment cache optimization is turned off (middle)the audit time is linear in the size of the ledger Audit time grows with the number of banks (right) and is much higher without commitment caches

described in sect41 a bank needs to use its entry fromtransaction nminus1 to create transaction n So though a bankcan use many cores to produce the proofs for a singletransaction in parallel multiple banks cannot producedifferent transactions in parallel In zkLedger banks startcreating transaction n before seeing nminus 1 but the bankcannot complete the transaction until nminus1 is accepted tothe ledger and verified causing an inherent bottleneck

The second major cost is around verification Everybank must verify every transaction so the more banksthe larger each transaction and thus the more work thatneeds to be done by each bank The middle graph inFigure 3 measures the time it takes one bank to createand all participants in zkLedger to completely processa transaction One bank creates a transaction and sendsit to the ledger which then broadcasts the transaction toall banks and an online auditor The auditor and everybank verify the transaction As we increase the numberof banks work increases quadratically however bankscan verify transactions in parallel so the time to processtransactions only increases linearly The right graph inFigure 3 shows that as we surmised zkLedgerrsquos through-put worsens with more banks The one bank transactingline in this graph is the same data as the middle graph

Since range proofs dominate the costs of transactioncreation and verification we are optimistic that a fasterrange proof implementation will directly improve perfor-mance zkLedgerrsquos current performance is comparableto Solidus a privacy-preserving distributed ledger whichachieves 3-4 transactions per second with online valida-tion but unlike zkLedger does not support auditing

8 Future workzkLedger focuses on providing provably correct auditingover private transaction data but zkLedger does not havea way to recover if the distributed ledger is corrupted Inthis case the parties maintaining the ledger would haveto come together to recreate historical transactions zk-Ledger also does not provide recourse if a bank commitsan unintended transaction to the ledger A future ver-sion of zkLedger might provide rectifying transactions orparticipant agreed-upon rollback

9 ConclusionzkLedger is the first distributed ledger system to providestrong transaction privacy public verifiability and com-plete provably correct auditing zkLedger supports a richset of auditing queries which are useful to measure thefinancial health of a market We developed a design usingnon-interactive zero-knowledge proofs to prove transac-tions maintain financial invariants and to support auditingOur evaluation shows that zkLedger has reasonable per-formance for transaction settlement and auditing

10 AcknowledgementsWe thank Alexander Chernyakhovsky Thaddeus DryjaDavid Lazar Ronald L Rivest CJ Williams and ourshepherd and reviewers for helpful comments The re-search leading to these results has received funding fromthe Center for Science of Information (CSoI) an NSFScience and Technology Center under grant agreementCCF-0939370 and the Ethics and Governance of Artifi-cial Intelligence Fund

76 15th USENIX Symposium on Networked Systems Design and Implementation USENIX Association

References[1] Bank secrecy act of 1970 October 1970 12 USC 103[2] Package btcec implements support for the elliptic curves

needed for Bitcoin July 2017 httpsgodocorggithubcombtcsuitebtcdbtcec

[3] ABBE E A KHANDANI A E AND LO A WPrivacy-preserving methods for sharing financial risk ex-posures The American Economic Review 102 3 (2012)65ndash70

[4] ARASU A BLANAS S EGURO K KAUSHIK RKOSSMANN D RAMAMURTHY R AND VENKATE-SAN R Orthogonal security with cipherbase In CIDR(2013)

[5] BAJAJ S AND SION R Trusteddb A trusted hardware-based database with privacy and data confidentiality IEEETransactions on Knowledge and Data Engineering 26 3(2014) 752ndash765

[6] BAUMANN A PEINADO M AND HUNT G Shieldingapplications from an untrusted cloud with haven ACMTransactions on Computer Systems (TOCS) 33 3 (2015)8

[7] BEN-SASSON E CHIESA A GENKIN D TROMERE AND VIRZA M SNARKs for C Verifying programexecutions succinctly and in zero knowledge In Advancesin CryptologyndashCRYPTO 2013 Springer 2013 pp 90ndash108

[8] BEN-SASSON E CHIESA A GREEN M TROMERE AND VIRZA M Secure sampling of public parametersfor succinct zero knowledge proofs In Proceedings of the2015 IEEE Symposium on Security and Privacy (2015)SP rsquo15 pp 287ndash304

[9] BLUM M FELDMAN P AND MICALI S Non-interactive zero-knowledge and its applications In Pro-ceedings of the 20th Annual ACM Symposium on Theoryof Computing (1988) STOC rsquo88 pp 103ndash112

[10] BOGDANOV D TALVISTE R AND WILLEMSON JDeploying secure multi-party computation for financialdata analysis In International Conference on FinancialCryptography and Data Security (2012) Springer pp 57ndash64

[11] BOWE S GABIZON A AND GREEN M A multi-party protocol for constructing the public parameters ofthe Pinocchio zk-SNARK Cryptology ePrint ArchiveReport 2017602 2017

[12] BOWE S GABIZON A AND MIERS I Scalable multi-party computation for zk-SNARK parameters in the ran-dom beacon model Cryptology ePrint Archive Report20171050 2017

[13] BUNZ B BOOTLE J BONEH D POELSTRA AAND MAXWELL G Bulletproofs Short proofs for Con-fidential Transactions and more In Security and Privacy(SP) 2018 IEEE Symposium on (2018) IEEE

[14] BURKHART M STRASSER M MANY D AND DIM-ITROPOULOS X Sepia Privacy-preserving aggregationof multi-domain network events and statistics Network 1101101 (2010)

[15] CASTRO M AND LISKOV B Practical byzantine faulttolerance In OSDI (1999) vol 99 pp 173ndash186

[16] CECCHETTI E ZHANG F JI Y KOSBA A JUELSA AND SHI E Solidus Confidential distributed ledgertransactions via pvorm

[17] CHAIN I Confidential assets httpsblogchaincomhidden-in-plain-sight-transacting-privately-on-a-blockchain-835ab75c01cb

[18] CORRIGAN-GIBBS H AND BONEH D Prio Privaterobust and scalable computation of aggregate statisticsarXiv preprint arXiv170306255 (2017)

[19] COUNCIL F R Developments in audit 20162017full report 2017 httpwwwfrcorgukgetattachment915c15a4-dbc7-4223-b8ae-cad53dbcca17Developments-in-Audit-2016-17-Full-reportpdf

[20] CRAMER R DAMGARD I AND SCHOENMAKERSB Proofs of partial knowledge and simplified design ofwitness hiding protocols In Advances in Cryptology -CRYPTO rsquo94 14th Annual International Cryptology Con-ference Santa Barbara California USA August 21-251994 Proceedings (1994) pp 174ndash187

[21] DAGHER G G BUNZ B BONNEAU J CLARK JAND BONEH D Provisions Privacy-preserving proofsof solvency for Bitcoin exchanges In Proceedings of the22nd ACM SIGSAC Conference on Computer and Com-munications Security (Denver CO 2015) ACM pp 720ndash731

[22] Corda 2017 httpsgithubcomcordacorda

[23] Digital asset holdings 2017 httpdigitalassetcom

[24] Regulation (EU) 2016679 of the European Parliamentand of the Council of 27 April 2016 on the protection ofnatural persons with regard to the processing of personaldata and on the free movement of such data and repealingDirective 9546EC (General Data Protection Regulation)Official Journal of the European Union L119 (May 2016)1ndash88

[25] FELDMAN A J ZELLER W P FREEDMAN M JAND FELTEN E W Sporc Group collaboration us-ing untrusted cloud resources In OSDI (2010) vol 10pp 337ndash350

[26] FIAT A AND SHAMIR A How to prove yourselfpractical solutions to identification and signature problemsIn Proceedings of the 6th Annual International CryptologyConference (1987) CRYPTO rsquo87 pp 186ndash194

[27] GARMAN C GREEN M AND MIERS I Accountableprivacy for decentralized anonymous payments Cryp-tology ePrint Archive Report 2016061 2016 httpeprintiacrorg2016061

[28] GREENBERG A Fbi says itrsquos seized $285 million inbitcoins from ross ulbricht alleged owner of silk roadForbes 25 (2013)

USENIX Association 15th USENIX Symposium on Networked Systems Design and Implementation 77

zkLedger might require multiple range proofs but byusing disjunctive proofs we can multiplex different valuesinto one range proof per entry

In summary the contributions of this paper are

bull zkLedger the first distributed ledger system to achievestrong privacy and complete auditing

bull a design combining fast well-understood cryptographicprimitives using audit tokens and mapreduce to com-pute provably correct answers to queries

bull an evaluation of zkLedger showing efficient transactioncreation and auditing and

bull an analysis of the types of queries zkLedger can supportsuggesting that zkLedger can efficiently handle a usefulset of auditing measurements

2 Related WorkzkLedger is related to work in auditing or computing onprivate data and privacy-preserving blockchains zkLed-ger achieves fast provably correct auditing by creatinga new distributed ledger table model and applying a newscheme using zero-knowledge proofs

21 Computing on Private DataPrevious work proposed a multi-party computationscheme in which participants use a secure protocol tocompute the results of functions which answer questionsabout systemic financial risk the same problem which zk-Ledger aims to address [3 10] and network security [14]This work provides privacy benefits over existing analyt-ics systems by allowing participants to keep their datasecret However it only supports overall system auditingit is not a solution to audit individual participants Thereis also nothing preventing participants from lying in theinputs to the multi-party computation they do not achievecompleteness

Provisions [21] is a way for Bitcoin exchanges to provethey are solvent without revealing their total holdingsProvisions uses Proof of Assets and Proof of Liabilitieswhich are very similar to the zero-knowledge proofs weuse in zkLedger However in Provisions an exchangecould ldquoborrowrdquo private keys from another Bitcoin holderand thus prove assets they do not actually hold in factmultiple exchanges could share the same assets More-over Provisions does not provide completeness By usinga columnar construction with a distributed ledger zkLed-ger achieves completeness

In Prio [18] untrusted servers can compute privatelyon mobile client data Prio does not operate on distributedledgers and thus does not guarantee public verifiability

Prio requires all servers to cooperate in order for clientproofs to validate zkLedger can tolerate non-cooperatingparticipants

Several systems provide private and correct computingusing trusted hardware [4ndash6 49 52] In our setting wecannot guarantee that all participants will trust the samehardware provider In addition it would be a conflictof interest to use such a system to audit the companyproviding the trusted hardware

There are many systems which compute on encrypteddata to protect user confidentiality in the event of a servercompromise [25 31 32 40 43 44 50] These systemsaddress a different problem than what zkLedger is tryingto solve Instead we provide interactive provably correctauditing over private data generated by many parties

22 Privacy-preserving blockchainsBitcoin a decentralized cryptocurrency released in 2009was the first blockchain [37] Many companies have ex-plored using a blockchain to record the transfer of assetsThese systems are marked by the following characteris-tics (1) Multiple possibly distrusting participants allwith write permissions and no single point of failure orcontrol (2) A consensus protocol to construct an append-only globally ordered log with a chain of hashes to pre-vent tampering with the past and (3) Digitally signedtransactions to indicate intent to transfer ownership

In Bitcoin and most other blockchains all transactionsare public every participant receives each transactionand can verify all the details Users create pseudonymsby generating one-time use public keys for payment ad-dresses but transaction amounts and the links betweentransactions are still globally visible Confidential Trans-actions [34] and Confidential Assets [17 42] are exten-sions to Bitcoin which blind the assets and amounts intransactions while still ensuring that all participants canvalidate transactions Though these systems hide assetsand amounts they leak the transaction graph and do notsupport private auditingmdashan auditor would require ac-cess to all plain-text transactions in order to ensure com-pleteness The transaction graph alone leaks substantialinformation [36 38 45 46] for example the FBI fol-lowed linked transactions to trace bitcoins and used thisas evidence in court [28] zkLedger provides strongertransaction privacy and private auditing but at the costof scalability Transactions in zkLedger are sized orderthe number of participants in the whole system requiringmore time to produce and verify as the number of par-ticipants grows This makes zkLedger more suitable toledgers with fewer participants who require more privacy

Solidus [16] is a distributed ledger system that usesOblivious RAM to hide the transaction graph and trans-

USENIX Association 15th USENIX Symposium on Networked Systems Design and Implementation 67

action amount between bank customers While this con-struction also provides private transactions Solidus canonly support auditing by revealing all of the keys used inthe system to an auditor and opening transactions zk-Ledger achieves performance similar to Solidus whileproviding private auditing

R3rsquos Corda [22] and Digital Asset Holdingrsquos GlobalSynchronization Log (GSL) [23] are distributed ledgersgeared towards financial institutions that rely on trustedthird parties to pass through information In Corda no-taries verify transactions and maintain privacy of partici-pants while GSL segments its ledger only storing a hashof the values globally and limiting access to fine-grainedtransaction data Neither support private auditing

Another approach is that of Zerocash [47] and its re-lated implementation Zcash [51] an anonymous cryp-tocurrency based on Bitcoin Zerocash uses zk-SNARKs[7] to hide transaction amounts participants and thetransaction graph The zk-SNARKs as used in Zcashcan be extended to handle policies to enforce regulationsKYCAML laws and taxes [27] These policies do notsupport arbitrary queries but instead put limits on thenew types of transactions that can take place These ideashave not yet been implemented in a practical system

zk-SNARKs are quite efficient for some statementsbut unfortunately the price of this efficiency is paid insetup assumptions as of now all concretely efficientzk-SNARKs require a trusted third party for setup Theconsequences of incorrect or compromised setup are po-tentially disastrous an adversary who can learn the secretrandomness used during setup can make fraudulent proofsof false statements that are indistinguishable from proofsof true statements In our setting (international bank-ing) such proofs would permit unrestricted creation ordestruction of financial assets or liabilities There maynot even be a viable party to perform the one-time trustedsetup For example Russia might not trust the FederalReserve or the European Central Bank or it might notbe politically expedient to be seen as doing so While itis possible to mitigate this concern eg by distributingthe setup between multiple parties [8 11 12] this processis onerous and expensive Ideally the financial integrityof the system would not rely on trusted setup at all Wechoose to base consensus-critical portions of zkLedgerrsquosdesign on standard NIZKs

3 zkLedger Overview31 Architecture

System participants There are n participants which wecall banks that issue transactions to transfer digital assetsBank1 Bankn and an auditor Auditor that verifies

certain operational aspects of transactions performed bythe banks (eg ldquois a particular bank Banki solventrdquo)These roles are not distinct a bank could also audit ADepositor or set of Depositors can issue and withdrawassets from the system for example the European Cen-tral Bank might issue 1M C to Banki in the system Is-suance and withdrawal of all assets are controlled by theDepositors and are global public events

Transactions Banks exchange assets by creating trans-fer transactions whose details are hidden A transfertransaction captures an event where Banki is transferringv shares of asset t to Bank j Our scheme supports a banktransferring to multiple other banks but for simplicity weassume there is one spending and one receiving bank ineach transaction Banks determine the details of a trans-fer transaction outside of zkLedger perhaps through anexchange We assume they use encrypted channels

Append-only ledger Banks submit transactions to anappend-only ledger which globally orders all valid trans-actions If a digital asset only exists on the ledger thentransfer on the ledger is change in legal custody of the dig-ital assets not merely a record of ownership change andan Auditor is guaranteed a Bank is not hiding assets Thisledger could be maintained by a trusted third party by thebanks themselves or via a blockchain like Ethereum orBitcoin Maintaining a fault-tolerant globally ordered logis outside the scope of this paper but can be done usingstandard techniques [15 30 39]

32 Cryptographic building blocks

Commitment schemes To protect their privacy partici-pant banks do not broadcast payment details such as thetransaction amount in plain Instead the banks post hid-ing commitments to the append-only ledger in particularzkLedger uses Pedersen commitments [41] Let G be acyclic group with s = |G| elements and let g and h be tworandom generators of G Then a Pedersen commitment toan integer v isin 01 sminus1 is formed as follows pickcommitment randomness r and return the commitmentcm = COMM(vr) = gvhr

Pedersen commitments are perfectly hiding the com-mitment cm reveals nothing about the committed value vIn a similar way the commitments are also computation-ally binding if an adversary can open a commitment cmin two different ways (for the same r two different valuesv and vprime) then the same adversary can be used to computelogh(g) and thus break the discrete logarithm problem inG In zkLedger we choose G to be the group of points onthe elliptic curve secp256k1

A very useful property of Pedersen commitments isthat they are additively homomorphic If cm1 and cm2 are

68 15th USENIX Symposium on Networked Systems Design and Implementation USENIX Association

Use Commitment 13Cache to prove answer13

013 $13113 euro13213 $13

TX DB13

Commitment Cache13

Bank of America13

130558 2171813

130559 2171813

130601 2171813

Add transaction13Notify of new transaction13

Determine 13trade 13

details13

Commitment Cache13

Auditor13

Notify of new transaction13

TX DB13

Commitment Cache13

JPMorgan13

Respond to Audit13 Audit13

Use Commitment 13Cache to verify audit13

Bank of America13 Goldman Sachs13 JP Morgan13

transaction commitments and proofs13

Figure 1 Overall zkLed-ger system design showingthe interactions between thethree main entities (banksauditor and the sharedledger) in our system Eachbank maintains private stateconsisting of the transactiondatabase for transactions thebank originated and thebankrsquos secret key

two commitments to values v1 and v2 using commitmentrandomness r1 and r2 respectively then cm = cm1 middotcm2is a commitment to v1 + v2 using randomness r1 + r2 ascm=(gv1hr1) middot(gv2hr2)= gv1+v2 hr1+r2 To speed up trans-action generation and auditing zkLedger makes extensiveuse of the ability to additively combine commitments

Public-key encryption Every bank i also generates aSchnorr signature keypair keypair consisting of a secretkey ski and public key pki = hski and distributes thepublic key pki to all other system participants

Non-interactive zero-knowledge proofs To makeprivacy-preserving assertions about payment details zk-Ledger relies on non-interactive zero-knowledge proofs(NIZKs) [9] In brief zero-knowledge proofs concerntwo parties the prover who holds some private data andthe verifier who wishes to be convinced of some propertyabout this private data For example the prover mightknow the opening of a commitment cm and wish to con-vince the verifier that the committed value v is in somerange eg 0 le v lt 106 Using NIZKs the prover canproduce a binary string π the proof that simultaneouslypersuades the verifier yet does not reveal anything elseabout v Verifying π does not require any interactionbetween the prover and the verifier and the prover canappend π to the ledger where it can be verified by anyparty of the system

In theory NIZK proof systems exist for all propertiesin NP whereas the practical feasibility of NIZKs is highly-dependent on the complexity of the property at hand Inparticular algebraic properties in cyclic groups such asknowledge of discrete logarithm equality of values com-mitted in Pedersen commitments or similar have veryefficient NIZK proof systems The design of zkLedger iscarefully structured so that all NIZK proofs have particu-larly efficient constructions

33 Security GoalsThe goals of zkLedger are to hide the amounts partici-pants and links between transactions while maintaining averifiable transaction ledger and for the Auditor to receivereliable answers to its queries Specifically zkLedger letsbanks issue hidden transfer transactions which are stillpublicly verifiable by all other participants every partici-pant can confirm a transaction conserves assets and assetsare only transferred with the spending bankrsquos authorityFor example if Banki transfers 10000 C to Bank j boththe banks and amount are hidden The asset (C) and timeof the transaction are not hidden zkLedger also hides thetransaction graph meaning which previous transaction(s)supplied the 10000 C to Banki in the first place

An Auditor can query a Bank about its contents on theledger for example ldquoHow many euros does Bank j holdrdquoA bank should be able to produce commitments whichwill convince the auditor that the bankrsquos answer to theauditing query is correct meaning consistent with thetransactions on the ledger zkLedger ensures that if a bankgives the Auditor an answer that is inconsistent with theledger the Auditor will catch such attempt of cheatingwith high probability (and of course a trustworthy answermust always be accepted)

34 Threat modelzkLedger does not assume that banks will behavehonestlymdashthey can attempt to steal assets hide assetsmanipulate their account balances or lie to auditors Weassume banks can arbitrarily collude zkLedger keeps theamounts and participants of transactions private as longas neither the spender nor receiver in a transaction colludewith an observer like the Auditor We assume that theledger does not omit transactions and is available zkLed-ger does not protect against an adversary who observestraffic on the network for example if only two banksare exchanging messages itrsquos reasonable to assume thetransactions in the ledger involve those banks Nothing

USENIX Association 15th USENIX Symposium on Networked Systems Design and Implementation 69

beyond what is necessarily leaked by an audit is revealedHowever frequent auditing might reveal transaction con-tents eg if an auditor asks for banksrsquo assets after everytransaction

4 DesignThe challenge in creating zkLedger is to practically sup-port complete confidential auditingmdashan Auditor shouldnot be able to see individual bank transactions but a Bankshould not be able to hide assets from the Auditor dur-ing an audit and the auditor should be able to detect anincorrect answer

Figure 1 shows a general overview of zkLedger Thereare banks which determine transactions out of band andthen settle them by appending transactions to the ledgerThe ledger makes sure all banks and any auditors seenew transactions Each bank and auditor maintains acommitment cache which are commitments to summedvalues used to make creating transactions and respondingto audits faster Each bank also has private stores of plain-text transaction data

The rest of this section describes the zkLedger trans-action format how banks create transactions and how abank can answer a simple query from the auditor

41 TransactionsThe ledger in zkLedger is a table where transactions cor-respond to rows and Banks correspond to columns Eachtransaction has an entry for each Bank Figure 2 shows aledger with n banks Each entry in a transaction includesa commitment to a value which is the amount of the assetthat is being debited or credited to the bank For exam-ple if Banki wants to transfer 100 shares of an asset toBank j irsquos entry in the transaction would contain a com-mitment to -100 and jrsquos would contain a commitment to100 All other entries in the transaction would containcommitments to 0 since none of the other bank balanceswere changed This scheme has the nice property thatan outside observer can look at a bankrsquos entire columnand know that this represents the entirety of the bankrsquosholdings

Hiding amounts As described in sect32 zkLedger doesnot include the value in plain-text in the transaction In-stead zkLedger uses Pedersen commitments to committo the value in transfer transactions This makes valuecommitments completely indistinguishablemdashan outsideobserver cannot tell the difference between a commitmentto a positive value a negative value or 0 Recall that acommitment to a value v is cm = COMM(vr) = gvhrIf desired a prover can reveal v and r to a verifier whoknows cm and the verifier can confirm this is consistent

Since a transaction in zkLedger contains an entry forevery Bank there is a size-n vector ~cm committing tovalues in ~v Each commitment cmk uses a fresh com-mitment randomness rk Most of the entries will containcommitments to 0 for banks that are not involved with thetransaction but this is not apparent to an outside observer

zkLedger maintains the following financial invariants

bull A transfer transaction cannot create or destroy assets

bull The spending bank must give consent to the transferand must actually own enough of the particular asset toexecute this transaction

In a public blockchain the validators could simplyconfirm that these things are true by looking at the historyof transactions and the current transaction and makingsure the spending bank has the funds to spend Howeverin zkLedger these values are not public Instead wecreate a set of proofs that the spender can create to provethe invariants are maintained The spender can createa transaction without interacting with any of the otherbanks

First zkLedger introduces a Proof of Balance (πB)This is a proof that the transaction conserves assets noassets are created or destroyed (of course public is-suance and withdrawal transactions do not have suchproofs) More formally the committed values shouldsatisfy sum

nk=1 vk = 0 To prove this the prover chooses the

rk carefully it should also be the case that sumnk=1 rk = 0

If this is true and the values also sum to 0 then the ver-ifier can check to make sure that prod

nk=1 cmk = 1 for the

commitments in the rowNext zkLedger must ensure that the spending bank

actually has the assets to transfer To do this zkLedger in-troduces a Proof of Assets (πA) Other privacy-preservingblockchain systems use Unspent Transaction Outputsor UTXOs to show proof of assets and prevent doublespending For example if Alice wants to send a coin toBob she chooses one of her coins creates a new trans-action addressing the coin to Bob and includes a pointerto the previous transaction where she received the coinThis previous transaction is an output All of the valida-tors in the system maintain the invariant that outputs canonly be spent once Unfortunately in systems without zk-SNARKs this leaks the transaction graph In zkLedger abank proves it has assets by creating a commitment to thesum of the values for the asset in its column includingthis transaction If the sum is greater than or equal to 0then the bank has assets to transfer Note that this is truesince the bankrsquos column represents all the assets it hasreceived or spent and the Pedersen commitments can behomomorphically added in columns as well as in rows In

70 15th USENIX Symposium on Networked Systems Design and Implementation USENIX Association

order to produce a proof with the correct sum the bankmust have seen every previous transaction This impliesthat banks must create transactions serially In its ownentry where the value is negative the bank includes proofof knowledge of secret key to show that it authorized thetransaction This requires creating a disjunctive proofmdasheither the committed value for entry i has vi ge 0 or thecreator of the transaction knows the secret key for Banki

Range proofs Because commitment values are in anelliptic curve group and rely on modulus we need to makesure that the commited values are within an acceptablerange To see why note that if N is the order of thegroup then COMM(vr) = COMM(v+Nr) there is noway to distinguish between the two Without a checkto make sure the commited value is within the range[0N minus 1] a malicious bank could undetectably createassets To address this we use range proofs as describedin Confidential Assets [42] which uses Borromean ringsignatures [35] zkLedger supports asset value amountsup to a trillion Range proofs are the most expensivepart of the transaction as described our scheme requirestwo range proofsmdashone for the commitment value andanother for the sum of assets in the column We cansquash the two range proofs down to one range proof byintroducing an auxiliary commitment cmprimei cmprimei is eithera re-commitment to the value in cmi or the sum of thevalues in the column up to row m sum

mk=0 vk which can be

achieved by computing the product of the commitmentsin the column prod

mk=0 cmk Then we can do one range

proof on the value in cmprimei Either this is the spendingbank in which case cmprimei must be a commitment to thesum or it is another bank which is receiving funds or notinvolved in which case cmprimei could be either (and it doesnot matter which it is)

This satisfies the financial invariants described aboveHowever a particular design choice we made in zkLedgeris that a spending bank can create a transaction spendingits own assets without interacting with other banks Thismeans that a malicious bank could create transactionswhich maintain financial invariants but are ill-formed Wewill address this problem after describing how auditingworks

Once created a bank broadcasts the transaction andit will be appended to the ledger If the banks are main-taining the ledger each bank is responsible for validatingthe transaction before accepting it to the ledger If a thirdparty is maintaining the ledger then the third party shouldverify the proofs in a transaction before accepting it

Example transaction Figure 2 shows a transactionwhere Bank of America is transferring one million eurosto Goldman Sachs Bank of America creates the transfer

transaction publishing the transaction id timestamp andasset type (euros) publicly Bank of America commits tothe amount deducted from its own assets minus1000000in its own entry and 1000000 in Goldman Sachsrsquos en-try For every other bank Bank of America commits to0 This serves to hide the banks involved in the transferno one except Bank of America can distinguish betweenthe commitments to determine which are commiting tononzero values Bank of America then broadcasts thetransaction to the ledger The ledger maintainer validatesthe transaction and appends it to the ledger Once ac-cepted to the ledger this serves as a complete transferof 1000000 euros from Bank of America to GoldmanSachs

42 Auditing ProtocolThe Auditor has a copy of the ledger and interacts withthe banks to calculate functions on their private data inorder to get a view of the financial system represented bythe ledger

The Auditor audits Banki by issuing a query to Bankifor example ldquoHow many euros do you hold at time trdquoBanki responds to the auditor with an answer and a proofthat the answer is consistent with the transactions on theledger The Auditor multiplies the commitments on theledger in Bankirsquos column for euros and verifies the proofand answer with the total This is a commitment to thethe total amount of euros Banki holds

The key insight here is that given this table constructionthe Auditor can read bank irsquos column and know that itis seeing every asset transfer involving i There is noway for i to ldquohiderdquo assets on the ledger without actuallytransferring assets and giving control to another bank Incontrast during a traditional audit a bank could simplynot show the auditor some of its balance sheet

Banks could collude to hold assets for each other tem-porarily for example Bank j might transfer assets toBanki and take them back later For that time periodthe assets would be part of Bankirsquos holdings But bankscannot collude after an Auditor poses a query becausethe Auditor has already specified the time t at which thequery applies Any transfer would necessarily have to beafter t So at this point it is too late for a malicious bankto create a new transaction transferring assets to anotherbank

As described above a bank can create a transactiontransferring its own assets without any interaction Thisis common with most blockchain systems where onlythe signature of the sender is required to create a validtransaction There is no in-protocol way for a receiver toobject to a transfer Given our table construction everybank is affected by every transaction because a bank must

USENIX Association 15th USENIX Symposium on Networked Systems Design and Implementation 71

Metadata Bank1 Bank2 Bank3 BanknID Asset Time (Bank of America) (Goldman Sachs) (JPMorgan) (Citigroup)

1 e 130601 COMM(minus106r1) COMM(106r2) COMM(0r3) middot middot middot COMM(0rn)21718 Token1 Token2 Token2 middot middot middot Tokenn

πA1 π

B1 π

C1 πA

2 πB2 π

C2 πA

3 πB3 π

C3 middot middot middot πA

n πBn π

Cn

Figure 2 Contents of the ledger pertaining to a transaction that sends 106 euros from Bank1 to Bank2 Note that while asset type (euro) is visibleas part of the metadata the transaction amount (106 e) and participating institutions (Bank of America and Goldman Sachs) remain private Weuse Pedersen commitments so the commitment part of the row has values gminus106

hr1 g106hr2 and hr3 hrn Similarly audit tokens pictured

have values (pk1)r1 (pk2)

r2 For each bank Banki the corresponding column also includes proof-of-assets πAi proof-of-balance πB

i andproof-of-consistency πC

i

total all of the commitments in its column to respond tothe Auditormdasheven commitments for transactions in whichit was not involved A malicious Banki could create atransaction and not inform the another Bank j of the r jused in its entry even if it is not transferring assets toBank j Bank j would be unable to respond to the Auditorbecause it would not be able to open up the product of thecommitments in its column

In order to prove the integrity of a transfer transactionzkLedger must ensure an additional invariant

bull All banks have enough information in the transactionto open up commitments for the Auditor

zkLedger does this by requiring the spending bank toinclude a publicly verifiable Token in every entry Thisis defined as Tokenk = (pkk)

rk Bankk uses this token toopen up the product of its commitments for the Auditorwithout needing to know rkUsing audit tokens Consider a query for a sum of valuesin a bankrsquos column One way of answering this querywould be to reveal sumvk and sumrk Then the auditor wouldsimply check that these plain values are consistent withthe homomorphically computed value prodcmk = gsumvk hsumrk

However a bank does not necessarily know all thecommitment randomnesses rk (in particular these valuesare unknown for any transaction that the bank was notparty to) so the naive approach does not work

One approach could be to ask the preparer of the trans-action (ie the sender) to encrypt rk so that the non-participating bank Bankk can decrypt it To prevent thesending bank from placing a ldquogarbagerdquo ciphertext on theledger (and thus making Bankk fail the auditorrsquos queries)one would need a zero-knowledge proof of consistencybetween the encrypted value and the commitment Con-structing a concretely efficient proof for this statement isnon-trivial in a nutshell standard encryption schemes(eg ElGamal) embed plain-text in a group element whilePedersen commitments would have this value in the expo-nent

Our insight is that Bankk does not need to open sumrkto prove that sumvk is correct Instead suppose that Bankk

wants to claim that s = gsumvk hsumrk opens up to a valuesumvk To do so the bank computes sprime = sgsumvk = hsumrk andt = prodk Tokenk = hsksumrk Note that the auditor can alsocompute the values of sprime and t from the ledger and theclaimed answer sumvk

It suffices for the bank to prove that logsprime t = logh pkObserve that both logarithms evaluate to sk so a bank canproduce this proof without knowing sumri Moreover ifthis equation holds then t1sk = sprime = sgsumv but if the sumvwas incorrect then knowledge of sk would reveal a linearrelationship between g and h which is ruled out by oursecurity assumption

To show that the r in the Tokenk is the same as ther in rk we require an additional Proof of Consistency(πC) This is a zero-knowledge proof asserting that foreach k the value rk used to form cmk and Tokenk is thesame (See Appendix B for details of how such proof isconstructed)

Note that audit tokens are only useful to the bank open-ing its commitment though public a malicious bankcannot use another bankrsquos Token to successfully open anincorrect result or learn information about other bankrsquostransactions

43 Final transaction constructionFor a transfer transaction in row m each entry i containsthe following itemsbull Commitment (cmi) (gvihri) a Pedersen commitment

to the value we are transferringbull Audit Token (Tokeni) (pki)

ri This is used to answeraudits without knowing the randomness used in thecommitment

bull Proof of Balance (πB) a zero-knowledge proof assert-ing that the committed values satisfy sum

nk=1 vk = 0

bull Proof of Assets (πA) a new commitment cmprimei corre-sponding token Tokenprimei and a zero-knowledge proofasserting that either cmprimei is a re-commitment of thevalue in cmi or a recommitment to the sum of the val-ues in prod

mj=0 cm j and cmprimei is in range [0240) If the

committed value in cmi is negative the proof assertsbank i consented to the transfer

72 15th USENIX Symposium on Networked Systems Design and Implementation USENIX Association

bull Proof of Consistency (πC) two zero-knowledgeproofs asserting the randomness used in cmi and Tokeniare the same and the randomness used in cmprimei andTokenprimei are the same This is to prevent a maliciousbank from adding data to the ledger that would stopanother bank from being able to open its commitmentsfor the AuditorTransactions may contain additional metadata in plain-

text or not For example banks might want to includeencrypted account numbers addresses or identifying in-formation on behalf of a customer to satisfy the TravelRule specified in the Bank Secrecy Act of 1970 [1] zk-Ledger supports auditing over metadata in the transactionas well but it does not have a way to publicly verifyadditional metadata

44 Adding or removing bankszkLedger can support dynamically adding or removingbanks if done so publicly The participants (or anotherauthority) append a signed transaction to the ledger indi-cating which banks and thus columns should be addedor removed For example to add a new bank to theledger shown in Figure 2 the involved banks would ap-pend a transaction to the ledger indicating an intent toadd Bankn+1 From that point forward all transactionsshould contain n+ 1 entries The Proof of Assets forBankn+1rsquos entry in each transaction will start at the rowwhere Bankn+1 was added Similarly if a bank is re-moved later transactions should not include entries forthat bank Since all participants can see which bankswere added or removed they can adjust their proofs andverifications accordingly

45 OptimizationszkLedger employs several optimizations to make produc-ing and verifying these proofs faster and to support fasterauditing First caching the product of the commitmentsin a bankrsquos column improves auditing and proof creationspeed Each bank stores a rolling product of commitmentsby row and by asset so that it can quickly produce proofsof assets and answer queries from auditors Using thesecaches a bank can quickly answer an auditorrsquos query ona subset of rows in the ledger

Most transactions in zkLedger do not include everybank Every bank can pre-generate many range proofsfor the value 0 We speedup transaction throughput byparallelizing range proof generation and validation

5 AuditingAuditing is a critical component of the financial systemand regulators use various techniques to measure systemicfinancial risk Through the use of sums means ratios

variance co-variance and standard deviation an auditorin zkLedger can determine the following among othermeasurementsbull Leverage ratios zkLedger can show how much of an

asset a bank has on its books compared to its otherholdings This is helpful to estimate counterparty risk

bull Concentration Regulators use a measure called theHerfindahl-Hirschman Index (HHI) to measure howcompetitive an industry is [29]

bull Real-time price indexes Auditors can get a sense ofthe price of assets that are traded over-the-counter andthus not tracked through exchangesNatively zkLedger supports sums which means linear

combinations of values stored in the ledger This comesfrom the additive structure of Pedersen commitmentsBut zkLedger also supports a more general query modelwhich can be considered in two parts A map step and areduce stepBasic auditing Consider the basic example where anauditor wants to determine how much of an asset a bankhas on its books As described in sect42 the auditor willfilter the rows by asset multiply the entries in the bankrsquoscolumn and then ask the bank to open the commitmentproduct This only requires one round of communica-tion between the auditor and the bank and the messagesare a constant size independent of the number of rowsBecause of zkLedgerrsquos commitment caches this is veryfastMapreduce An auditor can issue more complex queriesthat might require the exchange of more data or mightrequire the participants to look at most of the rows in theledger Letrsquos consider an auditor which wants to know themean transaction size for a given bank and asset An au-ditor cannot verify a bankrsquos answer by simply totaling thebankrsquos column of commitments and dividing the openedvalue by the number of rows because such a computationwould have an incorrect denominator Namely when thebank is not involved in a transaction its column in therow will be commitment to 0 and should be discountedIn order to determine the correct denominator the auditorand the bank run the following protocol1 Filter The bank will filter the rows by asset2 Produce new commitments For each row the bank

will commit to a single bit b 1 or 0 depending on ifthe bank was involved in the transaction or not and cre-ate a proof that the bank has done this recommitmentcorrectly Crucially the auditor cannot distinguishbetween these commitments and so the bankrsquos trans-actions are not revealed We call this act of producingnew commitments the map step The map step alsorequires producing proofs that the new values were

USENIX Association 15th USENIX Symposium on Networked Systems Design and Implementation 73

correctly computed in our example for each transac-tion the bank would produce a NIZK proof that b = 1if and only if the transaction value was not equal to 0

3 Compute number of non-zero transactions Thebank computes the homomorphic sum of the new com-mitments to bits~b and opens it to reveal how manytransactions were non-zero This is the reduce stepThis is the correct denominator to compute the meantransaction size The auditor cannot tell anything aboutthe values in~b beyond what is revealed by the sum

4 Respond to auditor The bank then sends the auditorthe sum of the values in its column the vector of bitcommitments and corresponding NIZK proofs thenumber of its non-zero transactions n and the sum ofthe r values in the commitments

5 Verification The auditor verifies the map step byverifying the commitments were done correctly andverifies the reduce step and the number of non-zerotransactions by confirming that the product of the vec-tor of bit commitments is gnhsum

Nk=1 rk

6 Compute answer The auditor computes the meanfrom the sum of the bankrsquos column and the number ofnon-zero transactionsAn auditor could ask a bank for outlier transactions

using a similar technique For each row the bank willcommit to a bit b where b = 1 if a transactionrsquos value forthat bank is outside a specified range As when computingthe mean the auditor can verify these commitments wereproduced correctly and obtain the sum The bank can thenopen only the transactions where b = 1 and the auditorknows exactly how many transactions should be opened

More complex auditing queries require multiple mapand reduce computations For example here is howan auditor can learn the variance of transaction valuesv1 vN

1 Compute the average transaction value Executethe protocol described above to compute the numberof non-zero transactions n and their average value v

2 Apply the squaring map For each entry vi in its rowthe bank produces a fresh commitment cmprimei to v2

i andsends these commitments to the auditor The bank alsosupplies NIZK proofs that the value hidden in eachcmprimei is exactly the square of the value vi committed toon the ledger

3 Apply the reduce step The auditor computes theproduct of the commitments cmprimei and the bank opensup this commitment as V = v2

1 + middot middot middot+ v2N by revealing

R = sumNi=1 ri The auditor confirms that the product of

the commitments is equal to gV hR

The auditor now computes the variance σ as followsσ2 = 1

n sumvi 6=0(viminus v)2 = 1nV minus v2

We note that whereas the square mapping used abovecorresponds to the second moment (variance) zkLedgercan also compute higher statistical moments (eg skew-ness and kurtosis) using similar techniques and usingcubing and fourth power mappings respectively See Ap-pendix A for a list of measurements zkLedger supports

zkLedger can support limited information release byusing more complex reduce mappings For example in-stead of releasing the sum of values the bank can producea commitment to the rounded sum of values (eg to thefirst two decimal places) and use range proofs also im-plemented in zkLedger to show that the rounding wasdone correctly Revealing just the order of magnitude ofthe quantity at hand lets the parties balance the granularityof information disclosure6 ImplementationTo evaluate zkLedgerrsquos design we implemented a pro-totype of zkLedger in Go Our prototype uses a modi-fied version of the btcec library [2] that contains the pa-rameters and methods to compute with the elliptic curvesecp256k1 We use Gorsquos built-in SHA-256 implementa-tion for our cryptographic hash function and determin-istically pick g and h by applying point decompressionto the ldquonothing-up-my-sleeverdquo strings SHA256(0) andSHA256(1) Our prototype consists of approximately3200 lines of code of which 40 implement crypto-graphic tools used by zkLedger (zero-knowledge proofsrange proofs etc)

The implementation of the curve in zkLedger uses GorsquosbigInt type which we make no effort to compress orserialize in an efficient way A more optimized imple-mentation could compress curve points Our range proofsimplement the protocol used in Confidential Assets [42]Our NIZKs are based on Generalized Schnorr Proofswhich are three move interactive protocols to make themnon-interactive we apply the Fiat-Shamir heuristic [26]where we instantiate the random oracle using the SHA-256 hash function Our prototype implementation doesnot implement the complex queries described in sect5 andthus we do not evaluate them in sect7

7 EvaluationOur evaluation answers the following questionsbull How expensive is it to store prove and verify the differ-

ent proofs in zkLedger (sect72)bull How does auditing scale with the size of the ledger

(sect73)bull How does zkLedger scale with the number of banks

(sect74)

74 15th USENIX Symposium on Networked Systems Design and Implementation USENIX Association

Component Create Verify Size

2k Commitment 05 ms 05 ms 64 B2k Consistency 07 ms 08 ms 224 Bk Disjunctive 09 ms 09 ms 288 Bk Range 47 ms 35 ms 3936 B

Table 1 Number of each proof component in a transaction for k banksSize of and time to create and verify the components with 12 cores Therange proof create and verify benefit from the additional cores

71 Experimental setup

Microbenchmarks We run microbenchmarks on a 12core Intel machine with i7-X980 333 GHz CPUs and24GB of RAM running 64-bit Linux 440 on Ubuntu16043 Each microbenchmark runs the same code aBank runs to create and validate transactions

Distributed experiment We run the distributed experi-ments on a set of 12 virtual machines each with 4 cores ofIntel Xeon E5-2640 25 GHz processors 24GB of RAMand the same software setup as above There is one au-ditor one server providing the service of the ledger anda varying number of banks one per server Servers com-municate using the netrpc Go package over TCP Allexperiments use Go version 19

72 Proof overhead in zkLedgerTable 1 shows the time to prove and verify the proofs in atransaction in zkLedger There are two commitments twoconsistency proofs and one each of the disjunctive andrange proofs in a transaction entry There is a transactionentry per Bank Table 1 also shows the sizes of the variousproofs in bytes These sizes are estimated based on thesize of the underlying fields in the struct in memorythese proofs could be further compressed Range proofsdominate the size of the transactions

The left graph in Figure 3 shows the time it takes tocreate and verify a transaction varying the number ofoverall banks which increases the number of entries pertransaction This indicates that as we increase the numberof banks both transaction creation and verification timesper bank increase linearly but parallelization helps Prov-ing and validating range proofs dominates transactioncreation and verification but this cost is also highly paral-lelizable 12 cores gives a 28times speedup when creating atransaction with 20 banks a bank can create or validate atransaction for up to 20 banks in less than 200ms

As described in sect41 zkLedger uses Borromean ringsignatures to prove that a value is in a certain range andsupports values up to 240 Reducing the supported rangeof values would reduce range proof cost since that cost islinear in the number of bits in the size of the range Thereare also newer proof systems such as Bulletproofs which

might create much smaller range proofs [13] We plan toevaluate zkLedger with Bulletproofs in future work

73 Cost of auditing ledgersThe left graph in Figure 4 shows that for certain func-tions the time to audit is independent of the number oftransactions in the ledger This is because the Auditorand Banks maintain commitment caches which alreadyhave the commitment product necessary to prove to theauditor the sum of the values in its column The auditfunction is measuring the Herfindhal-Hirschman Indexso the auditor communicates with each bank

When the auditor cannot use a commitment cache per-haps because it was offline it must process the wholeledger to compute the commitment product This alsoapplies to more complex auditing like the types describedin sect5 when the auditor has to verify recommitments forevery row in the ledger These costs are shown in themiddle graph in Figure 4 This graph shows how long ittakes the auditor to compute the Herfindahl-HirschmanIndex on a ledger of varying sizes without using the com-mitment caches so the auditor must process every row ofthe ledger In these measurements the auditor does notverify each row As expected this time increases linearlywith the number of rows This indicates that maintainingcommitment caches is important for real-time auditingHowever even without commitment caches auditing timeis reasonable 35 seconds for 100K transactions Thissuggests the complex auditing queries in which the au-ditor computes a similar set of operations per row willalso be on the order of many seconds zkLedger currentlyonly maintains commitment product caches per asset perbank but could maintain more

For a fixed size ledger this audit function costs orderthe number of banks The right graph in Figure 4 demon-strates the auditing costs of computing the Herfindahl-Hirschman Index on a ledger of 2000 transactions as wevary the number of banks both with and without com-mitment caches The auditor audits the banks in parallelAuditing cost for this function grows slightly with thenumber of banks since more banks increase the variabil-ity in parallel auditing and the auditor must wait for thelast bank to respond before computing the final answer

In these figures each point is the mean of running theauditing query 20 times with error bars representing onestandard deviation from the mean

74 Scaling with more banksThere are two significant costs that grow with the numberof banks in zkLedger a serial step to create transactionsthat increases linearly and verifying transactions whichincreases quadratically with the number of banks As

USENIX Association 15th USENIX Symposium on Networked Systems Design and Implementation 75

0

100

200

300

400

500

600

2 4 6 8 10 12 14 16 18 20

Tim

e (

ms)

number of banks

verify-1create-1verify-12

create-12

0

200

400

600

800

1000

2 3 4 5 6 7 8 9 10

Tim

e (

ms)

number of banks

complete transactions

0

2

4

6

8

10

12

2 3 4 5 6 7 8 9 10

Th

rou

gh

pu

t (t

xn

ss

ec)

number of banks

all banks transactingone bank transacting

Figure 3 Transaction creation and verification time for one bank (left) varying the number of entries in the transaction Single-threaded andmulti-threaded performance with 12 threads Time to fully process a transaction including creation broadcast to ledger banks and auditor andverification by all parties (middle) Throughput (right) varying the number of banks

0

2

4

6

8

10

12

0K 20K 40K 60K 80K 100K

Au

ditin

g t

ime

(m

s)

Transactions in ledger

online auditor

0

500

1000

1500

2000

2500

3000

3500

0K 20K 40K 60K 80K 100K

Transactions in ledger

offline auditor

0

20

40

60

80

100

120

2 3 4 5 6 7 8 9 10

Number of banks

offline auditor

online auditor

Figure 4 Time to audit ledgers of different sizes (4 banks) and with a varying number of banks (2000 row ledger) Audit time is independent of thesize of the ledger (left) thanks to commitment caches maintained by the online auditor When commitment cache optimization is turned off (middle)the audit time is linear in the size of the ledger Audit time grows with the number of banks (right) and is much higher without commitment caches

described in sect41 a bank needs to use its entry fromtransaction nminus1 to create transaction n So though a bankcan use many cores to produce the proofs for a singletransaction in parallel multiple banks cannot producedifferent transactions in parallel In zkLedger banks startcreating transaction n before seeing nminus 1 but the bankcannot complete the transaction until nminus1 is accepted tothe ledger and verified causing an inherent bottleneck

The second major cost is around verification Everybank must verify every transaction so the more banksthe larger each transaction and thus the more work thatneeds to be done by each bank The middle graph inFigure 3 measures the time it takes one bank to createand all participants in zkLedger to completely processa transaction One bank creates a transaction and sendsit to the ledger which then broadcasts the transaction toall banks and an online auditor The auditor and everybank verify the transaction As we increase the numberof banks work increases quadratically however bankscan verify transactions in parallel so the time to processtransactions only increases linearly The right graph inFigure 3 shows that as we surmised zkLedgerrsquos through-put worsens with more banks The one bank transactingline in this graph is the same data as the middle graph

Since range proofs dominate the costs of transactioncreation and verification we are optimistic that a fasterrange proof implementation will directly improve perfor-mance zkLedgerrsquos current performance is comparableto Solidus a privacy-preserving distributed ledger whichachieves 3-4 transactions per second with online valida-tion but unlike zkLedger does not support auditing

8 Future workzkLedger focuses on providing provably correct auditingover private transaction data but zkLedger does not havea way to recover if the distributed ledger is corrupted Inthis case the parties maintaining the ledger would haveto come together to recreate historical transactions zk-Ledger also does not provide recourse if a bank commitsan unintended transaction to the ledger A future ver-sion of zkLedger might provide rectifying transactions orparticipant agreed-upon rollback

9 ConclusionzkLedger is the first distributed ledger system to providestrong transaction privacy public verifiability and com-plete provably correct auditing zkLedger supports a richset of auditing queries which are useful to measure thefinancial health of a market We developed a design usingnon-interactive zero-knowledge proofs to prove transac-tions maintain financial invariants and to support auditingOur evaluation shows that zkLedger has reasonable per-formance for transaction settlement and auditing

10 AcknowledgementsWe thank Alexander Chernyakhovsky Thaddeus DryjaDavid Lazar Ronald L Rivest CJ Williams and ourshepherd and reviewers for helpful comments The re-search leading to these results has received funding fromthe Center for Science of Information (CSoI) an NSFScience and Technology Center under grant agreementCCF-0939370 and the Ethics and Governance of Artifi-cial Intelligence Fund

76 15th USENIX Symposium on Networked Systems Design and Implementation USENIX Association

References[1] Bank secrecy act of 1970 October 1970 12 USC 103[2] Package btcec implements support for the elliptic curves

needed for Bitcoin July 2017 httpsgodocorggithubcombtcsuitebtcdbtcec

[3] ABBE E A KHANDANI A E AND LO A WPrivacy-preserving methods for sharing financial risk ex-posures The American Economic Review 102 3 (2012)65ndash70

[4] ARASU A BLANAS S EGURO K KAUSHIK RKOSSMANN D RAMAMURTHY R AND VENKATE-SAN R Orthogonal security with cipherbase In CIDR(2013)

[5] BAJAJ S AND SION R Trusteddb A trusted hardware-based database with privacy and data confidentiality IEEETransactions on Knowledge and Data Engineering 26 3(2014) 752ndash765

[6] BAUMANN A PEINADO M AND HUNT G Shieldingapplications from an untrusted cloud with haven ACMTransactions on Computer Systems (TOCS) 33 3 (2015)8

[7] BEN-SASSON E CHIESA A GENKIN D TROMERE AND VIRZA M SNARKs for C Verifying programexecutions succinctly and in zero knowledge In Advancesin CryptologyndashCRYPTO 2013 Springer 2013 pp 90ndash108

[8] BEN-SASSON E CHIESA A GREEN M TROMERE AND VIRZA M Secure sampling of public parametersfor succinct zero knowledge proofs In Proceedings of the2015 IEEE Symposium on Security and Privacy (2015)SP rsquo15 pp 287ndash304

[9] BLUM M FELDMAN P AND MICALI S Non-interactive zero-knowledge and its applications In Pro-ceedings of the 20th Annual ACM Symposium on Theoryof Computing (1988) STOC rsquo88 pp 103ndash112

[10] BOGDANOV D TALVISTE R AND WILLEMSON JDeploying secure multi-party computation for financialdata analysis In International Conference on FinancialCryptography and Data Security (2012) Springer pp 57ndash64

[11] BOWE S GABIZON A AND GREEN M A multi-party protocol for constructing the public parameters ofthe Pinocchio zk-SNARK Cryptology ePrint ArchiveReport 2017602 2017

[12] BOWE S GABIZON A AND MIERS I Scalable multi-party computation for zk-SNARK parameters in the ran-dom beacon model Cryptology ePrint Archive Report20171050 2017

[13] BUNZ B BOOTLE J BONEH D POELSTRA AAND MAXWELL G Bulletproofs Short proofs for Con-fidential Transactions and more In Security and Privacy(SP) 2018 IEEE Symposium on (2018) IEEE

[14] BURKHART M STRASSER M MANY D AND DIM-ITROPOULOS X Sepia Privacy-preserving aggregationof multi-domain network events and statistics Network 1101101 (2010)

[15] CASTRO M AND LISKOV B Practical byzantine faulttolerance In OSDI (1999) vol 99 pp 173ndash186

[16] CECCHETTI E ZHANG F JI Y KOSBA A JUELSA AND SHI E Solidus Confidential distributed ledgertransactions via pvorm

[17] CHAIN I Confidential assets httpsblogchaincomhidden-in-plain-sight-transacting-privately-on-a-blockchain-835ab75c01cb

[18] CORRIGAN-GIBBS H AND BONEH D Prio Privaterobust and scalable computation of aggregate statisticsarXiv preprint arXiv170306255 (2017)

[19] COUNCIL F R Developments in audit 20162017full report 2017 httpwwwfrcorgukgetattachment915c15a4-dbc7-4223-b8ae-cad53dbcca17Developments-in-Audit-2016-17-Full-reportpdf

[20] CRAMER R DAMGARD I AND SCHOENMAKERSB Proofs of partial knowledge and simplified design ofwitness hiding protocols In Advances in Cryptology -CRYPTO rsquo94 14th Annual International Cryptology Con-ference Santa Barbara California USA August 21-251994 Proceedings (1994) pp 174ndash187

[21] DAGHER G G BUNZ B BONNEAU J CLARK JAND BONEH D Provisions Privacy-preserving proofsof solvency for Bitcoin exchanges In Proceedings of the22nd ACM SIGSAC Conference on Computer and Com-munications Security (Denver CO 2015) ACM pp 720ndash731

[22] Corda 2017 httpsgithubcomcordacorda

[23] Digital asset holdings 2017 httpdigitalassetcom

[24] Regulation (EU) 2016679 of the European Parliamentand of the Council of 27 April 2016 on the protection ofnatural persons with regard to the processing of personaldata and on the free movement of such data and repealingDirective 9546EC (General Data Protection Regulation)Official Journal of the European Union L119 (May 2016)1ndash88

[25] FELDMAN A J ZELLER W P FREEDMAN M JAND FELTEN E W Sporc Group collaboration us-ing untrusted cloud resources In OSDI (2010) vol 10pp 337ndash350

[26] FIAT A AND SHAMIR A How to prove yourselfpractical solutions to identification and signature problemsIn Proceedings of the 6th Annual International CryptologyConference (1987) CRYPTO rsquo87 pp 186ndash194

[27] GARMAN C GREEN M AND MIERS I Accountableprivacy for decentralized anonymous payments Cryp-tology ePrint Archive Report 2016061 2016 httpeprintiacrorg2016061

[28] GREENBERG A Fbi says itrsquos seized $285 million inbitcoins from ross ulbricht alleged owner of silk roadForbes 25 (2013)

USENIX Association 15th USENIX Symposium on Networked Systems Design and Implementation 77

action amount between bank customers While this con-struction also provides private transactions Solidus canonly support auditing by revealing all of the keys used inthe system to an auditor and opening transactions zk-Ledger achieves performance similar to Solidus whileproviding private auditing

R3rsquos Corda [22] and Digital Asset Holdingrsquos GlobalSynchronization Log (GSL) [23] are distributed ledgersgeared towards financial institutions that rely on trustedthird parties to pass through information In Corda no-taries verify transactions and maintain privacy of partici-pants while GSL segments its ledger only storing a hashof the values globally and limiting access to fine-grainedtransaction data Neither support private auditing

Another approach is that of Zerocash [47] and its re-lated implementation Zcash [51] an anonymous cryp-tocurrency based on Bitcoin Zerocash uses zk-SNARKs[7] to hide transaction amounts participants and thetransaction graph The zk-SNARKs as used in Zcashcan be extended to handle policies to enforce regulationsKYCAML laws and taxes [27] These policies do notsupport arbitrary queries but instead put limits on thenew types of transactions that can take place These ideashave not yet been implemented in a practical system

zk-SNARKs are quite efficient for some statementsbut unfortunately the price of this efficiency is paid insetup assumptions as of now all concretely efficientzk-SNARKs require a trusted third party for setup Theconsequences of incorrect or compromised setup are po-tentially disastrous an adversary who can learn the secretrandomness used during setup can make fraudulent proofsof false statements that are indistinguishable from proofsof true statements In our setting (international bank-ing) such proofs would permit unrestricted creation ordestruction of financial assets or liabilities There maynot even be a viable party to perform the one-time trustedsetup For example Russia might not trust the FederalReserve or the European Central Bank or it might notbe politically expedient to be seen as doing so While itis possible to mitigate this concern eg by distributingthe setup between multiple parties [8 11 12] this processis onerous and expensive Ideally the financial integrityof the system would not rely on trusted setup at all Wechoose to base consensus-critical portions of zkLedgerrsquosdesign on standard NIZKs

3 zkLedger Overview31 Architecture

System participants There are n participants which wecall banks that issue transactions to transfer digital assetsBank1 Bankn and an auditor Auditor that verifies

certain operational aspects of transactions performed bythe banks (eg ldquois a particular bank Banki solventrdquo)These roles are not distinct a bank could also audit ADepositor or set of Depositors can issue and withdrawassets from the system for example the European Cen-tral Bank might issue 1M C to Banki in the system Is-suance and withdrawal of all assets are controlled by theDepositors and are global public events

Transactions Banks exchange assets by creating trans-fer transactions whose details are hidden A transfertransaction captures an event where Banki is transferringv shares of asset t to Bank j Our scheme supports a banktransferring to multiple other banks but for simplicity weassume there is one spending and one receiving bank ineach transaction Banks determine the details of a trans-fer transaction outside of zkLedger perhaps through anexchange We assume they use encrypted channels

Append-only ledger Banks submit transactions to anappend-only ledger which globally orders all valid trans-actions If a digital asset only exists on the ledger thentransfer on the ledger is change in legal custody of the dig-ital assets not merely a record of ownership change andan Auditor is guaranteed a Bank is not hiding assets Thisledger could be maintained by a trusted third party by thebanks themselves or via a blockchain like Ethereum orBitcoin Maintaining a fault-tolerant globally ordered logis outside the scope of this paper but can be done usingstandard techniques [15 30 39]

32 Cryptographic building blocks

Commitment schemes To protect their privacy partici-pant banks do not broadcast payment details such as thetransaction amount in plain Instead the banks post hid-ing commitments to the append-only ledger in particularzkLedger uses Pedersen commitments [41] Let G be acyclic group with s = |G| elements and let g and h be tworandom generators of G Then a Pedersen commitment toan integer v isin 01 sminus1 is formed as follows pickcommitment randomness r and return the commitmentcm = COMM(vr) = gvhr

Pedersen commitments are perfectly hiding the com-mitment cm reveals nothing about the committed value vIn a similar way the commitments are also computation-ally binding if an adversary can open a commitment cmin two different ways (for the same r two different valuesv and vprime) then the same adversary can be used to computelogh(g) and thus break the discrete logarithm problem inG In zkLedger we choose G to be the group of points onthe elliptic curve secp256k1

A very useful property of Pedersen commitments isthat they are additively homomorphic If cm1 and cm2 are

68 15th USENIX Symposium on Networked Systems Design and Implementation USENIX Association

Use Commitment 13Cache to prove answer13

013 $13113 euro13213 $13

TX DB13

Commitment Cache13

Bank of America13

130558 2171813

130559 2171813

130601 2171813

Add transaction13Notify of new transaction13

Determine 13trade 13

details13

Commitment Cache13

Auditor13

Notify of new transaction13

TX DB13

Commitment Cache13

JPMorgan13

Respond to Audit13 Audit13

Use Commitment 13Cache to verify audit13

Bank of America13 Goldman Sachs13 JP Morgan13

transaction commitments and proofs13

Figure 1 Overall zkLed-ger system design showingthe interactions between thethree main entities (banksauditor and the sharedledger) in our system Eachbank maintains private stateconsisting of the transactiondatabase for transactions thebank originated and thebankrsquos secret key

two commitments to values v1 and v2 using commitmentrandomness r1 and r2 respectively then cm = cm1 middotcm2is a commitment to v1 + v2 using randomness r1 + r2 ascm=(gv1hr1) middot(gv2hr2)= gv1+v2 hr1+r2 To speed up trans-action generation and auditing zkLedger makes extensiveuse of the ability to additively combine commitments

Public-key encryption Every bank i also generates aSchnorr signature keypair keypair consisting of a secretkey ski and public key pki = hski and distributes thepublic key pki to all other system participants

Non-interactive zero-knowledge proofs To makeprivacy-preserving assertions about payment details zk-Ledger relies on non-interactive zero-knowledge proofs(NIZKs) [9] In brief zero-knowledge proofs concerntwo parties the prover who holds some private data andthe verifier who wishes to be convinced of some propertyabout this private data For example the prover mightknow the opening of a commitment cm and wish to con-vince the verifier that the committed value v is in somerange eg 0 le v lt 106 Using NIZKs the prover canproduce a binary string π the proof that simultaneouslypersuades the verifier yet does not reveal anything elseabout v Verifying π does not require any interactionbetween the prover and the verifier and the prover canappend π to the ledger where it can be verified by anyparty of the system

In theory NIZK proof systems exist for all propertiesin NP whereas the practical feasibility of NIZKs is highly-dependent on the complexity of the property at hand Inparticular algebraic properties in cyclic groups such asknowledge of discrete logarithm equality of values com-mitted in Pedersen commitments or similar have veryefficient NIZK proof systems The design of zkLedger iscarefully structured so that all NIZK proofs have particu-larly efficient constructions

33 Security GoalsThe goals of zkLedger are to hide the amounts partici-pants and links between transactions while maintaining averifiable transaction ledger and for the Auditor to receivereliable answers to its queries Specifically zkLedger letsbanks issue hidden transfer transactions which are stillpublicly verifiable by all other participants every partici-pant can confirm a transaction conserves assets and assetsare only transferred with the spending bankrsquos authorityFor example if Banki transfers 10000 C to Bank j boththe banks and amount are hidden The asset (C) and timeof the transaction are not hidden zkLedger also hides thetransaction graph meaning which previous transaction(s)supplied the 10000 C to Banki in the first place

An Auditor can query a Bank about its contents on theledger for example ldquoHow many euros does Bank j holdrdquoA bank should be able to produce commitments whichwill convince the auditor that the bankrsquos answer to theauditing query is correct meaning consistent with thetransactions on the ledger zkLedger ensures that if a bankgives the Auditor an answer that is inconsistent with theledger the Auditor will catch such attempt of cheatingwith high probability (and of course a trustworthy answermust always be accepted)

34 Threat modelzkLedger does not assume that banks will behavehonestlymdashthey can attempt to steal assets hide assetsmanipulate their account balances or lie to auditors Weassume banks can arbitrarily collude zkLedger keeps theamounts and participants of transactions private as longas neither the spender nor receiver in a transaction colludewith an observer like the Auditor We assume that theledger does not omit transactions and is available zkLed-ger does not protect against an adversary who observestraffic on the network for example if only two banksare exchanging messages itrsquos reasonable to assume thetransactions in the ledger involve those banks Nothing

USENIX Association 15th USENIX Symposium on Networked Systems Design and Implementation 69

beyond what is necessarily leaked by an audit is revealedHowever frequent auditing might reveal transaction con-tents eg if an auditor asks for banksrsquo assets after everytransaction

4 DesignThe challenge in creating zkLedger is to practically sup-port complete confidential auditingmdashan Auditor shouldnot be able to see individual bank transactions but a Bankshould not be able to hide assets from the Auditor dur-ing an audit and the auditor should be able to detect anincorrect answer

Figure 1 shows a general overview of zkLedger Thereare banks which determine transactions out of band andthen settle them by appending transactions to the ledgerThe ledger makes sure all banks and any auditors seenew transactions Each bank and auditor maintains acommitment cache which are commitments to summedvalues used to make creating transactions and respondingto audits faster Each bank also has private stores of plain-text transaction data

The rest of this section describes the zkLedger trans-action format how banks create transactions and how abank can answer a simple query from the auditor

41 TransactionsThe ledger in zkLedger is a table where transactions cor-respond to rows and Banks correspond to columns Eachtransaction has an entry for each Bank Figure 2 shows aledger with n banks Each entry in a transaction includesa commitment to a value which is the amount of the assetthat is being debited or credited to the bank For exam-ple if Banki wants to transfer 100 shares of an asset toBank j irsquos entry in the transaction would contain a com-mitment to -100 and jrsquos would contain a commitment to100 All other entries in the transaction would containcommitments to 0 since none of the other bank balanceswere changed This scheme has the nice property thatan outside observer can look at a bankrsquos entire columnand know that this represents the entirety of the bankrsquosholdings

Hiding amounts As described in sect32 zkLedger doesnot include the value in plain-text in the transaction In-stead zkLedger uses Pedersen commitments to committo the value in transfer transactions This makes valuecommitments completely indistinguishablemdashan outsideobserver cannot tell the difference between a commitmentto a positive value a negative value or 0 Recall that acommitment to a value v is cm = COMM(vr) = gvhrIf desired a prover can reveal v and r to a verifier whoknows cm and the verifier can confirm this is consistent

Since a transaction in zkLedger contains an entry forevery Bank there is a size-n vector ~cm committing tovalues in ~v Each commitment cmk uses a fresh com-mitment randomness rk Most of the entries will containcommitments to 0 for banks that are not involved with thetransaction but this is not apparent to an outside observer

zkLedger maintains the following financial invariants

bull A transfer transaction cannot create or destroy assets

bull The spending bank must give consent to the transferand must actually own enough of the particular asset toexecute this transaction

In a public blockchain the validators could simplyconfirm that these things are true by looking at the historyof transactions and the current transaction and makingsure the spending bank has the funds to spend Howeverin zkLedger these values are not public Instead wecreate a set of proofs that the spender can create to provethe invariants are maintained The spender can createa transaction without interacting with any of the otherbanks

First zkLedger introduces a Proof of Balance (πB)This is a proof that the transaction conserves assets noassets are created or destroyed (of course public is-suance and withdrawal transactions do not have suchproofs) More formally the committed values shouldsatisfy sum

nk=1 vk = 0 To prove this the prover chooses the

rk carefully it should also be the case that sumnk=1 rk = 0

If this is true and the values also sum to 0 then the ver-ifier can check to make sure that prod

nk=1 cmk = 1 for the

commitments in the rowNext zkLedger must ensure that the spending bank

actually has the assets to transfer To do this zkLedger in-troduces a Proof of Assets (πA) Other privacy-preservingblockchain systems use Unspent Transaction Outputsor UTXOs to show proof of assets and prevent doublespending For example if Alice wants to send a coin toBob she chooses one of her coins creates a new trans-action addressing the coin to Bob and includes a pointerto the previous transaction where she received the coinThis previous transaction is an output All of the valida-tors in the system maintain the invariant that outputs canonly be spent once Unfortunately in systems without zk-SNARKs this leaks the transaction graph In zkLedger abank proves it has assets by creating a commitment to thesum of the values for the asset in its column includingthis transaction If the sum is greater than or equal to 0then the bank has assets to transfer Note that this is truesince the bankrsquos column represents all the assets it hasreceived or spent and the Pedersen commitments can behomomorphically added in columns as well as in rows In

70 15th USENIX Symposium on Networked Systems Design and Implementation USENIX Association

order to produce a proof with the correct sum the bankmust have seen every previous transaction This impliesthat banks must create transactions serially In its ownentry where the value is negative the bank includes proofof knowledge of secret key to show that it authorized thetransaction This requires creating a disjunctive proofmdasheither the committed value for entry i has vi ge 0 or thecreator of the transaction knows the secret key for Banki

Range proofs Because commitment values are in anelliptic curve group and rely on modulus we need to makesure that the commited values are within an acceptablerange To see why note that if N is the order of thegroup then COMM(vr) = COMM(v+Nr) there is noway to distinguish between the two Without a checkto make sure the commited value is within the range[0N minus 1] a malicious bank could undetectably createassets To address this we use range proofs as describedin Confidential Assets [42] which uses Borromean ringsignatures [35] zkLedger supports asset value amountsup to a trillion Range proofs are the most expensivepart of the transaction as described our scheme requirestwo range proofsmdashone for the commitment value andanother for the sum of assets in the column We cansquash the two range proofs down to one range proof byintroducing an auxiliary commitment cmprimei cmprimei is eithera re-commitment to the value in cmi or the sum of thevalues in the column up to row m sum

mk=0 vk which can be

achieved by computing the product of the commitmentsin the column prod

mk=0 cmk Then we can do one range

proof on the value in cmprimei Either this is the spendingbank in which case cmprimei must be a commitment to thesum or it is another bank which is receiving funds or notinvolved in which case cmprimei could be either (and it doesnot matter which it is)

This satisfies the financial invariants described aboveHowever a particular design choice we made in zkLedgeris that a spending bank can create a transaction spendingits own assets without interacting with other banks Thismeans that a malicious bank could create transactionswhich maintain financial invariants but are ill-formed Wewill address this problem after describing how auditingworks

Once created a bank broadcasts the transaction andit will be appended to the ledger If the banks are main-taining the ledger each bank is responsible for validatingthe transaction before accepting it to the ledger If a thirdparty is maintaining the ledger then the third party shouldverify the proofs in a transaction before accepting it

Example transaction Figure 2 shows a transactionwhere Bank of America is transferring one million eurosto Goldman Sachs Bank of America creates the transfer

transaction publishing the transaction id timestamp andasset type (euros) publicly Bank of America commits tothe amount deducted from its own assets minus1000000in its own entry and 1000000 in Goldman Sachsrsquos en-try For every other bank Bank of America commits to0 This serves to hide the banks involved in the transferno one except Bank of America can distinguish betweenthe commitments to determine which are commiting tononzero values Bank of America then broadcasts thetransaction to the ledger The ledger maintainer validatesthe transaction and appends it to the ledger Once ac-cepted to the ledger this serves as a complete transferof 1000000 euros from Bank of America to GoldmanSachs

42 Auditing ProtocolThe Auditor has a copy of the ledger and interacts withthe banks to calculate functions on their private data inorder to get a view of the financial system represented bythe ledger

The Auditor audits Banki by issuing a query to Bankifor example ldquoHow many euros do you hold at time trdquoBanki responds to the auditor with an answer and a proofthat the answer is consistent with the transactions on theledger The Auditor multiplies the commitments on theledger in Bankirsquos column for euros and verifies the proofand answer with the total This is a commitment to thethe total amount of euros Banki holds

The key insight here is that given this table constructionthe Auditor can read bank irsquos column and know that itis seeing every asset transfer involving i There is noway for i to ldquohiderdquo assets on the ledger without actuallytransferring assets and giving control to another bank Incontrast during a traditional audit a bank could simplynot show the auditor some of its balance sheet

Banks could collude to hold assets for each other tem-porarily for example Bank j might transfer assets toBanki and take them back later For that time periodthe assets would be part of Bankirsquos holdings But bankscannot collude after an Auditor poses a query becausethe Auditor has already specified the time t at which thequery applies Any transfer would necessarily have to beafter t So at this point it is too late for a malicious bankto create a new transaction transferring assets to anotherbank

As described above a bank can create a transactiontransferring its own assets without any interaction Thisis common with most blockchain systems where onlythe signature of the sender is required to create a validtransaction There is no in-protocol way for a receiver toobject to a transfer Given our table construction everybank is affected by every transaction because a bank must

USENIX Association 15th USENIX Symposium on Networked Systems Design and Implementation 71

Metadata Bank1 Bank2 Bank3 BanknID Asset Time (Bank of America) (Goldman Sachs) (JPMorgan) (Citigroup)

1 e 130601 COMM(minus106r1) COMM(106r2) COMM(0r3) middot middot middot COMM(0rn)21718 Token1 Token2 Token2 middot middot middot Tokenn

πA1 π

B1 π

C1 πA

2 πB2 π

C2 πA

3 πB3 π

C3 middot middot middot πA

n πBn π

Cn

Figure 2 Contents of the ledger pertaining to a transaction that sends 106 euros from Bank1 to Bank2 Note that while asset type (euro) is visibleas part of the metadata the transaction amount (106 e) and participating institutions (Bank of America and Goldman Sachs) remain private Weuse Pedersen commitments so the commitment part of the row has values gminus106

hr1 g106hr2 and hr3 hrn Similarly audit tokens pictured

have values (pk1)r1 (pk2)

r2 For each bank Banki the corresponding column also includes proof-of-assets πAi proof-of-balance πB

i andproof-of-consistency πC

i

total all of the commitments in its column to respond tothe Auditormdasheven commitments for transactions in whichit was not involved A malicious Banki could create atransaction and not inform the another Bank j of the r jused in its entry even if it is not transferring assets toBank j Bank j would be unable to respond to the Auditorbecause it would not be able to open up the product of thecommitments in its column

In order to prove the integrity of a transfer transactionzkLedger must ensure an additional invariant

bull All banks have enough information in the transactionto open up commitments for the Auditor

zkLedger does this by requiring the spending bank toinclude a publicly verifiable Token in every entry Thisis defined as Tokenk = (pkk)

rk Bankk uses this token toopen up the product of its commitments for the Auditorwithout needing to know rkUsing audit tokens Consider a query for a sum of valuesin a bankrsquos column One way of answering this querywould be to reveal sumvk and sumrk Then the auditor wouldsimply check that these plain values are consistent withthe homomorphically computed value prodcmk = gsumvk hsumrk

However a bank does not necessarily know all thecommitment randomnesses rk (in particular these valuesare unknown for any transaction that the bank was notparty to) so the naive approach does not work

One approach could be to ask the preparer of the trans-action (ie the sender) to encrypt rk so that the non-participating bank Bankk can decrypt it To prevent thesending bank from placing a ldquogarbagerdquo ciphertext on theledger (and thus making Bankk fail the auditorrsquos queries)one would need a zero-knowledge proof of consistencybetween the encrypted value and the commitment Con-structing a concretely efficient proof for this statement isnon-trivial in a nutshell standard encryption schemes(eg ElGamal) embed plain-text in a group element whilePedersen commitments would have this value in the expo-nent

Our insight is that Bankk does not need to open sumrkto prove that sumvk is correct Instead suppose that Bankk

wants to claim that s = gsumvk hsumrk opens up to a valuesumvk To do so the bank computes sprime = sgsumvk = hsumrk andt = prodk Tokenk = hsksumrk Note that the auditor can alsocompute the values of sprime and t from the ledger and theclaimed answer sumvk

It suffices for the bank to prove that logsprime t = logh pkObserve that both logarithms evaluate to sk so a bank canproduce this proof without knowing sumri Moreover ifthis equation holds then t1sk = sprime = sgsumv but if the sumvwas incorrect then knowledge of sk would reveal a linearrelationship between g and h which is ruled out by oursecurity assumption

To show that the r in the Tokenk is the same as ther in rk we require an additional Proof of Consistency(πC) This is a zero-knowledge proof asserting that foreach k the value rk used to form cmk and Tokenk is thesame (See Appendix B for details of how such proof isconstructed)

Note that audit tokens are only useful to the bank open-ing its commitment though public a malicious bankcannot use another bankrsquos Token to successfully open anincorrect result or learn information about other bankrsquostransactions

43 Final transaction constructionFor a transfer transaction in row m each entry i containsthe following itemsbull Commitment (cmi) (gvihri) a Pedersen commitment

to the value we are transferringbull Audit Token (Tokeni) (pki)

ri This is used to answeraudits without knowing the randomness used in thecommitment

bull Proof of Balance (πB) a zero-knowledge proof assert-ing that the committed values satisfy sum

nk=1 vk = 0

bull Proof of Assets (πA) a new commitment cmprimei corre-sponding token Tokenprimei and a zero-knowledge proofasserting that either cmprimei is a re-commitment of thevalue in cmi or a recommitment to the sum of the val-ues in prod

mj=0 cm j and cmprimei is in range [0240) If the

committed value in cmi is negative the proof assertsbank i consented to the transfer

72 15th USENIX Symposium on Networked Systems Design and Implementation USENIX Association

bull Proof of Consistency (πC) two zero-knowledgeproofs asserting the randomness used in cmi and Tokeniare the same and the randomness used in cmprimei andTokenprimei are the same This is to prevent a maliciousbank from adding data to the ledger that would stopanother bank from being able to open its commitmentsfor the AuditorTransactions may contain additional metadata in plain-

text or not For example banks might want to includeencrypted account numbers addresses or identifying in-formation on behalf of a customer to satisfy the TravelRule specified in the Bank Secrecy Act of 1970 [1] zk-Ledger supports auditing over metadata in the transactionas well but it does not have a way to publicly verifyadditional metadata

44 Adding or removing bankszkLedger can support dynamically adding or removingbanks if done so publicly The participants (or anotherauthority) append a signed transaction to the ledger indi-cating which banks and thus columns should be addedor removed For example to add a new bank to theledger shown in Figure 2 the involved banks would ap-pend a transaction to the ledger indicating an intent toadd Bankn+1 From that point forward all transactionsshould contain n+ 1 entries The Proof of Assets forBankn+1rsquos entry in each transaction will start at the rowwhere Bankn+1 was added Similarly if a bank is re-moved later transactions should not include entries forthat bank Since all participants can see which bankswere added or removed they can adjust their proofs andverifications accordingly

45 OptimizationszkLedger employs several optimizations to make produc-ing and verifying these proofs faster and to support fasterauditing First caching the product of the commitmentsin a bankrsquos column improves auditing and proof creationspeed Each bank stores a rolling product of commitmentsby row and by asset so that it can quickly produce proofsof assets and answer queries from auditors Using thesecaches a bank can quickly answer an auditorrsquos query ona subset of rows in the ledger

Most transactions in zkLedger do not include everybank Every bank can pre-generate many range proofsfor the value 0 We speedup transaction throughput byparallelizing range proof generation and validation

5 AuditingAuditing is a critical component of the financial systemand regulators use various techniques to measure systemicfinancial risk Through the use of sums means ratios

variance co-variance and standard deviation an auditorin zkLedger can determine the following among othermeasurementsbull Leverage ratios zkLedger can show how much of an

asset a bank has on its books compared to its otherholdings This is helpful to estimate counterparty risk

bull Concentration Regulators use a measure called theHerfindahl-Hirschman Index (HHI) to measure howcompetitive an industry is [29]

bull Real-time price indexes Auditors can get a sense ofthe price of assets that are traded over-the-counter andthus not tracked through exchangesNatively zkLedger supports sums which means linear

combinations of values stored in the ledger This comesfrom the additive structure of Pedersen commitmentsBut zkLedger also supports a more general query modelwhich can be considered in two parts A map step and areduce stepBasic auditing Consider the basic example where anauditor wants to determine how much of an asset a bankhas on its books As described in sect42 the auditor willfilter the rows by asset multiply the entries in the bankrsquoscolumn and then ask the bank to open the commitmentproduct This only requires one round of communica-tion between the auditor and the bank and the messagesare a constant size independent of the number of rowsBecause of zkLedgerrsquos commitment caches this is veryfastMapreduce An auditor can issue more complex queriesthat might require the exchange of more data or mightrequire the participants to look at most of the rows in theledger Letrsquos consider an auditor which wants to know themean transaction size for a given bank and asset An au-ditor cannot verify a bankrsquos answer by simply totaling thebankrsquos column of commitments and dividing the openedvalue by the number of rows because such a computationwould have an incorrect denominator Namely when thebank is not involved in a transaction its column in therow will be commitment to 0 and should be discountedIn order to determine the correct denominator the auditorand the bank run the following protocol1 Filter The bank will filter the rows by asset2 Produce new commitments For each row the bank

will commit to a single bit b 1 or 0 depending on ifthe bank was involved in the transaction or not and cre-ate a proof that the bank has done this recommitmentcorrectly Crucially the auditor cannot distinguishbetween these commitments and so the bankrsquos trans-actions are not revealed We call this act of producingnew commitments the map step The map step alsorequires producing proofs that the new values were

USENIX Association 15th USENIX Symposium on Networked Systems Design and Implementation 73

correctly computed in our example for each transac-tion the bank would produce a NIZK proof that b = 1if and only if the transaction value was not equal to 0

3 Compute number of non-zero transactions Thebank computes the homomorphic sum of the new com-mitments to bits~b and opens it to reveal how manytransactions were non-zero This is the reduce stepThis is the correct denominator to compute the meantransaction size The auditor cannot tell anything aboutthe values in~b beyond what is revealed by the sum

4 Respond to auditor The bank then sends the auditorthe sum of the values in its column the vector of bitcommitments and corresponding NIZK proofs thenumber of its non-zero transactions n and the sum ofthe r values in the commitments

5 Verification The auditor verifies the map step byverifying the commitments were done correctly andverifies the reduce step and the number of non-zerotransactions by confirming that the product of the vec-tor of bit commitments is gnhsum

Nk=1 rk

6 Compute answer The auditor computes the meanfrom the sum of the bankrsquos column and the number ofnon-zero transactionsAn auditor could ask a bank for outlier transactions

using a similar technique For each row the bank willcommit to a bit b where b = 1 if a transactionrsquos value forthat bank is outside a specified range As when computingthe mean the auditor can verify these commitments wereproduced correctly and obtain the sum The bank can thenopen only the transactions where b = 1 and the auditorknows exactly how many transactions should be opened

More complex auditing queries require multiple mapand reduce computations For example here is howan auditor can learn the variance of transaction valuesv1 vN

1 Compute the average transaction value Executethe protocol described above to compute the numberof non-zero transactions n and their average value v

2 Apply the squaring map For each entry vi in its rowthe bank produces a fresh commitment cmprimei to v2

i andsends these commitments to the auditor The bank alsosupplies NIZK proofs that the value hidden in eachcmprimei is exactly the square of the value vi committed toon the ledger

3 Apply the reduce step The auditor computes theproduct of the commitments cmprimei and the bank opensup this commitment as V = v2

1 + middot middot middot+ v2N by revealing

R = sumNi=1 ri The auditor confirms that the product of

the commitments is equal to gV hR

The auditor now computes the variance σ as followsσ2 = 1

n sumvi 6=0(viminus v)2 = 1nV minus v2

We note that whereas the square mapping used abovecorresponds to the second moment (variance) zkLedgercan also compute higher statistical moments (eg skew-ness and kurtosis) using similar techniques and usingcubing and fourth power mappings respectively See Ap-pendix A for a list of measurements zkLedger supports

zkLedger can support limited information release byusing more complex reduce mappings For example in-stead of releasing the sum of values the bank can producea commitment to the rounded sum of values (eg to thefirst two decimal places) and use range proofs also im-plemented in zkLedger to show that the rounding wasdone correctly Revealing just the order of magnitude ofthe quantity at hand lets the parties balance the granularityof information disclosure6 ImplementationTo evaluate zkLedgerrsquos design we implemented a pro-totype of zkLedger in Go Our prototype uses a modi-fied version of the btcec library [2] that contains the pa-rameters and methods to compute with the elliptic curvesecp256k1 We use Gorsquos built-in SHA-256 implementa-tion for our cryptographic hash function and determin-istically pick g and h by applying point decompressionto the ldquonothing-up-my-sleeverdquo strings SHA256(0) andSHA256(1) Our prototype consists of approximately3200 lines of code of which 40 implement crypto-graphic tools used by zkLedger (zero-knowledge proofsrange proofs etc)

The implementation of the curve in zkLedger uses GorsquosbigInt type which we make no effort to compress orserialize in an efficient way A more optimized imple-mentation could compress curve points Our range proofsimplement the protocol used in Confidential Assets [42]Our NIZKs are based on Generalized Schnorr Proofswhich are three move interactive protocols to make themnon-interactive we apply the Fiat-Shamir heuristic [26]where we instantiate the random oracle using the SHA-256 hash function Our prototype implementation doesnot implement the complex queries described in sect5 andthus we do not evaluate them in sect7

7 EvaluationOur evaluation answers the following questionsbull How expensive is it to store prove and verify the differ-

ent proofs in zkLedger (sect72)bull How does auditing scale with the size of the ledger

(sect73)bull How does zkLedger scale with the number of banks

(sect74)

74 15th USENIX Symposium on Networked Systems Design and Implementation USENIX Association

Component Create Verify Size

2k Commitment 05 ms 05 ms 64 B2k Consistency 07 ms 08 ms 224 Bk Disjunctive 09 ms 09 ms 288 Bk Range 47 ms 35 ms 3936 B

Table 1 Number of each proof component in a transaction for k banksSize of and time to create and verify the components with 12 cores Therange proof create and verify benefit from the additional cores

71 Experimental setup

Microbenchmarks We run microbenchmarks on a 12core Intel machine with i7-X980 333 GHz CPUs and24GB of RAM running 64-bit Linux 440 on Ubuntu16043 Each microbenchmark runs the same code aBank runs to create and validate transactions

Distributed experiment We run the distributed experi-ments on a set of 12 virtual machines each with 4 cores ofIntel Xeon E5-2640 25 GHz processors 24GB of RAMand the same software setup as above There is one au-ditor one server providing the service of the ledger anda varying number of banks one per server Servers com-municate using the netrpc Go package over TCP Allexperiments use Go version 19

72 Proof overhead in zkLedgerTable 1 shows the time to prove and verify the proofs in atransaction in zkLedger There are two commitments twoconsistency proofs and one each of the disjunctive andrange proofs in a transaction entry There is a transactionentry per Bank Table 1 also shows the sizes of the variousproofs in bytes These sizes are estimated based on thesize of the underlying fields in the struct in memorythese proofs could be further compressed Range proofsdominate the size of the transactions

The left graph in Figure 3 shows the time it takes tocreate and verify a transaction varying the number ofoverall banks which increases the number of entries pertransaction This indicates that as we increase the numberof banks both transaction creation and verification timesper bank increase linearly but parallelization helps Prov-ing and validating range proofs dominates transactioncreation and verification but this cost is also highly paral-lelizable 12 cores gives a 28times speedup when creating atransaction with 20 banks a bank can create or validate atransaction for up to 20 banks in less than 200ms

As described in sect41 zkLedger uses Borromean ringsignatures to prove that a value is in a certain range andsupports values up to 240 Reducing the supported rangeof values would reduce range proof cost since that cost islinear in the number of bits in the size of the range Thereare also newer proof systems such as Bulletproofs which

might create much smaller range proofs [13] We plan toevaluate zkLedger with Bulletproofs in future work

73 Cost of auditing ledgersThe left graph in Figure 4 shows that for certain func-tions the time to audit is independent of the number oftransactions in the ledger This is because the Auditorand Banks maintain commitment caches which alreadyhave the commitment product necessary to prove to theauditor the sum of the values in its column The auditfunction is measuring the Herfindhal-Hirschman Indexso the auditor communicates with each bank

When the auditor cannot use a commitment cache per-haps because it was offline it must process the wholeledger to compute the commitment product This alsoapplies to more complex auditing like the types describedin sect5 when the auditor has to verify recommitments forevery row in the ledger These costs are shown in themiddle graph in Figure 4 This graph shows how long ittakes the auditor to compute the Herfindahl-HirschmanIndex on a ledger of varying sizes without using the com-mitment caches so the auditor must process every row ofthe ledger In these measurements the auditor does notverify each row As expected this time increases linearlywith the number of rows This indicates that maintainingcommitment caches is important for real-time auditingHowever even without commitment caches auditing timeis reasonable 35 seconds for 100K transactions Thissuggests the complex auditing queries in which the au-ditor computes a similar set of operations per row willalso be on the order of many seconds zkLedger currentlyonly maintains commitment product caches per asset perbank but could maintain more

For a fixed size ledger this audit function costs orderthe number of banks The right graph in Figure 4 demon-strates the auditing costs of computing the Herfindahl-Hirschman Index on a ledger of 2000 transactions as wevary the number of banks both with and without com-mitment caches The auditor audits the banks in parallelAuditing cost for this function grows slightly with thenumber of banks since more banks increase the variabil-ity in parallel auditing and the auditor must wait for thelast bank to respond before computing the final answer

In these figures each point is the mean of running theauditing query 20 times with error bars representing onestandard deviation from the mean

74 Scaling with more banksThere are two significant costs that grow with the numberof banks in zkLedger a serial step to create transactionsthat increases linearly and verifying transactions whichincreases quadratically with the number of banks As

USENIX Association 15th USENIX Symposium on Networked Systems Design and Implementation 75

0

100

200

300

400

500

600

2 4 6 8 10 12 14 16 18 20

Tim

e (

ms)

number of banks

verify-1create-1verify-12

create-12

0

200

400

600

800

1000

2 3 4 5 6 7 8 9 10

Tim

e (

ms)

number of banks

complete transactions

0

2

4

6

8

10

12

2 3 4 5 6 7 8 9 10

Th

rou

gh

pu

t (t

xn

ss

ec)

number of banks

all banks transactingone bank transacting

Figure 3 Transaction creation and verification time for one bank (left) varying the number of entries in the transaction Single-threaded andmulti-threaded performance with 12 threads Time to fully process a transaction including creation broadcast to ledger banks and auditor andverification by all parties (middle) Throughput (right) varying the number of banks

0

2

4

6

8

10

12

0K 20K 40K 60K 80K 100K

Au

ditin

g t

ime

(m

s)

Transactions in ledger

online auditor

0

500

1000

1500

2000

2500

3000

3500

0K 20K 40K 60K 80K 100K

Transactions in ledger

offline auditor

0

20

40

60

80

100

120

2 3 4 5 6 7 8 9 10

Number of banks

offline auditor

online auditor

Figure 4 Time to audit ledgers of different sizes (4 banks) and with a varying number of banks (2000 row ledger) Audit time is independent of thesize of the ledger (left) thanks to commitment caches maintained by the online auditor When commitment cache optimization is turned off (middle)the audit time is linear in the size of the ledger Audit time grows with the number of banks (right) and is much higher without commitment caches

described in sect41 a bank needs to use its entry fromtransaction nminus1 to create transaction n So though a bankcan use many cores to produce the proofs for a singletransaction in parallel multiple banks cannot producedifferent transactions in parallel In zkLedger banks startcreating transaction n before seeing nminus 1 but the bankcannot complete the transaction until nminus1 is accepted tothe ledger and verified causing an inherent bottleneck

The second major cost is around verification Everybank must verify every transaction so the more banksthe larger each transaction and thus the more work thatneeds to be done by each bank The middle graph inFigure 3 measures the time it takes one bank to createand all participants in zkLedger to completely processa transaction One bank creates a transaction and sendsit to the ledger which then broadcasts the transaction toall banks and an online auditor The auditor and everybank verify the transaction As we increase the numberof banks work increases quadratically however bankscan verify transactions in parallel so the time to processtransactions only increases linearly The right graph inFigure 3 shows that as we surmised zkLedgerrsquos through-put worsens with more banks The one bank transactingline in this graph is the same data as the middle graph

Since range proofs dominate the costs of transactioncreation and verification we are optimistic that a fasterrange proof implementation will directly improve perfor-mance zkLedgerrsquos current performance is comparableto Solidus a privacy-preserving distributed ledger whichachieves 3-4 transactions per second with online valida-tion but unlike zkLedger does not support auditing

8 Future workzkLedger focuses on providing provably correct auditingover private transaction data but zkLedger does not havea way to recover if the distributed ledger is corrupted Inthis case the parties maintaining the ledger would haveto come together to recreate historical transactions zk-Ledger also does not provide recourse if a bank commitsan unintended transaction to the ledger A future ver-sion of zkLedger might provide rectifying transactions orparticipant agreed-upon rollback

9 ConclusionzkLedger is the first distributed ledger system to providestrong transaction privacy public verifiability and com-plete provably correct auditing zkLedger supports a richset of auditing queries which are useful to measure thefinancial health of a market We developed a design usingnon-interactive zero-knowledge proofs to prove transac-tions maintain financial invariants and to support auditingOur evaluation shows that zkLedger has reasonable per-formance for transaction settlement and auditing

10 AcknowledgementsWe thank Alexander Chernyakhovsky Thaddeus DryjaDavid Lazar Ronald L Rivest CJ Williams and ourshepherd and reviewers for helpful comments The re-search leading to these results has received funding fromthe Center for Science of Information (CSoI) an NSFScience and Technology Center under grant agreementCCF-0939370 and the Ethics and Governance of Artifi-cial Intelligence Fund

76 15th USENIX Symposium on Networked Systems Design and Implementation USENIX Association

References[1] Bank secrecy act of 1970 October 1970 12 USC 103[2] Package btcec implements support for the elliptic curves

needed for Bitcoin July 2017 httpsgodocorggithubcombtcsuitebtcdbtcec

[3] ABBE E A KHANDANI A E AND LO A WPrivacy-preserving methods for sharing financial risk ex-posures The American Economic Review 102 3 (2012)65ndash70

[4] ARASU A BLANAS S EGURO K KAUSHIK RKOSSMANN D RAMAMURTHY R AND VENKATE-SAN R Orthogonal security with cipherbase In CIDR(2013)

[5] BAJAJ S AND SION R Trusteddb A trusted hardware-based database with privacy and data confidentiality IEEETransactions on Knowledge and Data Engineering 26 3(2014) 752ndash765

[6] BAUMANN A PEINADO M AND HUNT G Shieldingapplications from an untrusted cloud with haven ACMTransactions on Computer Systems (TOCS) 33 3 (2015)8

[7] BEN-SASSON E CHIESA A GENKIN D TROMERE AND VIRZA M SNARKs for C Verifying programexecutions succinctly and in zero knowledge In Advancesin CryptologyndashCRYPTO 2013 Springer 2013 pp 90ndash108

[8] BEN-SASSON E CHIESA A GREEN M TROMERE AND VIRZA M Secure sampling of public parametersfor succinct zero knowledge proofs In Proceedings of the2015 IEEE Symposium on Security and Privacy (2015)SP rsquo15 pp 287ndash304

[9] BLUM M FELDMAN P AND MICALI S Non-interactive zero-knowledge and its applications In Pro-ceedings of the 20th Annual ACM Symposium on Theoryof Computing (1988) STOC rsquo88 pp 103ndash112

[10] BOGDANOV D TALVISTE R AND WILLEMSON JDeploying secure multi-party computation for financialdata analysis In International Conference on FinancialCryptography and Data Security (2012) Springer pp 57ndash64

[11] BOWE S GABIZON A AND GREEN M A multi-party protocol for constructing the public parameters ofthe Pinocchio zk-SNARK Cryptology ePrint ArchiveReport 2017602 2017

[12] BOWE S GABIZON A AND MIERS I Scalable multi-party computation for zk-SNARK parameters in the ran-dom beacon model Cryptology ePrint Archive Report20171050 2017

[13] BUNZ B BOOTLE J BONEH D POELSTRA AAND MAXWELL G Bulletproofs Short proofs for Con-fidential Transactions and more In Security and Privacy(SP) 2018 IEEE Symposium on (2018) IEEE

[14] BURKHART M STRASSER M MANY D AND DIM-ITROPOULOS X Sepia Privacy-preserving aggregationof multi-domain network events and statistics Network 1101101 (2010)

[15] CASTRO M AND LISKOV B Practical byzantine faulttolerance In OSDI (1999) vol 99 pp 173ndash186

[16] CECCHETTI E ZHANG F JI Y KOSBA A JUELSA AND SHI E Solidus Confidential distributed ledgertransactions via pvorm

[17] CHAIN I Confidential assets httpsblogchaincomhidden-in-plain-sight-transacting-privately-on-a-blockchain-835ab75c01cb

[18] CORRIGAN-GIBBS H AND BONEH D Prio Privaterobust and scalable computation of aggregate statisticsarXiv preprint arXiv170306255 (2017)

[19] COUNCIL F R Developments in audit 20162017full report 2017 httpwwwfrcorgukgetattachment915c15a4-dbc7-4223-b8ae-cad53dbcca17Developments-in-Audit-2016-17-Full-reportpdf

[20] CRAMER R DAMGARD I AND SCHOENMAKERSB Proofs of partial knowledge and simplified design ofwitness hiding protocols In Advances in Cryptology -CRYPTO rsquo94 14th Annual International Cryptology Con-ference Santa Barbara California USA August 21-251994 Proceedings (1994) pp 174ndash187

[21] DAGHER G G BUNZ B BONNEAU J CLARK JAND BONEH D Provisions Privacy-preserving proofsof solvency for Bitcoin exchanges In Proceedings of the22nd ACM SIGSAC Conference on Computer and Com-munications Security (Denver CO 2015) ACM pp 720ndash731

[22] Corda 2017 httpsgithubcomcordacorda

[23] Digital asset holdings 2017 httpdigitalassetcom

[24] Regulation (EU) 2016679 of the European Parliamentand of the Council of 27 April 2016 on the protection ofnatural persons with regard to the processing of personaldata and on the free movement of such data and repealingDirective 9546EC (General Data Protection Regulation)Official Journal of the European Union L119 (May 2016)1ndash88

[25] FELDMAN A J ZELLER W P FREEDMAN M JAND FELTEN E W Sporc Group collaboration us-ing untrusted cloud resources In OSDI (2010) vol 10pp 337ndash350

[26] FIAT A AND SHAMIR A How to prove yourselfpractical solutions to identification and signature problemsIn Proceedings of the 6th Annual International CryptologyConference (1987) CRYPTO rsquo87 pp 186ndash194

[27] GARMAN C GREEN M AND MIERS I Accountableprivacy for decentralized anonymous payments Cryp-tology ePrint Archive Report 2016061 2016 httpeprintiacrorg2016061

[28] GREENBERG A Fbi says itrsquos seized $285 million inbitcoins from ross ulbricht alleged owner of silk roadForbes 25 (2013)

USENIX Association 15th USENIX Symposium on Networked Systems Design and Implementation 77

Use Commitment 13Cache to prove answer13

013 $13113 euro13213 $13

TX DB13

Commitment Cache13

Bank of America13

130558 2171813

130559 2171813

130601 2171813

Add transaction13Notify of new transaction13

Determine 13trade 13

details13

Commitment Cache13

Auditor13

Notify of new transaction13

TX DB13

Commitment Cache13

JPMorgan13

Respond to Audit13 Audit13

Use Commitment 13Cache to verify audit13

Bank of America13 Goldman Sachs13 JP Morgan13

transaction commitments and proofs13

Figure 1 Overall zkLed-ger system design showingthe interactions between thethree main entities (banksauditor and the sharedledger) in our system Eachbank maintains private stateconsisting of the transactiondatabase for transactions thebank originated and thebankrsquos secret key

two commitments to values v1 and v2 using commitmentrandomness r1 and r2 respectively then cm = cm1 middotcm2is a commitment to v1 + v2 using randomness r1 + r2 ascm=(gv1hr1) middot(gv2hr2)= gv1+v2 hr1+r2 To speed up trans-action generation and auditing zkLedger makes extensiveuse of the ability to additively combine commitments

Public-key encryption Every bank i also generates aSchnorr signature keypair keypair consisting of a secretkey ski and public key pki = hski and distributes thepublic key pki to all other system participants

Non-interactive zero-knowledge proofs To makeprivacy-preserving assertions about payment details zk-Ledger relies on non-interactive zero-knowledge proofs(NIZKs) [9] In brief zero-knowledge proofs concerntwo parties the prover who holds some private data andthe verifier who wishes to be convinced of some propertyabout this private data For example the prover mightknow the opening of a commitment cm and wish to con-vince the verifier that the committed value v is in somerange eg 0 le v lt 106 Using NIZKs the prover canproduce a binary string π the proof that simultaneouslypersuades the verifier yet does not reveal anything elseabout v Verifying π does not require any interactionbetween the prover and the verifier and the prover canappend π to the ledger where it can be verified by anyparty of the system

In theory NIZK proof systems exist for all propertiesin NP whereas the practical feasibility of NIZKs is highly-dependent on the complexity of the property at hand Inparticular algebraic properties in cyclic groups such asknowledge of discrete logarithm equality of values com-mitted in Pedersen commitments or similar have veryefficient NIZK proof systems The design of zkLedger iscarefully structured so that all NIZK proofs have particu-larly efficient constructions

33 Security GoalsThe goals of zkLedger are to hide the amounts partici-pants and links between transactions while maintaining averifiable transaction ledger and for the Auditor to receivereliable answers to its queries Specifically zkLedger letsbanks issue hidden transfer transactions which are stillpublicly verifiable by all other participants every partici-pant can confirm a transaction conserves assets and assetsare only transferred with the spending bankrsquos authorityFor example if Banki transfers 10000 C to Bank j boththe banks and amount are hidden The asset (C) and timeof the transaction are not hidden zkLedger also hides thetransaction graph meaning which previous transaction(s)supplied the 10000 C to Banki in the first place

An Auditor can query a Bank about its contents on theledger for example ldquoHow many euros does Bank j holdrdquoA bank should be able to produce commitments whichwill convince the auditor that the bankrsquos answer to theauditing query is correct meaning consistent with thetransactions on the ledger zkLedger ensures that if a bankgives the Auditor an answer that is inconsistent with theledger the Auditor will catch such attempt of cheatingwith high probability (and of course a trustworthy answermust always be accepted)

34 Threat modelzkLedger does not assume that banks will behavehonestlymdashthey can attempt to steal assets hide assetsmanipulate their account balances or lie to auditors Weassume banks can arbitrarily collude zkLedger keeps theamounts and participants of transactions private as longas neither the spender nor receiver in a transaction colludewith an observer like the Auditor We assume that theledger does not omit transactions and is available zkLed-ger does not protect against an adversary who observestraffic on the network for example if only two banksare exchanging messages itrsquos reasonable to assume thetransactions in the ledger involve those banks Nothing

USENIX Association 15th USENIX Symposium on Networked Systems Design and Implementation 69

beyond what is necessarily leaked by an audit is revealedHowever frequent auditing might reveal transaction con-tents eg if an auditor asks for banksrsquo assets after everytransaction

4 DesignThe challenge in creating zkLedger is to practically sup-port complete confidential auditingmdashan Auditor shouldnot be able to see individual bank transactions but a Bankshould not be able to hide assets from the Auditor dur-ing an audit and the auditor should be able to detect anincorrect answer

Figure 1 shows a general overview of zkLedger Thereare banks which determine transactions out of band andthen settle them by appending transactions to the ledgerThe ledger makes sure all banks and any auditors seenew transactions Each bank and auditor maintains acommitment cache which are commitments to summedvalues used to make creating transactions and respondingto audits faster Each bank also has private stores of plain-text transaction data

The rest of this section describes the zkLedger trans-action format how banks create transactions and how abank can answer a simple query from the auditor

41 TransactionsThe ledger in zkLedger is a table where transactions cor-respond to rows and Banks correspond to columns Eachtransaction has an entry for each Bank Figure 2 shows aledger with n banks Each entry in a transaction includesa commitment to a value which is the amount of the assetthat is being debited or credited to the bank For exam-ple if Banki wants to transfer 100 shares of an asset toBank j irsquos entry in the transaction would contain a com-mitment to -100 and jrsquos would contain a commitment to100 All other entries in the transaction would containcommitments to 0 since none of the other bank balanceswere changed This scheme has the nice property thatan outside observer can look at a bankrsquos entire columnand know that this represents the entirety of the bankrsquosholdings

Hiding amounts As described in sect32 zkLedger doesnot include the value in plain-text in the transaction In-stead zkLedger uses Pedersen commitments to committo the value in transfer transactions This makes valuecommitments completely indistinguishablemdashan outsideobserver cannot tell the difference between a commitmentto a positive value a negative value or 0 Recall that acommitment to a value v is cm = COMM(vr) = gvhrIf desired a prover can reveal v and r to a verifier whoknows cm and the verifier can confirm this is consistent

Since a transaction in zkLedger contains an entry forevery Bank there is a size-n vector ~cm committing tovalues in ~v Each commitment cmk uses a fresh com-mitment randomness rk Most of the entries will containcommitments to 0 for banks that are not involved with thetransaction but this is not apparent to an outside observer

zkLedger maintains the following financial invariants

bull A transfer transaction cannot create or destroy assets

bull The spending bank must give consent to the transferand must actually own enough of the particular asset toexecute this transaction

In a public blockchain the validators could simplyconfirm that these things are true by looking at the historyof transactions and the current transaction and makingsure the spending bank has the funds to spend Howeverin zkLedger these values are not public Instead wecreate a set of proofs that the spender can create to provethe invariants are maintained The spender can createa transaction without interacting with any of the otherbanks

First zkLedger introduces a Proof of Balance (πB)This is a proof that the transaction conserves assets noassets are created or destroyed (of course public is-suance and withdrawal transactions do not have suchproofs) More formally the committed values shouldsatisfy sum

nk=1 vk = 0 To prove this the prover chooses the

rk carefully it should also be the case that sumnk=1 rk = 0

If this is true and the values also sum to 0 then the ver-ifier can check to make sure that prod

nk=1 cmk = 1 for the

commitments in the rowNext zkLedger must ensure that the spending bank

actually has the assets to transfer To do this zkLedger in-troduces a Proof of Assets (πA) Other privacy-preservingblockchain systems use Unspent Transaction Outputsor UTXOs to show proof of assets and prevent doublespending For example if Alice wants to send a coin toBob she chooses one of her coins creates a new trans-action addressing the coin to Bob and includes a pointerto the previous transaction where she received the coinThis previous transaction is an output All of the valida-tors in the system maintain the invariant that outputs canonly be spent once Unfortunately in systems without zk-SNARKs this leaks the transaction graph In zkLedger abank proves it has assets by creating a commitment to thesum of the values for the asset in its column includingthis transaction If the sum is greater than or equal to 0then the bank has assets to transfer Note that this is truesince the bankrsquos column represents all the assets it hasreceived or spent and the Pedersen commitments can behomomorphically added in columns as well as in rows In

70 15th USENIX Symposium on Networked Systems Design and Implementation USENIX Association

order to produce a proof with the correct sum the bankmust have seen every previous transaction This impliesthat banks must create transactions serially In its ownentry where the value is negative the bank includes proofof knowledge of secret key to show that it authorized thetransaction This requires creating a disjunctive proofmdasheither the committed value for entry i has vi ge 0 or thecreator of the transaction knows the secret key for Banki

Range proofs Because commitment values are in anelliptic curve group and rely on modulus we need to makesure that the commited values are within an acceptablerange To see why note that if N is the order of thegroup then COMM(vr) = COMM(v+Nr) there is noway to distinguish between the two Without a checkto make sure the commited value is within the range[0N minus 1] a malicious bank could undetectably createassets To address this we use range proofs as describedin Confidential Assets [42] which uses Borromean ringsignatures [35] zkLedger supports asset value amountsup to a trillion Range proofs are the most expensivepart of the transaction as described our scheme requirestwo range proofsmdashone for the commitment value andanother for the sum of assets in the column We cansquash the two range proofs down to one range proof byintroducing an auxiliary commitment cmprimei cmprimei is eithera re-commitment to the value in cmi or the sum of thevalues in the column up to row m sum

mk=0 vk which can be

achieved by computing the product of the commitmentsin the column prod

mk=0 cmk Then we can do one range

proof on the value in cmprimei Either this is the spendingbank in which case cmprimei must be a commitment to thesum or it is another bank which is receiving funds or notinvolved in which case cmprimei could be either (and it doesnot matter which it is)

This satisfies the financial invariants described aboveHowever a particular design choice we made in zkLedgeris that a spending bank can create a transaction spendingits own assets without interacting with other banks Thismeans that a malicious bank could create transactionswhich maintain financial invariants but are ill-formed Wewill address this problem after describing how auditingworks

Once created a bank broadcasts the transaction andit will be appended to the ledger If the banks are main-taining the ledger each bank is responsible for validatingthe transaction before accepting it to the ledger If a thirdparty is maintaining the ledger then the third party shouldverify the proofs in a transaction before accepting it

Example transaction Figure 2 shows a transactionwhere Bank of America is transferring one million eurosto Goldman Sachs Bank of America creates the transfer

transaction publishing the transaction id timestamp andasset type (euros) publicly Bank of America commits tothe amount deducted from its own assets minus1000000in its own entry and 1000000 in Goldman Sachsrsquos en-try For every other bank Bank of America commits to0 This serves to hide the banks involved in the transferno one except Bank of America can distinguish betweenthe commitments to determine which are commiting tononzero values Bank of America then broadcasts thetransaction to the ledger The ledger maintainer validatesthe transaction and appends it to the ledger Once ac-cepted to the ledger this serves as a complete transferof 1000000 euros from Bank of America to GoldmanSachs

42 Auditing ProtocolThe Auditor has a copy of the ledger and interacts withthe banks to calculate functions on their private data inorder to get a view of the financial system represented bythe ledger

The Auditor audits Banki by issuing a query to Bankifor example ldquoHow many euros do you hold at time trdquoBanki responds to the auditor with an answer and a proofthat the answer is consistent with the transactions on theledger The Auditor multiplies the commitments on theledger in Bankirsquos column for euros and verifies the proofand answer with the total This is a commitment to thethe total amount of euros Banki holds

The key insight here is that given this table constructionthe Auditor can read bank irsquos column and know that itis seeing every asset transfer involving i There is noway for i to ldquohiderdquo assets on the ledger without actuallytransferring assets and giving control to another bank Incontrast during a traditional audit a bank could simplynot show the auditor some of its balance sheet

Banks could collude to hold assets for each other tem-porarily for example Bank j might transfer assets toBanki and take them back later For that time periodthe assets would be part of Bankirsquos holdings But bankscannot collude after an Auditor poses a query becausethe Auditor has already specified the time t at which thequery applies Any transfer would necessarily have to beafter t So at this point it is too late for a malicious bankto create a new transaction transferring assets to anotherbank

As described above a bank can create a transactiontransferring its own assets without any interaction Thisis common with most blockchain systems where onlythe signature of the sender is required to create a validtransaction There is no in-protocol way for a receiver toobject to a transfer Given our table construction everybank is affected by every transaction because a bank must

USENIX Association 15th USENIX Symposium on Networked Systems Design and Implementation 71

Metadata Bank1 Bank2 Bank3 BanknID Asset Time (Bank of America) (Goldman Sachs) (JPMorgan) (Citigroup)

1 e 130601 COMM(minus106r1) COMM(106r2) COMM(0r3) middot middot middot COMM(0rn)21718 Token1 Token2 Token2 middot middot middot Tokenn

πA1 π

B1 π

C1 πA

2 πB2 π

C2 πA

3 πB3 π

C3 middot middot middot πA

n πBn π

Cn

Figure 2 Contents of the ledger pertaining to a transaction that sends 106 euros from Bank1 to Bank2 Note that while asset type (euro) is visibleas part of the metadata the transaction amount (106 e) and participating institutions (Bank of America and Goldman Sachs) remain private Weuse Pedersen commitments so the commitment part of the row has values gminus106

hr1 g106hr2 and hr3 hrn Similarly audit tokens pictured

have values (pk1)r1 (pk2)

r2 For each bank Banki the corresponding column also includes proof-of-assets πAi proof-of-balance πB

i andproof-of-consistency πC

i

total all of the commitments in its column to respond tothe Auditormdasheven commitments for transactions in whichit was not involved A malicious Banki could create atransaction and not inform the another Bank j of the r jused in its entry even if it is not transferring assets toBank j Bank j would be unable to respond to the Auditorbecause it would not be able to open up the product of thecommitments in its column

In order to prove the integrity of a transfer transactionzkLedger must ensure an additional invariant

bull All banks have enough information in the transactionto open up commitments for the Auditor

zkLedger does this by requiring the spending bank toinclude a publicly verifiable Token in every entry Thisis defined as Tokenk = (pkk)

rk Bankk uses this token toopen up the product of its commitments for the Auditorwithout needing to know rkUsing audit tokens Consider a query for a sum of valuesin a bankrsquos column One way of answering this querywould be to reveal sumvk and sumrk Then the auditor wouldsimply check that these plain values are consistent withthe homomorphically computed value prodcmk = gsumvk hsumrk

However a bank does not necessarily know all thecommitment randomnesses rk (in particular these valuesare unknown for any transaction that the bank was notparty to) so the naive approach does not work

One approach could be to ask the preparer of the trans-action (ie the sender) to encrypt rk so that the non-participating bank Bankk can decrypt it To prevent thesending bank from placing a ldquogarbagerdquo ciphertext on theledger (and thus making Bankk fail the auditorrsquos queries)one would need a zero-knowledge proof of consistencybetween the encrypted value and the commitment Con-structing a concretely efficient proof for this statement isnon-trivial in a nutshell standard encryption schemes(eg ElGamal) embed plain-text in a group element whilePedersen commitments would have this value in the expo-nent

Our insight is that Bankk does not need to open sumrkto prove that sumvk is correct Instead suppose that Bankk

wants to claim that s = gsumvk hsumrk opens up to a valuesumvk To do so the bank computes sprime = sgsumvk = hsumrk andt = prodk Tokenk = hsksumrk Note that the auditor can alsocompute the values of sprime and t from the ledger and theclaimed answer sumvk

It suffices for the bank to prove that logsprime t = logh pkObserve that both logarithms evaluate to sk so a bank canproduce this proof without knowing sumri Moreover ifthis equation holds then t1sk = sprime = sgsumv but if the sumvwas incorrect then knowledge of sk would reveal a linearrelationship between g and h which is ruled out by oursecurity assumption

To show that the r in the Tokenk is the same as ther in rk we require an additional Proof of Consistency(πC) This is a zero-knowledge proof asserting that foreach k the value rk used to form cmk and Tokenk is thesame (See Appendix B for details of how such proof isconstructed)

Note that audit tokens are only useful to the bank open-ing its commitment though public a malicious bankcannot use another bankrsquos Token to successfully open anincorrect result or learn information about other bankrsquostransactions

43 Final transaction constructionFor a transfer transaction in row m each entry i containsthe following itemsbull Commitment (cmi) (gvihri) a Pedersen commitment

to the value we are transferringbull Audit Token (Tokeni) (pki)

ri This is used to answeraudits without knowing the randomness used in thecommitment

bull Proof of Balance (πB) a zero-knowledge proof assert-ing that the committed values satisfy sum

nk=1 vk = 0

bull Proof of Assets (πA) a new commitment cmprimei corre-sponding token Tokenprimei and a zero-knowledge proofasserting that either cmprimei is a re-commitment of thevalue in cmi or a recommitment to the sum of the val-ues in prod

mj=0 cm j and cmprimei is in range [0240) If the

committed value in cmi is negative the proof assertsbank i consented to the transfer

72 15th USENIX Symposium on Networked Systems Design and Implementation USENIX Association

bull Proof of Consistency (πC) two zero-knowledgeproofs asserting the randomness used in cmi and Tokeniare the same and the randomness used in cmprimei andTokenprimei are the same This is to prevent a maliciousbank from adding data to the ledger that would stopanother bank from being able to open its commitmentsfor the AuditorTransactions may contain additional metadata in plain-

text or not For example banks might want to includeencrypted account numbers addresses or identifying in-formation on behalf of a customer to satisfy the TravelRule specified in the Bank Secrecy Act of 1970 [1] zk-Ledger supports auditing over metadata in the transactionas well but it does not have a way to publicly verifyadditional metadata

44 Adding or removing bankszkLedger can support dynamically adding or removingbanks if done so publicly The participants (or anotherauthority) append a signed transaction to the ledger indi-cating which banks and thus columns should be addedor removed For example to add a new bank to theledger shown in Figure 2 the involved banks would ap-pend a transaction to the ledger indicating an intent toadd Bankn+1 From that point forward all transactionsshould contain n+ 1 entries The Proof of Assets forBankn+1rsquos entry in each transaction will start at the rowwhere Bankn+1 was added Similarly if a bank is re-moved later transactions should not include entries forthat bank Since all participants can see which bankswere added or removed they can adjust their proofs andverifications accordingly

45 OptimizationszkLedger employs several optimizations to make produc-ing and verifying these proofs faster and to support fasterauditing First caching the product of the commitmentsin a bankrsquos column improves auditing and proof creationspeed Each bank stores a rolling product of commitmentsby row and by asset so that it can quickly produce proofsof assets and answer queries from auditors Using thesecaches a bank can quickly answer an auditorrsquos query ona subset of rows in the ledger

Most transactions in zkLedger do not include everybank Every bank can pre-generate many range proofsfor the value 0 We speedup transaction throughput byparallelizing range proof generation and validation

5 AuditingAuditing is a critical component of the financial systemand regulators use various techniques to measure systemicfinancial risk Through the use of sums means ratios

variance co-variance and standard deviation an auditorin zkLedger can determine the following among othermeasurementsbull Leverage ratios zkLedger can show how much of an

asset a bank has on its books compared to its otherholdings This is helpful to estimate counterparty risk

bull Concentration Regulators use a measure called theHerfindahl-Hirschman Index (HHI) to measure howcompetitive an industry is [29]

bull Real-time price indexes Auditors can get a sense ofthe price of assets that are traded over-the-counter andthus not tracked through exchangesNatively zkLedger supports sums which means linear

combinations of values stored in the ledger This comesfrom the additive structure of Pedersen commitmentsBut zkLedger also supports a more general query modelwhich can be considered in two parts A map step and areduce stepBasic auditing Consider the basic example where anauditor wants to determine how much of an asset a bankhas on its books As described in sect42 the auditor willfilter the rows by asset multiply the entries in the bankrsquoscolumn and then ask the bank to open the commitmentproduct This only requires one round of communica-tion between the auditor and the bank and the messagesare a constant size independent of the number of rowsBecause of zkLedgerrsquos commitment caches this is veryfastMapreduce An auditor can issue more complex queriesthat might require the exchange of more data or mightrequire the participants to look at most of the rows in theledger Letrsquos consider an auditor which wants to know themean transaction size for a given bank and asset An au-ditor cannot verify a bankrsquos answer by simply totaling thebankrsquos column of commitments and dividing the openedvalue by the number of rows because such a computationwould have an incorrect denominator Namely when thebank is not involved in a transaction its column in therow will be commitment to 0 and should be discountedIn order to determine the correct denominator the auditorand the bank run the following protocol1 Filter The bank will filter the rows by asset2 Produce new commitments For each row the bank

will commit to a single bit b 1 or 0 depending on ifthe bank was involved in the transaction or not and cre-ate a proof that the bank has done this recommitmentcorrectly Crucially the auditor cannot distinguishbetween these commitments and so the bankrsquos trans-actions are not revealed We call this act of producingnew commitments the map step The map step alsorequires producing proofs that the new values were

USENIX Association 15th USENIX Symposium on Networked Systems Design and Implementation 73

correctly computed in our example for each transac-tion the bank would produce a NIZK proof that b = 1if and only if the transaction value was not equal to 0

3 Compute number of non-zero transactions Thebank computes the homomorphic sum of the new com-mitments to bits~b and opens it to reveal how manytransactions were non-zero This is the reduce stepThis is the correct denominator to compute the meantransaction size The auditor cannot tell anything aboutthe values in~b beyond what is revealed by the sum

4 Respond to auditor The bank then sends the auditorthe sum of the values in its column the vector of bitcommitments and corresponding NIZK proofs thenumber of its non-zero transactions n and the sum ofthe r values in the commitments

5 Verification The auditor verifies the map step byverifying the commitments were done correctly andverifies the reduce step and the number of non-zerotransactions by confirming that the product of the vec-tor of bit commitments is gnhsum

Nk=1 rk

6 Compute answer The auditor computes the meanfrom the sum of the bankrsquos column and the number ofnon-zero transactionsAn auditor could ask a bank for outlier transactions

using a similar technique For each row the bank willcommit to a bit b where b = 1 if a transactionrsquos value forthat bank is outside a specified range As when computingthe mean the auditor can verify these commitments wereproduced correctly and obtain the sum The bank can thenopen only the transactions where b = 1 and the auditorknows exactly how many transactions should be opened

More complex auditing queries require multiple mapand reduce computations For example here is howan auditor can learn the variance of transaction valuesv1 vN

1 Compute the average transaction value Executethe protocol described above to compute the numberof non-zero transactions n and their average value v

2 Apply the squaring map For each entry vi in its rowthe bank produces a fresh commitment cmprimei to v2

i andsends these commitments to the auditor The bank alsosupplies NIZK proofs that the value hidden in eachcmprimei is exactly the square of the value vi committed toon the ledger

3 Apply the reduce step The auditor computes theproduct of the commitments cmprimei and the bank opensup this commitment as V = v2

1 + middot middot middot+ v2N by revealing

R = sumNi=1 ri The auditor confirms that the product of

the commitments is equal to gV hR

The auditor now computes the variance σ as followsσ2 = 1

n sumvi 6=0(viminus v)2 = 1nV minus v2

We note that whereas the square mapping used abovecorresponds to the second moment (variance) zkLedgercan also compute higher statistical moments (eg skew-ness and kurtosis) using similar techniques and usingcubing and fourth power mappings respectively See Ap-pendix A for a list of measurements zkLedger supports

zkLedger can support limited information release byusing more complex reduce mappings For example in-stead of releasing the sum of values the bank can producea commitment to the rounded sum of values (eg to thefirst two decimal places) and use range proofs also im-plemented in zkLedger to show that the rounding wasdone correctly Revealing just the order of magnitude ofthe quantity at hand lets the parties balance the granularityof information disclosure6 ImplementationTo evaluate zkLedgerrsquos design we implemented a pro-totype of zkLedger in Go Our prototype uses a modi-fied version of the btcec library [2] that contains the pa-rameters and methods to compute with the elliptic curvesecp256k1 We use Gorsquos built-in SHA-256 implementa-tion for our cryptographic hash function and determin-istically pick g and h by applying point decompressionto the ldquonothing-up-my-sleeverdquo strings SHA256(0) andSHA256(1) Our prototype consists of approximately3200 lines of code of which 40 implement crypto-graphic tools used by zkLedger (zero-knowledge proofsrange proofs etc)

The implementation of the curve in zkLedger uses GorsquosbigInt type which we make no effort to compress orserialize in an efficient way A more optimized imple-mentation could compress curve points Our range proofsimplement the protocol used in Confidential Assets [42]Our NIZKs are based on Generalized Schnorr Proofswhich are three move interactive protocols to make themnon-interactive we apply the Fiat-Shamir heuristic [26]where we instantiate the random oracle using the SHA-256 hash function Our prototype implementation doesnot implement the complex queries described in sect5 andthus we do not evaluate them in sect7

7 EvaluationOur evaluation answers the following questionsbull How expensive is it to store prove and verify the differ-

ent proofs in zkLedger (sect72)bull How does auditing scale with the size of the ledger

(sect73)bull How does zkLedger scale with the number of banks

(sect74)

74 15th USENIX Symposium on Networked Systems Design and Implementation USENIX Association

Component Create Verify Size

2k Commitment 05 ms 05 ms 64 B2k Consistency 07 ms 08 ms 224 Bk Disjunctive 09 ms 09 ms 288 Bk Range 47 ms 35 ms 3936 B

Table 1 Number of each proof component in a transaction for k banksSize of and time to create and verify the components with 12 cores Therange proof create and verify benefit from the additional cores

71 Experimental setup

Microbenchmarks We run microbenchmarks on a 12core Intel machine with i7-X980 333 GHz CPUs and24GB of RAM running 64-bit Linux 440 on Ubuntu16043 Each microbenchmark runs the same code aBank runs to create and validate transactions

Distributed experiment We run the distributed experi-ments on a set of 12 virtual machines each with 4 cores ofIntel Xeon E5-2640 25 GHz processors 24GB of RAMand the same software setup as above There is one au-ditor one server providing the service of the ledger anda varying number of banks one per server Servers com-municate using the netrpc Go package over TCP Allexperiments use Go version 19

72 Proof overhead in zkLedgerTable 1 shows the time to prove and verify the proofs in atransaction in zkLedger There are two commitments twoconsistency proofs and one each of the disjunctive andrange proofs in a transaction entry There is a transactionentry per Bank Table 1 also shows the sizes of the variousproofs in bytes These sizes are estimated based on thesize of the underlying fields in the struct in memorythese proofs could be further compressed Range proofsdominate the size of the transactions

The left graph in Figure 3 shows the time it takes tocreate and verify a transaction varying the number ofoverall banks which increases the number of entries pertransaction This indicates that as we increase the numberof banks both transaction creation and verification timesper bank increase linearly but parallelization helps Prov-ing and validating range proofs dominates transactioncreation and verification but this cost is also highly paral-lelizable 12 cores gives a 28times speedup when creating atransaction with 20 banks a bank can create or validate atransaction for up to 20 banks in less than 200ms

As described in sect41 zkLedger uses Borromean ringsignatures to prove that a value is in a certain range andsupports values up to 240 Reducing the supported rangeof values would reduce range proof cost since that cost islinear in the number of bits in the size of the range Thereare also newer proof systems such as Bulletproofs which

might create much smaller range proofs [13] We plan toevaluate zkLedger with Bulletproofs in future work

73 Cost of auditing ledgersThe left graph in Figure 4 shows that for certain func-tions the time to audit is independent of the number oftransactions in the ledger This is because the Auditorand Banks maintain commitment caches which alreadyhave the commitment product necessary to prove to theauditor the sum of the values in its column The auditfunction is measuring the Herfindhal-Hirschman Indexso the auditor communicates with each bank

When the auditor cannot use a commitment cache per-haps because it was offline it must process the wholeledger to compute the commitment product This alsoapplies to more complex auditing like the types describedin sect5 when the auditor has to verify recommitments forevery row in the ledger These costs are shown in themiddle graph in Figure 4 This graph shows how long ittakes the auditor to compute the Herfindahl-HirschmanIndex on a ledger of varying sizes without using the com-mitment caches so the auditor must process every row ofthe ledger In these measurements the auditor does notverify each row As expected this time increases linearlywith the number of rows This indicates that maintainingcommitment caches is important for real-time auditingHowever even without commitment caches auditing timeis reasonable 35 seconds for 100K transactions Thissuggests the complex auditing queries in which the au-ditor computes a similar set of operations per row willalso be on the order of many seconds zkLedger currentlyonly maintains commitment product caches per asset perbank but could maintain more

For a fixed size ledger this audit function costs orderthe number of banks The right graph in Figure 4 demon-strates the auditing costs of computing the Herfindahl-Hirschman Index on a ledger of 2000 transactions as wevary the number of banks both with and without com-mitment caches The auditor audits the banks in parallelAuditing cost for this function grows slightly with thenumber of banks since more banks increase the variabil-ity in parallel auditing and the auditor must wait for thelast bank to respond before computing the final answer

In these figures each point is the mean of running theauditing query 20 times with error bars representing onestandard deviation from the mean

74 Scaling with more banksThere are two significant costs that grow with the numberof banks in zkLedger a serial step to create transactionsthat increases linearly and verifying transactions whichincreases quadratically with the number of banks As

USENIX Association 15th USENIX Symposium on Networked Systems Design and Implementation 75

0

100

200

300

400

500

600

2 4 6 8 10 12 14 16 18 20

Tim

e (

ms)

number of banks

verify-1create-1verify-12

create-12

0

200

400

600

800

1000

2 3 4 5 6 7 8 9 10

Tim

e (

ms)

number of banks

complete transactions

0

2

4

6

8

10

12

2 3 4 5 6 7 8 9 10

Th

rou

gh

pu

t (t

xn

ss

ec)

number of banks

all banks transactingone bank transacting

Figure 3 Transaction creation and verification time for one bank (left) varying the number of entries in the transaction Single-threaded andmulti-threaded performance with 12 threads Time to fully process a transaction including creation broadcast to ledger banks and auditor andverification by all parties (middle) Throughput (right) varying the number of banks

0

2

4

6

8

10

12

0K 20K 40K 60K 80K 100K

Au

ditin

g t

ime

(m

s)

Transactions in ledger

online auditor

0

500

1000

1500

2000

2500

3000

3500

0K 20K 40K 60K 80K 100K

Transactions in ledger

offline auditor

0

20

40

60

80

100

120

2 3 4 5 6 7 8 9 10

Number of banks

offline auditor

online auditor

Figure 4 Time to audit ledgers of different sizes (4 banks) and with a varying number of banks (2000 row ledger) Audit time is independent of thesize of the ledger (left) thanks to commitment caches maintained by the online auditor When commitment cache optimization is turned off (middle)the audit time is linear in the size of the ledger Audit time grows with the number of banks (right) and is much higher without commitment caches

described in sect41 a bank needs to use its entry fromtransaction nminus1 to create transaction n So though a bankcan use many cores to produce the proofs for a singletransaction in parallel multiple banks cannot producedifferent transactions in parallel In zkLedger banks startcreating transaction n before seeing nminus 1 but the bankcannot complete the transaction until nminus1 is accepted tothe ledger and verified causing an inherent bottleneck

The second major cost is around verification Everybank must verify every transaction so the more banksthe larger each transaction and thus the more work thatneeds to be done by each bank The middle graph inFigure 3 measures the time it takes one bank to createand all participants in zkLedger to completely processa transaction One bank creates a transaction and sendsit to the ledger which then broadcasts the transaction toall banks and an online auditor The auditor and everybank verify the transaction As we increase the numberof banks work increases quadratically however bankscan verify transactions in parallel so the time to processtransactions only increases linearly The right graph inFigure 3 shows that as we surmised zkLedgerrsquos through-put worsens with more banks The one bank transactingline in this graph is the same data as the middle graph

Since range proofs dominate the costs of transactioncreation and verification we are optimistic that a fasterrange proof implementation will directly improve perfor-mance zkLedgerrsquos current performance is comparableto Solidus a privacy-preserving distributed ledger whichachieves 3-4 transactions per second with online valida-tion but unlike zkLedger does not support auditing

8 Future workzkLedger focuses on providing provably correct auditingover private transaction data but zkLedger does not havea way to recover if the distributed ledger is corrupted Inthis case the parties maintaining the ledger would haveto come together to recreate historical transactions zk-Ledger also does not provide recourse if a bank commitsan unintended transaction to the ledger A future ver-sion of zkLedger might provide rectifying transactions orparticipant agreed-upon rollback

9 ConclusionzkLedger is the first distributed ledger system to providestrong transaction privacy public verifiability and com-plete provably correct auditing zkLedger supports a richset of auditing queries which are useful to measure thefinancial health of a market We developed a design usingnon-interactive zero-knowledge proofs to prove transac-tions maintain financial invariants and to support auditingOur evaluation shows that zkLedger has reasonable per-formance for transaction settlement and auditing

10 AcknowledgementsWe thank Alexander Chernyakhovsky Thaddeus DryjaDavid Lazar Ronald L Rivest CJ Williams and ourshepherd and reviewers for helpful comments The re-search leading to these results has received funding fromthe Center for Science of Information (CSoI) an NSFScience and Technology Center under grant agreementCCF-0939370 and the Ethics and Governance of Artifi-cial Intelligence Fund

76 15th USENIX Symposium on Networked Systems Design and Implementation USENIX Association

References[1] Bank secrecy act of 1970 October 1970 12 USC 103[2] Package btcec implements support for the elliptic curves

needed for Bitcoin July 2017 httpsgodocorggithubcombtcsuitebtcdbtcec

[3] ABBE E A KHANDANI A E AND LO A WPrivacy-preserving methods for sharing financial risk ex-posures The American Economic Review 102 3 (2012)65ndash70

[4] ARASU A BLANAS S EGURO K KAUSHIK RKOSSMANN D RAMAMURTHY R AND VENKATE-SAN R Orthogonal security with cipherbase In CIDR(2013)

[5] BAJAJ S AND SION R Trusteddb A trusted hardware-based database with privacy and data confidentiality IEEETransactions on Knowledge and Data Engineering 26 3(2014) 752ndash765

[6] BAUMANN A PEINADO M AND HUNT G Shieldingapplications from an untrusted cloud with haven ACMTransactions on Computer Systems (TOCS) 33 3 (2015)8

[7] BEN-SASSON E CHIESA A GENKIN D TROMERE AND VIRZA M SNARKs for C Verifying programexecutions succinctly and in zero knowledge In Advancesin CryptologyndashCRYPTO 2013 Springer 2013 pp 90ndash108

[8] BEN-SASSON E CHIESA A GREEN M TROMERE AND VIRZA M Secure sampling of public parametersfor succinct zero knowledge proofs In Proceedings of the2015 IEEE Symposium on Security and Privacy (2015)SP rsquo15 pp 287ndash304

[9] BLUM M FELDMAN P AND MICALI S Non-interactive zero-knowledge and its applications In Pro-ceedings of the 20th Annual ACM Symposium on Theoryof Computing (1988) STOC rsquo88 pp 103ndash112

[10] BOGDANOV D TALVISTE R AND WILLEMSON JDeploying secure multi-party computation for financialdata analysis In International Conference on FinancialCryptography and Data Security (2012) Springer pp 57ndash64

[11] BOWE S GABIZON A AND GREEN M A multi-party protocol for constructing the public parameters ofthe Pinocchio zk-SNARK Cryptology ePrint ArchiveReport 2017602 2017

[12] BOWE S GABIZON A AND MIERS I Scalable multi-party computation for zk-SNARK parameters in the ran-dom beacon model Cryptology ePrint Archive Report20171050 2017

[13] BUNZ B BOOTLE J BONEH D POELSTRA AAND MAXWELL G Bulletproofs Short proofs for Con-fidential Transactions and more In Security and Privacy(SP) 2018 IEEE Symposium on (2018) IEEE

[14] BURKHART M STRASSER M MANY D AND DIM-ITROPOULOS X Sepia Privacy-preserving aggregationof multi-domain network events and statistics Network 1101101 (2010)

[15] CASTRO M AND LISKOV B Practical byzantine faulttolerance In OSDI (1999) vol 99 pp 173ndash186

[16] CECCHETTI E ZHANG F JI Y KOSBA A JUELSA AND SHI E Solidus Confidential distributed ledgertransactions via pvorm

[17] CHAIN I Confidential assets httpsblogchaincomhidden-in-plain-sight-transacting-privately-on-a-blockchain-835ab75c01cb

[18] CORRIGAN-GIBBS H AND BONEH D Prio Privaterobust and scalable computation of aggregate statisticsarXiv preprint arXiv170306255 (2017)

[19] COUNCIL F R Developments in audit 20162017full report 2017 httpwwwfrcorgukgetattachment915c15a4-dbc7-4223-b8ae-cad53dbcca17Developments-in-Audit-2016-17-Full-reportpdf

[20] CRAMER R DAMGARD I AND SCHOENMAKERSB Proofs of partial knowledge and simplified design ofwitness hiding protocols In Advances in Cryptology -CRYPTO rsquo94 14th Annual International Cryptology Con-ference Santa Barbara California USA August 21-251994 Proceedings (1994) pp 174ndash187

[21] DAGHER G G BUNZ B BONNEAU J CLARK JAND BONEH D Provisions Privacy-preserving proofsof solvency for Bitcoin exchanges In Proceedings of the22nd ACM SIGSAC Conference on Computer and Com-munications Security (Denver CO 2015) ACM pp 720ndash731

[22] Corda 2017 httpsgithubcomcordacorda

[23] Digital asset holdings 2017 httpdigitalassetcom

[24] Regulation (EU) 2016679 of the European Parliamentand of the Council of 27 April 2016 on the protection ofnatural persons with regard to the processing of personaldata and on the free movement of such data and repealingDirective 9546EC (General Data Protection Regulation)Official Journal of the European Union L119 (May 2016)1ndash88

[25] FELDMAN A J ZELLER W P FREEDMAN M JAND FELTEN E W Sporc Group collaboration us-ing untrusted cloud resources In OSDI (2010) vol 10pp 337ndash350

[26] FIAT A AND SHAMIR A How to prove yourselfpractical solutions to identification and signature problemsIn Proceedings of the 6th Annual International CryptologyConference (1987) CRYPTO rsquo87 pp 186ndash194

[27] GARMAN C GREEN M AND MIERS I Accountableprivacy for decentralized anonymous payments Cryp-tology ePrint Archive Report 2016061 2016 httpeprintiacrorg2016061

[28] GREENBERG A Fbi says itrsquos seized $285 million inbitcoins from ross ulbricht alleged owner of silk roadForbes 25 (2013)

USENIX Association 15th USENIX Symposium on Networked Systems Design and Implementation 77

beyond what is necessarily leaked by an audit is revealedHowever frequent auditing might reveal transaction con-tents eg if an auditor asks for banksrsquo assets after everytransaction

4 DesignThe challenge in creating zkLedger is to practically sup-port complete confidential auditingmdashan Auditor shouldnot be able to see individual bank transactions but a Bankshould not be able to hide assets from the Auditor dur-ing an audit and the auditor should be able to detect anincorrect answer

Figure 1 shows a general overview of zkLedger Thereare banks which determine transactions out of band andthen settle them by appending transactions to the ledgerThe ledger makes sure all banks and any auditors seenew transactions Each bank and auditor maintains acommitment cache which are commitments to summedvalues used to make creating transactions and respondingto audits faster Each bank also has private stores of plain-text transaction data

The rest of this section describes the zkLedger trans-action format how banks create transactions and how abank can answer a simple query from the auditor

41 TransactionsThe ledger in zkLedger is a table where transactions cor-respond to rows and Banks correspond to columns Eachtransaction has an entry for each Bank Figure 2 shows aledger with n banks Each entry in a transaction includesa commitment to a value which is the amount of the assetthat is being debited or credited to the bank For exam-ple if Banki wants to transfer 100 shares of an asset toBank j irsquos entry in the transaction would contain a com-mitment to -100 and jrsquos would contain a commitment to100 All other entries in the transaction would containcommitments to 0 since none of the other bank balanceswere changed This scheme has the nice property thatan outside observer can look at a bankrsquos entire columnand know that this represents the entirety of the bankrsquosholdings

Hiding amounts As described in sect32 zkLedger doesnot include the value in plain-text in the transaction In-stead zkLedger uses Pedersen commitments to committo the value in transfer transactions This makes valuecommitments completely indistinguishablemdashan outsideobserver cannot tell the difference between a commitmentto a positive value a negative value or 0 Recall that acommitment to a value v is cm = COMM(vr) = gvhrIf desired a prover can reveal v and r to a verifier whoknows cm and the verifier can confirm this is consistent

Since a transaction in zkLedger contains an entry forevery Bank there is a size-n vector ~cm committing tovalues in ~v Each commitment cmk uses a fresh com-mitment randomness rk Most of the entries will containcommitments to 0 for banks that are not involved with thetransaction but this is not apparent to an outside observer

zkLedger maintains the following financial invariants

bull A transfer transaction cannot create or destroy assets

bull The spending bank must give consent to the transferand must actually own enough of the particular asset toexecute this transaction

In a public blockchain the validators could simplyconfirm that these things are true by looking at the historyof transactions and the current transaction and makingsure the spending bank has the funds to spend Howeverin zkLedger these values are not public Instead wecreate a set of proofs that the spender can create to provethe invariants are maintained The spender can createa transaction without interacting with any of the otherbanks

First zkLedger introduces a Proof of Balance (πB)This is a proof that the transaction conserves assets noassets are created or destroyed (of course public is-suance and withdrawal transactions do not have suchproofs) More formally the committed values shouldsatisfy sum

nk=1 vk = 0 To prove this the prover chooses the

rk carefully it should also be the case that sumnk=1 rk = 0

If this is true and the values also sum to 0 then the ver-ifier can check to make sure that prod

nk=1 cmk = 1 for the

commitments in the rowNext zkLedger must ensure that the spending bank

actually has the assets to transfer To do this zkLedger in-troduces a Proof of Assets (πA) Other privacy-preservingblockchain systems use Unspent Transaction Outputsor UTXOs to show proof of assets and prevent doublespending For example if Alice wants to send a coin toBob she chooses one of her coins creates a new trans-action addressing the coin to Bob and includes a pointerto the previous transaction where she received the coinThis previous transaction is an output All of the valida-tors in the system maintain the invariant that outputs canonly be spent once Unfortunately in systems without zk-SNARKs this leaks the transaction graph In zkLedger abank proves it has assets by creating a commitment to thesum of the values for the asset in its column includingthis transaction If the sum is greater than or equal to 0then the bank has assets to transfer Note that this is truesince the bankrsquos column represents all the assets it hasreceived or spent and the Pedersen commitments can behomomorphically added in columns as well as in rows In

70 15th USENIX Symposium on Networked Systems Design and Implementation USENIX Association

order to produce a proof with the correct sum the bankmust have seen every previous transaction This impliesthat banks must create transactions serially In its ownentry where the value is negative the bank includes proofof knowledge of secret key to show that it authorized thetransaction This requires creating a disjunctive proofmdasheither the committed value for entry i has vi ge 0 or thecreator of the transaction knows the secret key for Banki

Range proofs Because commitment values are in anelliptic curve group and rely on modulus we need to makesure that the commited values are within an acceptablerange To see why note that if N is the order of thegroup then COMM(vr) = COMM(v+Nr) there is noway to distinguish between the two Without a checkto make sure the commited value is within the range[0N minus 1] a malicious bank could undetectably createassets To address this we use range proofs as describedin Confidential Assets [42] which uses Borromean ringsignatures [35] zkLedger supports asset value amountsup to a trillion Range proofs are the most expensivepart of the transaction as described our scheme requirestwo range proofsmdashone for the commitment value andanother for the sum of assets in the column We cansquash the two range proofs down to one range proof byintroducing an auxiliary commitment cmprimei cmprimei is eithera re-commitment to the value in cmi or the sum of thevalues in the column up to row m sum

mk=0 vk which can be

achieved by computing the product of the commitmentsin the column prod

mk=0 cmk Then we can do one range

proof on the value in cmprimei Either this is the spendingbank in which case cmprimei must be a commitment to thesum or it is another bank which is receiving funds or notinvolved in which case cmprimei could be either (and it doesnot matter which it is)

This satisfies the financial invariants described aboveHowever a particular design choice we made in zkLedgeris that a spending bank can create a transaction spendingits own assets without interacting with other banks Thismeans that a malicious bank could create transactionswhich maintain financial invariants but are ill-formed Wewill address this problem after describing how auditingworks

Once created a bank broadcasts the transaction andit will be appended to the ledger If the banks are main-taining the ledger each bank is responsible for validatingthe transaction before accepting it to the ledger If a thirdparty is maintaining the ledger then the third party shouldverify the proofs in a transaction before accepting it

Example transaction Figure 2 shows a transactionwhere Bank of America is transferring one million eurosto Goldman Sachs Bank of America creates the transfer

transaction publishing the transaction id timestamp andasset type (euros) publicly Bank of America commits tothe amount deducted from its own assets minus1000000in its own entry and 1000000 in Goldman Sachsrsquos en-try For every other bank Bank of America commits to0 This serves to hide the banks involved in the transferno one except Bank of America can distinguish betweenthe commitments to determine which are commiting tononzero values Bank of America then broadcasts thetransaction to the ledger The ledger maintainer validatesthe transaction and appends it to the ledger Once ac-cepted to the ledger this serves as a complete transferof 1000000 euros from Bank of America to GoldmanSachs

42 Auditing ProtocolThe Auditor has a copy of the ledger and interacts withthe banks to calculate functions on their private data inorder to get a view of the financial system represented bythe ledger

The Auditor audits Banki by issuing a query to Bankifor example ldquoHow many euros do you hold at time trdquoBanki responds to the auditor with an answer and a proofthat the answer is consistent with the transactions on theledger The Auditor multiplies the commitments on theledger in Bankirsquos column for euros and verifies the proofand answer with the total This is a commitment to thethe total amount of euros Banki holds

The key insight here is that given this table constructionthe Auditor can read bank irsquos column and know that itis seeing every asset transfer involving i There is noway for i to ldquohiderdquo assets on the ledger without actuallytransferring assets and giving control to another bank Incontrast during a traditional audit a bank could simplynot show the auditor some of its balance sheet

Banks could collude to hold assets for each other tem-porarily for example Bank j might transfer assets toBanki and take them back later For that time periodthe assets would be part of Bankirsquos holdings But bankscannot collude after an Auditor poses a query becausethe Auditor has already specified the time t at which thequery applies Any transfer would necessarily have to beafter t So at this point it is too late for a malicious bankto create a new transaction transferring assets to anotherbank

As described above a bank can create a transactiontransferring its own assets without any interaction Thisis common with most blockchain systems where onlythe signature of the sender is required to create a validtransaction There is no in-protocol way for a receiver toobject to a transfer Given our table construction everybank is affected by every transaction because a bank must

USENIX Association 15th USENIX Symposium on Networked Systems Design and Implementation 71

Metadata Bank1 Bank2 Bank3 BanknID Asset Time (Bank of America) (Goldman Sachs) (JPMorgan) (Citigroup)

1 e 130601 COMM(minus106r1) COMM(106r2) COMM(0r3) middot middot middot COMM(0rn)21718 Token1 Token2 Token2 middot middot middot Tokenn

πA1 π

B1 π

C1 πA

2 πB2 π

C2 πA

3 πB3 π

C3 middot middot middot πA

n πBn π

Cn

Figure 2 Contents of the ledger pertaining to a transaction that sends 106 euros from Bank1 to Bank2 Note that while asset type (euro) is visibleas part of the metadata the transaction amount (106 e) and participating institutions (Bank of America and Goldman Sachs) remain private Weuse Pedersen commitments so the commitment part of the row has values gminus106

hr1 g106hr2 and hr3 hrn Similarly audit tokens pictured

have values (pk1)r1 (pk2)

r2 For each bank Banki the corresponding column also includes proof-of-assets πAi proof-of-balance πB

i andproof-of-consistency πC

i

total all of the commitments in its column to respond tothe Auditormdasheven commitments for transactions in whichit was not involved A malicious Banki could create atransaction and not inform the another Bank j of the r jused in its entry even if it is not transferring assets toBank j Bank j would be unable to respond to the Auditorbecause it would not be able to open up the product of thecommitments in its column

In order to prove the integrity of a transfer transactionzkLedger must ensure an additional invariant

bull All banks have enough information in the transactionto open up commitments for the Auditor

zkLedger does this by requiring the spending bank toinclude a publicly verifiable Token in every entry Thisis defined as Tokenk = (pkk)

rk Bankk uses this token toopen up the product of its commitments for the Auditorwithout needing to know rkUsing audit tokens Consider a query for a sum of valuesin a bankrsquos column One way of answering this querywould be to reveal sumvk and sumrk Then the auditor wouldsimply check that these plain values are consistent withthe homomorphically computed value prodcmk = gsumvk hsumrk

However a bank does not necessarily know all thecommitment randomnesses rk (in particular these valuesare unknown for any transaction that the bank was notparty to) so the naive approach does not work

One approach could be to ask the preparer of the trans-action (ie the sender) to encrypt rk so that the non-participating bank Bankk can decrypt it To prevent thesending bank from placing a ldquogarbagerdquo ciphertext on theledger (and thus making Bankk fail the auditorrsquos queries)one would need a zero-knowledge proof of consistencybetween the encrypted value and the commitment Con-structing a concretely efficient proof for this statement isnon-trivial in a nutshell standard encryption schemes(eg ElGamal) embed plain-text in a group element whilePedersen commitments would have this value in the expo-nent

Our insight is that Bankk does not need to open sumrkto prove that sumvk is correct Instead suppose that Bankk

wants to claim that s = gsumvk hsumrk opens up to a valuesumvk To do so the bank computes sprime = sgsumvk = hsumrk andt = prodk Tokenk = hsksumrk Note that the auditor can alsocompute the values of sprime and t from the ledger and theclaimed answer sumvk

It suffices for the bank to prove that logsprime t = logh pkObserve that both logarithms evaluate to sk so a bank canproduce this proof without knowing sumri Moreover ifthis equation holds then t1sk = sprime = sgsumv but if the sumvwas incorrect then knowledge of sk would reveal a linearrelationship between g and h which is ruled out by oursecurity assumption

To show that the r in the Tokenk is the same as ther in rk we require an additional Proof of Consistency(πC) This is a zero-knowledge proof asserting that foreach k the value rk used to form cmk and Tokenk is thesame (See Appendix B for details of how such proof isconstructed)

Note that audit tokens are only useful to the bank open-ing its commitment though public a malicious bankcannot use another bankrsquos Token to successfully open anincorrect result or learn information about other bankrsquostransactions

43 Final transaction constructionFor a transfer transaction in row m each entry i containsthe following itemsbull Commitment (cmi) (gvihri) a Pedersen commitment

to the value we are transferringbull Audit Token (Tokeni) (pki)

ri This is used to answeraudits without knowing the randomness used in thecommitment

bull Proof of Balance (πB) a zero-knowledge proof assert-ing that the committed values satisfy sum

nk=1 vk = 0

bull Proof of Assets (πA) a new commitment cmprimei corre-sponding token Tokenprimei and a zero-knowledge proofasserting that either cmprimei is a re-commitment of thevalue in cmi or a recommitment to the sum of the val-ues in prod

mj=0 cm j and cmprimei is in range [0240) If the

committed value in cmi is negative the proof assertsbank i consented to the transfer

72 15th USENIX Symposium on Networked Systems Design and Implementation USENIX Association

bull Proof of Consistency (πC) two zero-knowledgeproofs asserting the randomness used in cmi and Tokeniare the same and the randomness used in cmprimei andTokenprimei are the same This is to prevent a maliciousbank from adding data to the ledger that would stopanother bank from being able to open its commitmentsfor the AuditorTransactions may contain additional metadata in plain-

text or not For example banks might want to includeencrypted account numbers addresses or identifying in-formation on behalf of a customer to satisfy the TravelRule specified in the Bank Secrecy Act of 1970 [1] zk-Ledger supports auditing over metadata in the transactionas well but it does not have a way to publicly verifyadditional metadata

44 Adding or removing bankszkLedger can support dynamically adding or removingbanks if done so publicly The participants (or anotherauthority) append a signed transaction to the ledger indi-cating which banks and thus columns should be addedor removed For example to add a new bank to theledger shown in Figure 2 the involved banks would ap-pend a transaction to the ledger indicating an intent toadd Bankn+1 From that point forward all transactionsshould contain n+ 1 entries The Proof of Assets forBankn+1rsquos entry in each transaction will start at the rowwhere Bankn+1 was added Similarly if a bank is re-moved later transactions should not include entries forthat bank Since all participants can see which bankswere added or removed they can adjust their proofs andverifications accordingly

45 OptimizationszkLedger employs several optimizations to make produc-ing and verifying these proofs faster and to support fasterauditing First caching the product of the commitmentsin a bankrsquos column improves auditing and proof creationspeed Each bank stores a rolling product of commitmentsby row and by asset so that it can quickly produce proofsof assets and answer queries from auditors Using thesecaches a bank can quickly answer an auditorrsquos query ona subset of rows in the ledger

Most transactions in zkLedger do not include everybank Every bank can pre-generate many range proofsfor the value 0 We speedup transaction throughput byparallelizing range proof generation and validation

5 AuditingAuditing is a critical component of the financial systemand regulators use various techniques to measure systemicfinancial risk Through the use of sums means ratios

variance co-variance and standard deviation an auditorin zkLedger can determine the following among othermeasurementsbull Leverage ratios zkLedger can show how much of an

asset a bank has on its books compared to its otherholdings This is helpful to estimate counterparty risk

bull Concentration Regulators use a measure called theHerfindahl-Hirschman Index (HHI) to measure howcompetitive an industry is [29]

bull Real-time price indexes Auditors can get a sense ofthe price of assets that are traded over-the-counter andthus not tracked through exchangesNatively zkLedger supports sums which means linear

combinations of values stored in the ledger This comesfrom the additive structure of Pedersen commitmentsBut zkLedger also supports a more general query modelwhich can be considered in two parts A map step and areduce stepBasic auditing Consider the basic example where anauditor wants to determine how much of an asset a bankhas on its books As described in sect42 the auditor willfilter the rows by asset multiply the entries in the bankrsquoscolumn and then ask the bank to open the commitmentproduct This only requires one round of communica-tion between the auditor and the bank and the messagesare a constant size independent of the number of rowsBecause of zkLedgerrsquos commitment caches this is veryfastMapreduce An auditor can issue more complex queriesthat might require the exchange of more data or mightrequire the participants to look at most of the rows in theledger Letrsquos consider an auditor which wants to know themean transaction size for a given bank and asset An au-ditor cannot verify a bankrsquos answer by simply totaling thebankrsquos column of commitments and dividing the openedvalue by the number of rows because such a computationwould have an incorrect denominator Namely when thebank is not involved in a transaction its column in therow will be commitment to 0 and should be discountedIn order to determine the correct denominator the auditorand the bank run the following protocol1 Filter The bank will filter the rows by asset2 Produce new commitments For each row the bank

will commit to a single bit b 1 or 0 depending on ifthe bank was involved in the transaction or not and cre-ate a proof that the bank has done this recommitmentcorrectly Crucially the auditor cannot distinguishbetween these commitments and so the bankrsquos trans-actions are not revealed We call this act of producingnew commitments the map step The map step alsorequires producing proofs that the new values were

USENIX Association 15th USENIX Symposium on Networked Systems Design and Implementation 73

correctly computed in our example for each transac-tion the bank would produce a NIZK proof that b = 1if and only if the transaction value was not equal to 0

3 Compute number of non-zero transactions Thebank computes the homomorphic sum of the new com-mitments to bits~b and opens it to reveal how manytransactions were non-zero This is the reduce stepThis is the correct denominator to compute the meantransaction size The auditor cannot tell anything aboutthe values in~b beyond what is revealed by the sum

4 Respond to auditor The bank then sends the auditorthe sum of the values in its column the vector of bitcommitments and corresponding NIZK proofs thenumber of its non-zero transactions n and the sum ofthe r values in the commitments

5 Verification The auditor verifies the map step byverifying the commitments were done correctly andverifies the reduce step and the number of non-zerotransactions by confirming that the product of the vec-tor of bit commitments is gnhsum

Nk=1 rk

6 Compute answer The auditor computes the meanfrom the sum of the bankrsquos column and the number ofnon-zero transactionsAn auditor could ask a bank for outlier transactions

using a similar technique For each row the bank willcommit to a bit b where b = 1 if a transactionrsquos value forthat bank is outside a specified range As when computingthe mean the auditor can verify these commitments wereproduced correctly and obtain the sum The bank can thenopen only the transactions where b = 1 and the auditorknows exactly how many transactions should be opened

More complex auditing queries require multiple mapand reduce computations For example here is howan auditor can learn the variance of transaction valuesv1 vN

1 Compute the average transaction value Executethe protocol described above to compute the numberof non-zero transactions n and their average value v

2 Apply the squaring map For each entry vi in its rowthe bank produces a fresh commitment cmprimei to v2

i andsends these commitments to the auditor The bank alsosupplies NIZK proofs that the value hidden in eachcmprimei is exactly the square of the value vi committed toon the ledger

3 Apply the reduce step The auditor computes theproduct of the commitments cmprimei and the bank opensup this commitment as V = v2

1 + middot middot middot+ v2N by revealing

R = sumNi=1 ri The auditor confirms that the product of

the commitments is equal to gV hR

The auditor now computes the variance σ as followsσ2 = 1

n sumvi 6=0(viminus v)2 = 1nV minus v2

We note that whereas the square mapping used abovecorresponds to the second moment (variance) zkLedgercan also compute higher statistical moments (eg skew-ness and kurtosis) using similar techniques and usingcubing and fourth power mappings respectively See Ap-pendix A for a list of measurements zkLedger supports

zkLedger can support limited information release byusing more complex reduce mappings For example in-stead of releasing the sum of values the bank can producea commitment to the rounded sum of values (eg to thefirst two decimal places) and use range proofs also im-plemented in zkLedger to show that the rounding wasdone correctly Revealing just the order of magnitude ofthe quantity at hand lets the parties balance the granularityof information disclosure6 ImplementationTo evaluate zkLedgerrsquos design we implemented a pro-totype of zkLedger in Go Our prototype uses a modi-fied version of the btcec library [2] that contains the pa-rameters and methods to compute with the elliptic curvesecp256k1 We use Gorsquos built-in SHA-256 implementa-tion for our cryptographic hash function and determin-istically pick g and h by applying point decompressionto the ldquonothing-up-my-sleeverdquo strings SHA256(0) andSHA256(1) Our prototype consists of approximately3200 lines of code of which 40 implement crypto-graphic tools used by zkLedger (zero-knowledge proofsrange proofs etc)

The implementation of the curve in zkLedger uses GorsquosbigInt type which we make no effort to compress orserialize in an efficient way A more optimized imple-mentation could compress curve points Our range proofsimplement the protocol used in Confidential Assets [42]Our NIZKs are based on Generalized Schnorr Proofswhich are three move interactive protocols to make themnon-interactive we apply the Fiat-Shamir heuristic [26]where we instantiate the random oracle using the SHA-256 hash function Our prototype implementation doesnot implement the complex queries described in sect5 andthus we do not evaluate them in sect7

7 EvaluationOur evaluation answers the following questionsbull How expensive is it to store prove and verify the differ-

ent proofs in zkLedger (sect72)bull How does auditing scale with the size of the ledger

(sect73)bull How does zkLedger scale with the number of banks

(sect74)

74 15th USENIX Symposium on Networked Systems Design and Implementation USENIX Association

Component Create Verify Size

2k Commitment 05 ms 05 ms 64 B2k Consistency 07 ms 08 ms 224 Bk Disjunctive 09 ms 09 ms 288 Bk Range 47 ms 35 ms 3936 B

Table 1 Number of each proof component in a transaction for k banksSize of and time to create and verify the components with 12 cores Therange proof create and verify benefit from the additional cores

71 Experimental setup

Microbenchmarks We run microbenchmarks on a 12core Intel machine with i7-X980 333 GHz CPUs and24GB of RAM running 64-bit Linux 440 on Ubuntu16043 Each microbenchmark runs the same code aBank runs to create and validate transactions

Distributed experiment We run the distributed experi-ments on a set of 12 virtual machines each with 4 cores ofIntel Xeon E5-2640 25 GHz processors 24GB of RAMand the same software setup as above There is one au-ditor one server providing the service of the ledger anda varying number of banks one per server Servers com-municate using the netrpc Go package over TCP Allexperiments use Go version 19

72 Proof overhead in zkLedgerTable 1 shows the time to prove and verify the proofs in atransaction in zkLedger There are two commitments twoconsistency proofs and one each of the disjunctive andrange proofs in a transaction entry There is a transactionentry per Bank Table 1 also shows the sizes of the variousproofs in bytes These sizes are estimated based on thesize of the underlying fields in the struct in memorythese proofs could be further compressed Range proofsdominate the size of the transactions

The left graph in Figure 3 shows the time it takes tocreate and verify a transaction varying the number ofoverall banks which increases the number of entries pertransaction This indicates that as we increase the numberof banks both transaction creation and verification timesper bank increase linearly but parallelization helps Prov-ing and validating range proofs dominates transactioncreation and verification but this cost is also highly paral-lelizable 12 cores gives a 28times speedup when creating atransaction with 20 banks a bank can create or validate atransaction for up to 20 banks in less than 200ms

As described in sect41 zkLedger uses Borromean ringsignatures to prove that a value is in a certain range andsupports values up to 240 Reducing the supported rangeof values would reduce range proof cost since that cost islinear in the number of bits in the size of the range Thereare also newer proof systems such as Bulletproofs which

might create much smaller range proofs [13] We plan toevaluate zkLedger with Bulletproofs in future work

73 Cost of auditing ledgersThe left graph in Figure 4 shows that for certain func-tions the time to audit is independent of the number oftransactions in the ledger This is because the Auditorand Banks maintain commitment caches which alreadyhave the commitment product necessary to prove to theauditor the sum of the values in its column The auditfunction is measuring the Herfindhal-Hirschman Indexso the auditor communicates with each bank

When the auditor cannot use a commitment cache per-haps because it was offline it must process the wholeledger to compute the commitment product This alsoapplies to more complex auditing like the types describedin sect5 when the auditor has to verify recommitments forevery row in the ledger These costs are shown in themiddle graph in Figure 4 This graph shows how long ittakes the auditor to compute the Herfindahl-HirschmanIndex on a ledger of varying sizes without using the com-mitment caches so the auditor must process every row ofthe ledger In these measurements the auditor does notverify each row As expected this time increases linearlywith the number of rows This indicates that maintainingcommitment caches is important for real-time auditingHowever even without commitment caches auditing timeis reasonable 35 seconds for 100K transactions Thissuggests the complex auditing queries in which the au-ditor computes a similar set of operations per row willalso be on the order of many seconds zkLedger currentlyonly maintains commitment product caches per asset perbank but could maintain more

For a fixed size ledger this audit function costs orderthe number of banks The right graph in Figure 4 demon-strates the auditing costs of computing the Herfindahl-Hirschman Index on a ledger of 2000 transactions as wevary the number of banks both with and without com-mitment caches The auditor audits the banks in parallelAuditing cost for this function grows slightly with thenumber of banks since more banks increase the variabil-ity in parallel auditing and the auditor must wait for thelast bank to respond before computing the final answer

In these figures each point is the mean of running theauditing query 20 times with error bars representing onestandard deviation from the mean

74 Scaling with more banksThere are two significant costs that grow with the numberof banks in zkLedger a serial step to create transactionsthat increases linearly and verifying transactions whichincreases quadratically with the number of banks As

USENIX Association 15th USENIX Symposium on Networked Systems Design and Implementation 75

0

100

200

300

400

500

600

2 4 6 8 10 12 14 16 18 20

Tim

e (

ms)

number of banks

verify-1create-1verify-12

create-12

0

200

400

600

800

1000

2 3 4 5 6 7 8 9 10

Tim

e (

ms)

number of banks

complete transactions

0

2

4

6

8

10

12

2 3 4 5 6 7 8 9 10

Th

rou

gh

pu

t (t

xn

ss

ec)

number of banks

all banks transactingone bank transacting

Figure 3 Transaction creation and verification time for one bank (left) varying the number of entries in the transaction Single-threaded andmulti-threaded performance with 12 threads Time to fully process a transaction including creation broadcast to ledger banks and auditor andverification by all parties (middle) Throughput (right) varying the number of banks

0

2

4

6

8

10

12

0K 20K 40K 60K 80K 100K

Au

ditin

g t

ime

(m

s)

Transactions in ledger

online auditor

0

500

1000

1500

2000

2500

3000

3500

0K 20K 40K 60K 80K 100K

Transactions in ledger

offline auditor

0

20

40

60

80

100

120

2 3 4 5 6 7 8 9 10

Number of banks

offline auditor

online auditor

Figure 4 Time to audit ledgers of different sizes (4 banks) and with a varying number of banks (2000 row ledger) Audit time is independent of thesize of the ledger (left) thanks to commitment caches maintained by the online auditor When commitment cache optimization is turned off (middle)the audit time is linear in the size of the ledger Audit time grows with the number of banks (right) and is much higher without commitment caches

described in sect41 a bank needs to use its entry fromtransaction nminus1 to create transaction n So though a bankcan use many cores to produce the proofs for a singletransaction in parallel multiple banks cannot producedifferent transactions in parallel In zkLedger banks startcreating transaction n before seeing nminus 1 but the bankcannot complete the transaction until nminus1 is accepted tothe ledger and verified causing an inherent bottleneck

The second major cost is around verification Everybank must verify every transaction so the more banksthe larger each transaction and thus the more work thatneeds to be done by each bank The middle graph inFigure 3 measures the time it takes one bank to createand all participants in zkLedger to completely processa transaction One bank creates a transaction and sendsit to the ledger which then broadcasts the transaction toall banks and an online auditor The auditor and everybank verify the transaction As we increase the numberof banks work increases quadratically however bankscan verify transactions in parallel so the time to processtransactions only increases linearly The right graph inFigure 3 shows that as we surmised zkLedgerrsquos through-put worsens with more banks The one bank transactingline in this graph is the same data as the middle graph

Since range proofs dominate the costs of transactioncreation and verification we are optimistic that a fasterrange proof implementation will directly improve perfor-mance zkLedgerrsquos current performance is comparableto Solidus a privacy-preserving distributed ledger whichachieves 3-4 transactions per second with online valida-tion but unlike zkLedger does not support auditing

8 Future workzkLedger focuses on providing provably correct auditingover private transaction data but zkLedger does not havea way to recover if the distributed ledger is corrupted Inthis case the parties maintaining the ledger would haveto come together to recreate historical transactions zk-Ledger also does not provide recourse if a bank commitsan unintended transaction to the ledger A future ver-sion of zkLedger might provide rectifying transactions orparticipant agreed-upon rollback

9 ConclusionzkLedger is the first distributed ledger system to providestrong transaction privacy public verifiability and com-plete provably correct auditing zkLedger supports a richset of auditing queries which are useful to measure thefinancial health of a market We developed a design usingnon-interactive zero-knowledge proofs to prove transac-tions maintain financial invariants and to support auditingOur evaluation shows that zkLedger has reasonable per-formance for transaction settlement and auditing

10 AcknowledgementsWe thank Alexander Chernyakhovsky Thaddeus DryjaDavid Lazar Ronald L Rivest CJ Williams and ourshepherd and reviewers for helpful comments The re-search leading to these results has received funding fromthe Center for Science of Information (CSoI) an NSFScience and Technology Center under grant agreementCCF-0939370 and the Ethics and Governance of Artifi-cial Intelligence Fund

76 15th USENIX Symposium on Networked Systems Design and Implementation USENIX Association

References[1] Bank secrecy act of 1970 October 1970 12 USC 103[2] Package btcec implements support for the elliptic curves

needed for Bitcoin July 2017 httpsgodocorggithubcombtcsuitebtcdbtcec

[3] ABBE E A KHANDANI A E AND LO A WPrivacy-preserving methods for sharing financial risk ex-posures The American Economic Review 102 3 (2012)65ndash70

[4] ARASU A BLANAS S EGURO K KAUSHIK RKOSSMANN D RAMAMURTHY R AND VENKATE-SAN R Orthogonal security with cipherbase In CIDR(2013)

[5] BAJAJ S AND SION R Trusteddb A trusted hardware-based database with privacy and data confidentiality IEEETransactions on Knowledge and Data Engineering 26 3(2014) 752ndash765

[6] BAUMANN A PEINADO M AND HUNT G Shieldingapplications from an untrusted cloud with haven ACMTransactions on Computer Systems (TOCS) 33 3 (2015)8

[7] BEN-SASSON E CHIESA A GENKIN D TROMERE AND VIRZA M SNARKs for C Verifying programexecutions succinctly and in zero knowledge In Advancesin CryptologyndashCRYPTO 2013 Springer 2013 pp 90ndash108

[8] BEN-SASSON E CHIESA A GREEN M TROMERE AND VIRZA M Secure sampling of public parametersfor succinct zero knowledge proofs In Proceedings of the2015 IEEE Symposium on Security and Privacy (2015)SP rsquo15 pp 287ndash304

[9] BLUM M FELDMAN P AND MICALI S Non-interactive zero-knowledge and its applications In Pro-ceedings of the 20th Annual ACM Symposium on Theoryof Computing (1988) STOC rsquo88 pp 103ndash112

[10] BOGDANOV D TALVISTE R AND WILLEMSON JDeploying secure multi-party computation for financialdata analysis In International Conference on FinancialCryptography and Data Security (2012) Springer pp 57ndash64

[11] BOWE S GABIZON A AND GREEN M A multi-party protocol for constructing the public parameters ofthe Pinocchio zk-SNARK Cryptology ePrint ArchiveReport 2017602 2017

[12] BOWE S GABIZON A AND MIERS I Scalable multi-party computation for zk-SNARK parameters in the ran-dom beacon model Cryptology ePrint Archive Report20171050 2017

[13] BUNZ B BOOTLE J BONEH D POELSTRA AAND MAXWELL G Bulletproofs Short proofs for Con-fidential Transactions and more In Security and Privacy(SP) 2018 IEEE Symposium on (2018) IEEE

[14] BURKHART M STRASSER M MANY D AND DIM-ITROPOULOS X Sepia Privacy-preserving aggregationof multi-domain network events and statistics Network 1101101 (2010)

[15] CASTRO M AND LISKOV B Practical byzantine faulttolerance In OSDI (1999) vol 99 pp 173ndash186

[16] CECCHETTI E ZHANG F JI Y KOSBA A JUELSA AND SHI E Solidus Confidential distributed ledgertransactions via pvorm

[17] CHAIN I Confidential assets httpsblogchaincomhidden-in-plain-sight-transacting-privately-on-a-blockchain-835ab75c01cb

[18] CORRIGAN-GIBBS H AND BONEH D Prio Privaterobust and scalable computation of aggregate statisticsarXiv preprint arXiv170306255 (2017)

[19] COUNCIL F R Developments in audit 20162017full report 2017 httpwwwfrcorgukgetattachment915c15a4-dbc7-4223-b8ae-cad53dbcca17Developments-in-Audit-2016-17-Full-reportpdf

[20] CRAMER R DAMGARD I AND SCHOENMAKERSB Proofs of partial knowledge and simplified design ofwitness hiding protocols In Advances in Cryptology -CRYPTO rsquo94 14th Annual International Cryptology Con-ference Santa Barbara California USA August 21-251994 Proceedings (1994) pp 174ndash187

[21] DAGHER G G BUNZ B BONNEAU J CLARK JAND BONEH D Provisions Privacy-preserving proofsof solvency for Bitcoin exchanges In Proceedings of the22nd ACM SIGSAC Conference on Computer and Com-munications Security (Denver CO 2015) ACM pp 720ndash731

[22] Corda 2017 httpsgithubcomcordacorda

[23] Digital asset holdings 2017 httpdigitalassetcom

[24] Regulation (EU) 2016679 of the European Parliamentand of the Council of 27 April 2016 on the protection ofnatural persons with regard to the processing of personaldata and on the free movement of such data and repealingDirective 9546EC (General Data Protection Regulation)Official Journal of the European Union L119 (May 2016)1ndash88

[25] FELDMAN A J ZELLER W P FREEDMAN M JAND FELTEN E W Sporc Group collaboration us-ing untrusted cloud resources In OSDI (2010) vol 10pp 337ndash350

[26] FIAT A AND SHAMIR A How to prove yourselfpractical solutions to identification and signature problemsIn Proceedings of the 6th Annual International CryptologyConference (1987) CRYPTO rsquo87 pp 186ndash194

[27] GARMAN C GREEN M AND MIERS I Accountableprivacy for decentralized anonymous payments Cryp-tology ePrint Archive Report 2016061 2016 httpeprintiacrorg2016061

[28] GREENBERG A Fbi says itrsquos seized $285 million inbitcoins from ross ulbricht alleged owner of silk roadForbes 25 (2013)

USENIX Association 15th USENIX Symposium on Networked Systems Design and Implementation 77

order to produce a proof with the correct sum the bankmust have seen every previous transaction This impliesthat banks must create transactions serially In its ownentry where the value is negative the bank includes proofof knowledge of secret key to show that it authorized thetransaction This requires creating a disjunctive proofmdasheither the committed value for entry i has vi ge 0 or thecreator of the transaction knows the secret key for Banki

Range proofs Because commitment values are in anelliptic curve group and rely on modulus we need to makesure that the commited values are within an acceptablerange To see why note that if N is the order of thegroup then COMM(vr) = COMM(v+Nr) there is noway to distinguish between the two Without a checkto make sure the commited value is within the range[0N minus 1] a malicious bank could undetectably createassets To address this we use range proofs as describedin Confidential Assets [42] which uses Borromean ringsignatures [35] zkLedger supports asset value amountsup to a trillion Range proofs are the most expensivepart of the transaction as described our scheme requirestwo range proofsmdashone for the commitment value andanother for the sum of assets in the column We cansquash the two range proofs down to one range proof byintroducing an auxiliary commitment cmprimei cmprimei is eithera re-commitment to the value in cmi or the sum of thevalues in the column up to row m sum

mk=0 vk which can be

achieved by computing the product of the commitmentsin the column prod

mk=0 cmk Then we can do one range

proof on the value in cmprimei Either this is the spendingbank in which case cmprimei must be a commitment to thesum or it is another bank which is receiving funds or notinvolved in which case cmprimei could be either (and it doesnot matter which it is)

This satisfies the financial invariants described aboveHowever a particular design choice we made in zkLedgeris that a spending bank can create a transaction spendingits own assets without interacting with other banks Thismeans that a malicious bank could create transactionswhich maintain financial invariants but are ill-formed Wewill address this problem after describing how auditingworks

Once created a bank broadcasts the transaction andit will be appended to the ledger If the banks are main-taining the ledger each bank is responsible for validatingthe transaction before accepting it to the ledger If a thirdparty is maintaining the ledger then the third party shouldverify the proofs in a transaction before accepting it

Example transaction Figure 2 shows a transactionwhere Bank of America is transferring one million eurosto Goldman Sachs Bank of America creates the transfer

transaction publishing the transaction id timestamp andasset type (euros) publicly Bank of America commits tothe amount deducted from its own assets minus1000000in its own entry and 1000000 in Goldman Sachsrsquos en-try For every other bank Bank of America commits to0 This serves to hide the banks involved in the transferno one except Bank of America can distinguish betweenthe commitments to determine which are commiting tononzero values Bank of America then broadcasts thetransaction to the ledger The ledger maintainer validatesthe transaction and appends it to the ledger Once ac-cepted to the ledger this serves as a complete transferof 1000000 euros from Bank of America to GoldmanSachs

42 Auditing ProtocolThe Auditor has a copy of the ledger and interacts withthe banks to calculate functions on their private data inorder to get a view of the financial system represented bythe ledger

The Auditor audits Banki by issuing a query to Bankifor example ldquoHow many euros do you hold at time trdquoBanki responds to the auditor with an answer and a proofthat the answer is consistent with the transactions on theledger The Auditor multiplies the commitments on theledger in Bankirsquos column for euros and verifies the proofand answer with the total This is a commitment to thethe total amount of euros Banki holds

The key insight here is that given this table constructionthe Auditor can read bank irsquos column and know that itis seeing every asset transfer involving i There is noway for i to ldquohiderdquo assets on the ledger without actuallytransferring assets and giving control to another bank Incontrast during a traditional audit a bank could simplynot show the auditor some of its balance sheet

Banks could collude to hold assets for each other tem-porarily for example Bank j might transfer assets toBanki and take them back later For that time periodthe assets would be part of Bankirsquos holdings But bankscannot collude after an Auditor poses a query becausethe Auditor has already specified the time t at which thequery applies Any transfer would necessarily have to beafter t So at this point it is too late for a malicious bankto create a new transaction transferring assets to anotherbank

As described above a bank can create a transactiontransferring its own assets without any interaction Thisis common with most blockchain systems where onlythe signature of the sender is required to create a validtransaction There is no in-protocol way for a receiver toobject to a transfer Given our table construction everybank is affected by every transaction because a bank must

USENIX Association 15th USENIX Symposium on Networked Systems Design and Implementation 71

Metadata Bank1 Bank2 Bank3 BanknID Asset Time (Bank of America) (Goldman Sachs) (JPMorgan) (Citigroup)

1 e 130601 COMM(minus106r1) COMM(106r2) COMM(0r3) middot middot middot COMM(0rn)21718 Token1 Token2 Token2 middot middot middot Tokenn

πA1 π

B1 π

C1 πA

2 πB2 π

C2 πA

3 πB3 π

C3 middot middot middot πA

n πBn π

Cn

Figure 2 Contents of the ledger pertaining to a transaction that sends 106 euros from Bank1 to Bank2 Note that while asset type (euro) is visibleas part of the metadata the transaction amount (106 e) and participating institutions (Bank of America and Goldman Sachs) remain private Weuse Pedersen commitments so the commitment part of the row has values gminus106

hr1 g106hr2 and hr3 hrn Similarly audit tokens pictured

have values (pk1)r1 (pk2)

r2 For each bank Banki the corresponding column also includes proof-of-assets πAi proof-of-balance πB

i andproof-of-consistency πC

i

total all of the commitments in its column to respond tothe Auditormdasheven commitments for transactions in whichit was not involved A malicious Banki could create atransaction and not inform the another Bank j of the r jused in its entry even if it is not transferring assets toBank j Bank j would be unable to respond to the Auditorbecause it would not be able to open up the product of thecommitments in its column

In order to prove the integrity of a transfer transactionzkLedger must ensure an additional invariant

bull All banks have enough information in the transactionto open up commitments for the Auditor

zkLedger does this by requiring the spending bank toinclude a publicly verifiable Token in every entry Thisis defined as Tokenk = (pkk)

rk Bankk uses this token toopen up the product of its commitments for the Auditorwithout needing to know rkUsing audit tokens Consider a query for a sum of valuesin a bankrsquos column One way of answering this querywould be to reveal sumvk and sumrk Then the auditor wouldsimply check that these plain values are consistent withthe homomorphically computed value prodcmk = gsumvk hsumrk

However a bank does not necessarily know all thecommitment randomnesses rk (in particular these valuesare unknown for any transaction that the bank was notparty to) so the naive approach does not work

One approach could be to ask the preparer of the trans-action (ie the sender) to encrypt rk so that the non-participating bank Bankk can decrypt it To prevent thesending bank from placing a ldquogarbagerdquo ciphertext on theledger (and thus making Bankk fail the auditorrsquos queries)one would need a zero-knowledge proof of consistencybetween the encrypted value and the commitment Con-structing a concretely efficient proof for this statement isnon-trivial in a nutshell standard encryption schemes(eg ElGamal) embed plain-text in a group element whilePedersen commitments would have this value in the expo-nent

Our insight is that Bankk does not need to open sumrkto prove that sumvk is correct Instead suppose that Bankk

wants to claim that s = gsumvk hsumrk opens up to a valuesumvk To do so the bank computes sprime = sgsumvk = hsumrk andt = prodk Tokenk = hsksumrk Note that the auditor can alsocompute the values of sprime and t from the ledger and theclaimed answer sumvk

It suffices for the bank to prove that logsprime t = logh pkObserve that both logarithms evaluate to sk so a bank canproduce this proof without knowing sumri Moreover ifthis equation holds then t1sk = sprime = sgsumv but if the sumvwas incorrect then knowledge of sk would reveal a linearrelationship between g and h which is ruled out by oursecurity assumption

To show that the r in the Tokenk is the same as ther in rk we require an additional Proof of Consistency(πC) This is a zero-knowledge proof asserting that foreach k the value rk used to form cmk and Tokenk is thesame (See Appendix B for details of how such proof isconstructed)

Note that audit tokens are only useful to the bank open-ing its commitment though public a malicious bankcannot use another bankrsquos Token to successfully open anincorrect result or learn information about other bankrsquostransactions

43 Final transaction constructionFor a transfer transaction in row m each entry i containsthe following itemsbull Commitment (cmi) (gvihri) a Pedersen commitment

to the value we are transferringbull Audit Token (Tokeni) (pki)

ri This is used to answeraudits without knowing the randomness used in thecommitment

bull Proof of Balance (πB) a zero-knowledge proof assert-ing that the committed values satisfy sum

nk=1 vk = 0

bull Proof of Assets (πA) a new commitment cmprimei corre-sponding token Tokenprimei and a zero-knowledge proofasserting that either cmprimei is a re-commitment of thevalue in cmi or a recommitment to the sum of the val-ues in prod

mj=0 cm j and cmprimei is in range [0240) If the

committed value in cmi is negative the proof assertsbank i consented to the transfer

72 15th USENIX Symposium on Networked Systems Design and Implementation USENIX Association

bull Proof of Consistency (πC) two zero-knowledgeproofs asserting the randomness used in cmi and Tokeniare the same and the randomness used in cmprimei andTokenprimei are the same This is to prevent a maliciousbank from adding data to the ledger that would stopanother bank from being able to open its commitmentsfor the AuditorTransactions may contain additional metadata in plain-

text or not For example banks might want to includeencrypted account numbers addresses or identifying in-formation on behalf of a customer to satisfy the TravelRule specified in the Bank Secrecy Act of 1970 [1] zk-Ledger supports auditing over metadata in the transactionas well but it does not have a way to publicly verifyadditional metadata

44 Adding or removing bankszkLedger can support dynamically adding or removingbanks if done so publicly The participants (or anotherauthority) append a signed transaction to the ledger indi-cating which banks and thus columns should be addedor removed For example to add a new bank to theledger shown in Figure 2 the involved banks would ap-pend a transaction to the ledger indicating an intent toadd Bankn+1 From that point forward all transactionsshould contain n+ 1 entries The Proof of Assets forBankn+1rsquos entry in each transaction will start at the rowwhere Bankn+1 was added Similarly if a bank is re-moved later transactions should not include entries forthat bank Since all participants can see which bankswere added or removed they can adjust their proofs andverifications accordingly

45 OptimizationszkLedger employs several optimizations to make produc-ing and verifying these proofs faster and to support fasterauditing First caching the product of the commitmentsin a bankrsquos column improves auditing and proof creationspeed Each bank stores a rolling product of commitmentsby row and by asset so that it can quickly produce proofsof assets and answer queries from auditors Using thesecaches a bank can quickly answer an auditorrsquos query ona subset of rows in the ledger

Most transactions in zkLedger do not include everybank Every bank can pre-generate many range proofsfor the value 0 We speedup transaction throughput byparallelizing range proof generation and validation

5 AuditingAuditing is a critical component of the financial systemand regulators use various techniques to measure systemicfinancial risk Through the use of sums means ratios

variance co-variance and standard deviation an auditorin zkLedger can determine the following among othermeasurementsbull Leverage ratios zkLedger can show how much of an

asset a bank has on its books compared to its otherholdings This is helpful to estimate counterparty risk

bull Concentration Regulators use a measure called theHerfindahl-Hirschman Index (HHI) to measure howcompetitive an industry is [29]

bull Real-time price indexes Auditors can get a sense ofthe price of assets that are traded over-the-counter andthus not tracked through exchangesNatively zkLedger supports sums which means linear

combinations of values stored in the ledger This comesfrom the additive structure of Pedersen commitmentsBut zkLedger also supports a more general query modelwhich can be considered in two parts A map step and areduce stepBasic auditing Consider the basic example where anauditor wants to determine how much of an asset a bankhas on its books As described in sect42 the auditor willfilter the rows by asset multiply the entries in the bankrsquoscolumn and then ask the bank to open the commitmentproduct This only requires one round of communica-tion between the auditor and the bank and the messagesare a constant size independent of the number of rowsBecause of zkLedgerrsquos commitment caches this is veryfastMapreduce An auditor can issue more complex queriesthat might require the exchange of more data or mightrequire the participants to look at most of the rows in theledger Letrsquos consider an auditor which wants to know themean transaction size for a given bank and asset An au-ditor cannot verify a bankrsquos answer by simply totaling thebankrsquos column of commitments and dividing the openedvalue by the number of rows because such a computationwould have an incorrect denominator Namely when thebank is not involved in a transaction its column in therow will be commitment to 0 and should be discountedIn order to determine the correct denominator the auditorand the bank run the following protocol1 Filter The bank will filter the rows by asset2 Produce new commitments For each row the bank

will commit to a single bit b 1 or 0 depending on ifthe bank was involved in the transaction or not and cre-ate a proof that the bank has done this recommitmentcorrectly Crucially the auditor cannot distinguishbetween these commitments and so the bankrsquos trans-actions are not revealed We call this act of producingnew commitments the map step The map step alsorequires producing proofs that the new values were

USENIX Association 15th USENIX Symposium on Networked Systems Design and Implementation 73

correctly computed in our example for each transac-tion the bank would produce a NIZK proof that b = 1if and only if the transaction value was not equal to 0

3 Compute number of non-zero transactions Thebank computes the homomorphic sum of the new com-mitments to bits~b and opens it to reveal how manytransactions were non-zero This is the reduce stepThis is the correct denominator to compute the meantransaction size The auditor cannot tell anything aboutthe values in~b beyond what is revealed by the sum

4 Respond to auditor The bank then sends the auditorthe sum of the values in its column the vector of bitcommitments and corresponding NIZK proofs thenumber of its non-zero transactions n and the sum ofthe r values in the commitments

5 Verification The auditor verifies the map step byverifying the commitments were done correctly andverifies the reduce step and the number of non-zerotransactions by confirming that the product of the vec-tor of bit commitments is gnhsum

Nk=1 rk

6 Compute answer The auditor computes the meanfrom the sum of the bankrsquos column and the number ofnon-zero transactionsAn auditor could ask a bank for outlier transactions

using a similar technique For each row the bank willcommit to a bit b where b = 1 if a transactionrsquos value forthat bank is outside a specified range As when computingthe mean the auditor can verify these commitments wereproduced correctly and obtain the sum The bank can thenopen only the transactions where b = 1 and the auditorknows exactly how many transactions should be opened

More complex auditing queries require multiple mapand reduce computations For example here is howan auditor can learn the variance of transaction valuesv1 vN

1 Compute the average transaction value Executethe protocol described above to compute the numberof non-zero transactions n and their average value v

2 Apply the squaring map For each entry vi in its rowthe bank produces a fresh commitment cmprimei to v2

i andsends these commitments to the auditor The bank alsosupplies NIZK proofs that the value hidden in eachcmprimei is exactly the square of the value vi committed toon the ledger

3 Apply the reduce step The auditor computes theproduct of the commitments cmprimei and the bank opensup this commitment as V = v2

1 + middot middot middot+ v2N by revealing

R = sumNi=1 ri The auditor confirms that the product of

the commitments is equal to gV hR

The auditor now computes the variance σ as followsσ2 = 1

n sumvi 6=0(viminus v)2 = 1nV minus v2

We note that whereas the square mapping used abovecorresponds to the second moment (variance) zkLedgercan also compute higher statistical moments (eg skew-ness and kurtosis) using similar techniques and usingcubing and fourth power mappings respectively See Ap-pendix A for a list of measurements zkLedger supports

zkLedger can support limited information release byusing more complex reduce mappings For example in-stead of releasing the sum of values the bank can producea commitment to the rounded sum of values (eg to thefirst two decimal places) and use range proofs also im-plemented in zkLedger to show that the rounding wasdone correctly Revealing just the order of magnitude ofthe quantity at hand lets the parties balance the granularityof information disclosure6 ImplementationTo evaluate zkLedgerrsquos design we implemented a pro-totype of zkLedger in Go Our prototype uses a modi-fied version of the btcec library [2] that contains the pa-rameters and methods to compute with the elliptic curvesecp256k1 We use Gorsquos built-in SHA-256 implementa-tion for our cryptographic hash function and determin-istically pick g and h by applying point decompressionto the ldquonothing-up-my-sleeverdquo strings SHA256(0) andSHA256(1) Our prototype consists of approximately3200 lines of code of which 40 implement crypto-graphic tools used by zkLedger (zero-knowledge proofsrange proofs etc)

The implementation of the curve in zkLedger uses GorsquosbigInt type which we make no effort to compress orserialize in an efficient way A more optimized imple-mentation could compress curve points Our range proofsimplement the protocol used in Confidential Assets [42]Our NIZKs are based on Generalized Schnorr Proofswhich are three move interactive protocols to make themnon-interactive we apply the Fiat-Shamir heuristic [26]where we instantiate the random oracle using the SHA-256 hash function Our prototype implementation doesnot implement the complex queries described in sect5 andthus we do not evaluate them in sect7

7 EvaluationOur evaluation answers the following questionsbull How expensive is it to store prove and verify the differ-

ent proofs in zkLedger (sect72)bull How does auditing scale with the size of the ledger

(sect73)bull How does zkLedger scale with the number of banks

(sect74)

74 15th USENIX Symposium on Networked Systems Design and Implementation USENIX Association

Component Create Verify Size

2k Commitment 05 ms 05 ms 64 B2k Consistency 07 ms 08 ms 224 Bk Disjunctive 09 ms 09 ms 288 Bk Range 47 ms 35 ms 3936 B

Table 1 Number of each proof component in a transaction for k banksSize of and time to create and verify the components with 12 cores Therange proof create and verify benefit from the additional cores

71 Experimental setup

Microbenchmarks We run microbenchmarks on a 12core Intel machine with i7-X980 333 GHz CPUs and24GB of RAM running 64-bit Linux 440 on Ubuntu16043 Each microbenchmark runs the same code aBank runs to create and validate transactions

Distributed experiment We run the distributed experi-ments on a set of 12 virtual machines each with 4 cores ofIntel Xeon E5-2640 25 GHz processors 24GB of RAMand the same software setup as above There is one au-ditor one server providing the service of the ledger anda varying number of banks one per server Servers com-municate using the netrpc Go package over TCP Allexperiments use Go version 19

72 Proof overhead in zkLedgerTable 1 shows the time to prove and verify the proofs in atransaction in zkLedger There are two commitments twoconsistency proofs and one each of the disjunctive andrange proofs in a transaction entry There is a transactionentry per Bank Table 1 also shows the sizes of the variousproofs in bytes These sizes are estimated based on thesize of the underlying fields in the struct in memorythese proofs could be further compressed Range proofsdominate the size of the transactions

The left graph in Figure 3 shows the time it takes tocreate and verify a transaction varying the number ofoverall banks which increases the number of entries pertransaction This indicates that as we increase the numberof banks both transaction creation and verification timesper bank increase linearly but parallelization helps Prov-ing and validating range proofs dominates transactioncreation and verification but this cost is also highly paral-lelizable 12 cores gives a 28times speedup when creating atransaction with 20 banks a bank can create or validate atransaction for up to 20 banks in less than 200ms

As described in sect41 zkLedger uses Borromean ringsignatures to prove that a value is in a certain range andsupports values up to 240 Reducing the supported rangeof values would reduce range proof cost since that cost islinear in the number of bits in the size of the range Thereare also newer proof systems such as Bulletproofs which

might create much smaller range proofs [13] We plan toevaluate zkLedger with Bulletproofs in future work

73 Cost of auditing ledgersThe left graph in Figure 4 shows that for certain func-tions the time to audit is independent of the number oftransactions in the ledger This is because the Auditorand Banks maintain commitment caches which alreadyhave the commitment product necessary to prove to theauditor the sum of the values in its column The auditfunction is measuring the Herfindhal-Hirschman Indexso the auditor communicates with each bank

When the auditor cannot use a commitment cache per-haps because it was offline it must process the wholeledger to compute the commitment product This alsoapplies to more complex auditing like the types describedin sect5 when the auditor has to verify recommitments forevery row in the ledger These costs are shown in themiddle graph in Figure 4 This graph shows how long ittakes the auditor to compute the Herfindahl-HirschmanIndex on a ledger of varying sizes without using the com-mitment caches so the auditor must process every row ofthe ledger In these measurements the auditor does notverify each row As expected this time increases linearlywith the number of rows This indicates that maintainingcommitment caches is important for real-time auditingHowever even without commitment caches auditing timeis reasonable 35 seconds for 100K transactions Thissuggests the complex auditing queries in which the au-ditor computes a similar set of operations per row willalso be on the order of many seconds zkLedger currentlyonly maintains commitment product caches per asset perbank but could maintain more

For a fixed size ledger this audit function costs orderthe number of banks The right graph in Figure 4 demon-strates the auditing costs of computing the Herfindahl-Hirschman Index on a ledger of 2000 transactions as wevary the number of banks both with and without com-mitment caches The auditor audits the banks in parallelAuditing cost for this function grows slightly with thenumber of banks since more banks increase the variabil-ity in parallel auditing and the auditor must wait for thelast bank to respond before computing the final answer

In these figures each point is the mean of running theauditing query 20 times with error bars representing onestandard deviation from the mean

74 Scaling with more banksThere are two significant costs that grow with the numberof banks in zkLedger a serial step to create transactionsthat increases linearly and verifying transactions whichincreases quadratically with the number of banks As

USENIX Association 15th USENIX Symposium on Networked Systems Design and Implementation 75

0

100

200

300

400

500

600

2 4 6 8 10 12 14 16 18 20

Tim

e (

ms)

number of banks

verify-1create-1verify-12

create-12

0

200

400

600

800

1000

2 3 4 5 6 7 8 9 10

Tim

e (

ms)

number of banks

complete transactions

0

2

4

6

8

10

12

2 3 4 5 6 7 8 9 10

Th

rou

gh

pu

t (t

xn

ss

ec)

number of banks

all banks transactingone bank transacting

Figure 3 Transaction creation and verification time for one bank (left) varying the number of entries in the transaction Single-threaded andmulti-threaded performance with 12 threads Time to fully process a transaction including creation broadcast to ledger banks and auditor andverification by all parties (middle) Throughput (right) varying the number of banks

0

2

4

6

8

10

12

0K 20K 40K 60K 80K 100K

Au

ditin

g t

ime

(m

s)

Transactions in ledger

online auditor

0

500

1000

1500

2000

2500

3000

3500

0K 20K 40K 60K 80K 100K

Transactions in ledger

offline auditor

0

20

40

60

80

100

120

2 3 4 5 6 7 8 9 10

Number of banks

offline auditor

online auditor

Figure 4 Time to audit ledgers of different sizes (4 banks) and with a varying number of banks (2000 row ledger) Audit time is independent of thesize of the ledger (left) thanks to commitment caches maintained by the online auditor When commitment cache optimization is turned off (middle)the audit time is linear in the size of the ledger Audit time grows with the number of banks (right) and is much higher without commitment caches

described in sect41 a bank needs to use its entry fromtransaction nminus1 to create transaction n So though a bankcan use many cores to produce the proofs for a singletransaction in parallel multiple banks cannot producedifferent transactions in parallel In zkLedger banks startcreating transaction n before seeing nminus 1 but the bankcannot complete the transaction until nminus1 is accepted tothe ledger and verified causing an inherent bottleneck

The second major cost is around verification Everybank must verify every transaction so the more banksthe larger each transaction and thus the more work thatneeds to be done by each bank The middle graph inFigure 3 measures the time it takes one bank to createand all participants in zkLedger to completely processa transaction One bank creates a transaction and sendsit to the ledger which then broadcasts the transaction toall banks and an online auditor The auditor and everybank verify the transaction As we increase the numberof banks work increases quadratically however bankscan verify transactions in parallel so the time to processtransactions only increases linearly The right graph inFigure 3 shows that as we surmised zkLedgerrsquos through-put worsens with more banks The one bank transactingline in this graph is the same data as the middle graph

Since range proofs dominate the costs of transactioncreation and verification we are optimistic that a fasterrange proof implementation will directly improve perfor-mance zkLedgerrsquos current performance is comparableto Solidus a privacy-preserving distributed ledger whichachieves 3-4 transactions per second with online valida-tion but unlike zkLedger does not support auditing

8 Future workzkLedger focuses on providing provably correct auditingover private transaction data but zkLedger does not havea way to recover if the distributed ledger is corrupted Inthis case the parties maintaining the ledger would haveto come together to recreate historical transactions zk-Ledger also does not provide recourse if a bank commitsan unintended transaction to the ledger A future ver-sion of zkLedger might provide rectifying transactions orparticipant agreed-upon rollback

9 ConclusionzkLedger is the first distributed ledger system to providestrong transaction privacy public verifiability and com-plete provably correct auditing zkLedger supports a richset of auditing queries which are useful to measure thefinancial health of a market We developed a design usingnon-interactive zero-knowledge proofs to prove transac-tions maintain financial invariants and to support auditingOur evaluation shows that zkLedger has reasonable per-formance for transaction settlement and auditing

10 AcknowledgementsWe thank Alexander Chernyakhovsky Thaddeus DryjaDavid Lazar Ronald L Rivest CJ Williams and ourshepherd and reviewers for helpful comments The re-search leading to these results has received funding fromthe Center for Science of Information (CSoI) an NSFScience and Technology Center under grant agreementCCF-0939370 and the Ethics and Governance of Artifi-cial Intelligence Fund

76 15th USENIX Symposium on Networked Systems Design and Implementation USENIX Association

References[1] Bank secrecy act of 1970 October 1970 12 USC 103[2] Package btcec implements support for the elliptic curves

needed for Bitcoin July 2017 httpsgodocorggithubcombtcsuitebtcdbtcec

[3] ABBE E A KHANDANI A E AND LO A WPrivacy-preserving methods for sharing financial risk ex-posures The American Economic Review 102 3 (2012)65ndash70

[4] ARASU A BLANAS S EGURO K KAUSHIK RKOSSMANN D RAMAMURTHY R AND VENKATE-SAN R Orthogonal security with cipherbase In CIDR(2013)

[5] BAJAJ S AND SION R Trusteddb A trusted hardware-based database with privacy and data confidentiality IEEETransactions on Knowledge and Data Engineering 26 3(2014) 752ndash765

[6] BAUMANN A PEINADO M AND HUNT G Shieldingapplications from an untrusted cloud with haven ACMTransactions on Computer Systems (TOCS) 33 3 (2015)8

[7] BEN-SASSON E CHIESA A GENKIN D TROMERE AND VIRZA M SNARKs for C Verifying programexecutions succinctly and in zero knowledge In Advancesin CryptologyndashCRYPTO 2013 Springer 2013 pp 90ndash108

[8] BEN-SASSON E CHIESA A GREEN M TROMERE AND VIRZA M Secure sampling of public parametersfor succinct zero knowledge proofs In Proceedings of the2015 IEEE Symposium on Security and Privacy (2015)SP rsquo15 pp 287ndash304

[9] BLUM M FELDMAN P AND MICALI S Non-interactive zero-knowledge and its applications In Pro-ceedings of the 20th Annual ACM Symposium on Theoryof Computing (1988) STOC rsquo88 pp 103ndash112

[10] BOGDANOV D TALVISTE R AND WILLEMSON JDeploying secure multi-party computation for financialdata analysis In International Conference on FinancialCryptography and Data Security (2012) Springer pp 57ndash64

[11] BOWE S GABIZON A AND GREEN M A multi-party protocol for constructing the public parameters ofthe Pinocchio zk-SNARK Cryptology ePrint ArchiveReport 2017602 2017

[12] BOWE S GABIZON A AND MIERS I Scalable multi-party computation for zk-SNARK parameters in the ran-dom beacon model Cryptology ePrint Archive Report20171050 2017

[13] BUNZ B BOOTLE J BONEH D POELSTRA AAND MAXWELL G Bulletproofs Short proofs for Con-fidential Transactions and more In Security and Privacy(SP) 2018 IEEE Symposium on (2018) IEEE

[14] BURKHART M STRASSER M MANY D AND DIM-ITROPOULOS X Sepia Privacy-preserving aggregationof multi-domain network events and statistics Network 1101101 (2010)

[15] CASTRO M AND LISKOV B Practical byzantine faulttolerance In OSDI (1999) vol 99 pp 173ndash186

[16] CECCHETTI E ZHANG F JI Y KOSBA A JUELSA AND SHI E Solidus Confidential distributed ledgertransactions via pvorm

[17] CHAIN I Confidential assets httpsblogchaincomhidden-in-plain-sight-transacting-privately-on-a-blockchain-835ab75c01cb

[18] CORRIGAN-GIBBS H AND BONEH D Prio Privaterobust and scalable computation of aggregate statisticsarXiv preprint arXiv170306255 (2017)

[19] COUNCIL F R Developments in audit 20162017full report 2017 httpwwwfrcorgukgetattachment915c15a4-dbc7-4223-b8ae-cad53dbcca17Developments-in-Audit-2016-17-Full-reportpdf

[20] CRAMER R DAMGARD I AND SCHOENMAKERSB Proofs of partial knowledge and simplified design ofwitness hiding protocols In Advances in Cryptology -CRYPTO rsquo94 14th Annual International Cryptology Con-ference Santa Barbara California USA August 21-251994 Proceedings (1994) pp 174ndash187

[21] DAGHER G G BUNZ B BONNEAU J CLARK JAND BONEH D Provisions Privacy-preserving proofsof solvency for Bitcoin exchanges In Proceedings of the22nd ACM SIGSAC Conference on Computer and Com-munications Security (Denver CO 2015) ACM pp 720ndash731

[22] Corda 2017 httpsgithubcomcordacorda

[23] Digital asset holdings 2017 httpdigitalassetcom

[24] Regulation (EU) 2016679 of the European Parliamentand of the Council of 27 April 2016 on the protection ofnatural persons with regard to the processing of personaldata and on the free movement of such data and repealingDirective 9546EC (General Data Protection Regulation)Official Journal of the European Union L119 (May 2016)1ndash88

[25] FELDMAN A J ZELLER W P FREEDMAN M JAND FELTEN E W Sporc Group collaboration us-ing untrusted cloud resources In OSDI (2010) vol 10pp 337ndash350

[26] FIAT A AND SHAMIR A How to prove yourselfpractical solutions to identification and signature problemsIn Proceedings of the 6th Annual International CryptologyConference (1987) CRYPTO rsquo87 pp 186ndash194

[27] GARMAN C GREEN M AND MIERS I Accountableprivacy for decentralized anonymous payments Cryp-tology ePrint Archive Report 2016061 2016 httpeprintiacrorg2016061

[28] GREENBERG A Fbi says itrsquos seized $285 million inbitcoins from ross ulbricht alleged owner of silk roadForbes 25 (2013)

USENIX Association 15th USENIX Symposium on Networked Systems Design and Implementation 77

Metadata Bank1 Bank2 Bank3 BanknID Asset Time (Bank of America) (Goldman Sachs) (JPMorgan) (Citigroup)

1 e 130601 COMM(minus106r1) COMM(106r2) COMM(0r3) middot middot middot COMM(0rn)21718 Token1 Token2 Token2 middot middot middot Tokenn

πA1 π

B1 π

C1 πA

2 πB2 π

C2 πA

3 πB3 π

C3 middot middot middot πA

n πBn π

Cn

Figure 2 Contents of the ledger pertaining to a transaction that sends 106 euros from Bank1 to Bank2 Note that while asset type (euro) is visibleas part of the metadata the transaction amount (106 e) and participating institutions (Bank of America and Goldman Sachs) remain private Weuse Pedersen commitments so the commitment part of the row has values gminus106

hr1 g106hr2 and hr3 hrn Similarly audit tokens pictured

have values (pk1)r1 (pk2)

r2 For each bank Banki the corresponding column also includes proof-of-assets πAi proof-of-balance πB

i andproof-of-consistency πC

i

total all of the commitments in its column to respond tothe Auditormdasheven commitments for transactions in whichit was not involved A malicious Banki could create atransaction and not inform the another Bank j of the r jused in its entry even if it is not transferring assets toBank j Bank j would be unable to respond to the Auditorbecause it would not be able to open up the product of thecommitments in its column

In order to prove the integrity of a transfer transactionzkLedger must ensure an additional invariant

bull All banks have enough information in the transactionto open up commitments for the Auditor

zkLedger does this by requiring the spending bank toinclude a publicly verifiable Token in every entry Thisis defined as Tokenk = (pkk)

rk Bankk uses this token toopen up the product of its commitments for the Auditorwithout needing to know rkUsing audit tokens Consider a query for a sum of valuesin a bankrsquos column One way of answering this querywould be to reveal sumvk and sumrk Then the auditor wouldsimply check that these plain values are consistent withthe homomorphically computed value prodcmk = gsumvk hsumrk

However a bank does not necessarily know all thecommitment randomnesses rk (in particular these valuesare unknown for any transaction that the bank was notparty to) so the naive approach does not work

One approach could be to ask the preparer of the trans-action (ie the sender) to encrypt rk so that the non-participating bank Bankk can decrypt it To prevent thesending bank from placing a ldquogarbagerdquo ciphertext on theledger (and thus making Bankk fail the auditorrsquos queries)one would need a zero-knowledge proof of consistencybetween the encrypted value and the commitment Con-structing a concretely efficient proof for this statement isnon-trivial in a nutshell standard encryption schemes(eg ElGamal) embed plain-text in a group element whilePedersen commitments would have this value in the expo-nent

Our insight is that Bankk does not need to open sumrkto prove that sumvk is correct Instead suppose that Bankk

wants to claim that s = gsumvk hsumrk opens up to a valuesumvk To do so the bank computes sprime = sgsumvk = hsumrk andt = prodk Tokenk = hsksumrk Note that the auditor can alsocompute the values of sprime and t from the ledger and theclaimed answer sumvk

It suffices for the bank to prove that logsprime t = logh pkObserve that both logarithms evaluate to sk so a bank canproduce this proof without knowing sumri Moreover ifthis equation holds then t1sk = sprime = sgsumv but if the sumvwas incorrect then knowledge of sk would reveal a linearrelationship between g and h which is ruled out by oursecurity assumption

To show that the r in the Tokenk is the same as ther in rk we require an additional Proof of Consistency(πC) This is a zero-knowledge proof asserting that foreach k the value rk used to form cmk and Tokenk is thesame (See Appendix B for details of how such proof isconstructed)

Note that audit tokens are only useful to the bank open-ing its commitment though public a malicious bankcannot use another bankrsquos Token to successfully open anincorrect result or learn information about other bankrsquostransactions

43 Final transaction constructionFor a transfer transaction in row m each entry i containsthe following itemsbull Commitment (cmi) (gvihri) a Pedersen commitment

to the value we are transferringbull Audit Token (Tokeni) (pki)

ri This is used to answeraudits without knowing the randomness used in thecommitment

bull Proof of Balance (πB) a zero-knowledge proof assert-ing that the committed values satisfy sum

nk=1 vk = 0

bull Proof of Assets (πA) a new commitment cmprimei corre-sponding token Tokenprimei and a zero-knowledge proofasserting that either cmprimei is a re-commitment of thevalue in cmi or a recommitment to the sum of the val-ues in prod

mj=0 cm j and cmprimei is in range [0240) If the

committed value in cmi is negative the proof assertsbank i consented to the transfer

72 15th USENIX Symposium on Networked Systems Design and Implementation USENIX Association

bull Proof of Consistency (πC) two zero-knowledgeproofs asserting the randomness used in cmi and Tokeniare the same and the randomness used in cmprimei andTokenprimei are the same This is to prevent a maliciousbank from adding data to the ledger that would stopanother bank from being able to open its commitmentsfor the AuditorTransactions may contain additional metadata in plain-

text or not For example banks might want to includeencrypted account numbers addresses or identifying in-formation on behalf of a customer to satisfy the TravelRule specified in the Bank Secrecy Act of 1970 [1] zk-Ledger supports auditing over metadata in the transactionas well but it does not have a way to publicly verifyadditional metadata

44 Adding or removing bankszkLedger can support dynamically adding or removingbanks if done so publicly The participants (or anotherauthority) append a signed transaction to the ledger indi-cating which banks and thus columns should be addedor removed For example to add a new bank to theledger shown in Figure 2 the involved banks would ap-pend a transaction to the ledger indicating an intent toadd Bankn+1 From that point forward all transactionsshould contain n+ 1 entries The Proof of Assets forBankn+1rsquos entry in each transaction will start at the rowwhere Bankn+1 was added Similarly if a bank is re-moved later transactions should not include entries forthat bank Since all participants can see which bankswere added or removed they can adjust their proofs andverifications accordingly

45 OptimizationszkLedger employs several optimizations to make produc-ing and verifying these proofs faster and to support fasterauditing First caching the product of the commitmentsin a bankrsquos column improves auditing and proof creationspeed Each bank stores a rolling product of commitmentsby row and by asset so that it can quickly produce proofsof assets and answer queries from auditors Using thesecaches a bank can quickly answer an auditorrsquos query ona subset of rows in the ledger

Most transactions in zkLedger do not include everybank Every bank can pre-generate many range proofsfor the value 0 We speedup transaction throughput byparallelizing range proof generation and validation

5 AuditingAuditing is a critical component of the financial systemand regulators use various techniques to measure systemicfinancial risk Through the use of sums means ratios

variance co-variance and standard deviation an auditorin zkLedger can determine the following among othermeasurementsbull Leverage ratios zkLedger can show how much of an

asset a bank has on its books compared to its otherholdings This is helpful to estimate counterparty risk

bull Concentration Regulators use a measure called theHerfindahl-Hirschman Index (HHI) to measure howcompetitive an industry is [29]

bull Real-time price indexes Auditors can get a sense ofthe price of assets that are traded over-the-counter andthus not tracked through exchangesNatively zkLedger supports sums which means linear

combinations of values stored in the ledger This comesfrom the additive structure of Pedersen commitmentsBut zkLedger also supports a more general query modelwhich can be considered in two parts A map step and areduce stepBasic auditing Consider the basic example where anauditor wants to determine how much of an asset a bankhas on its books As described in sect42 the auditor willfilter the rows by asset multiply the entries in the bankrsquoscolumn and then ask the bank to open the commitmentproduct This only requires one round of communica-tion between the auditor and the bank and the messagesare a constant size independent of the number of rowsBecause of zkLedgerrsquos commitment caches this is veryfastMapreduce An auditor can issue more complex queriesthat might require the exchange of more data or mightrequire the participants to look at most of the rows in theledger Letrsquos consider an auditor which wants to know themean transaction size for a given bank and asset An au-ditor cannot verify a bankrsquos answer by simply totaling thebankrsquos column of commitments and dividing the openedvalue by the number of rows because such a computationwould have an incorrect denominator Namely when thebank is not involved in a transaction its column in therow will be commitment to 0 and should be discountedIn order to determine the correct denominator the auditorand the bank run the following protocol1 Filter The bank will filter the rows by asset2 Produce new commitments For each row the bank

will commit to a single bit b 1 or 0 depending on ifthe bank was involved in the transaction or not and cre-ate a proof that the bank has done this recommitmentcorrectly Crucially the auditor cannot distinguishbetween these commitments and so the bankrsquos trans-actions are not revealed We call this act of producingnew commitments the map step The map step alsorequires producing proofs that the new values were

USENIX Association 15th USENIX Symposium on Networked Systems Design and Implementation 73

correctly computed in our example for each transac-tion the bank would produce a NIZK proof that b = 1if and only if the transaction value was not equal to 0

3 Compute number of non-zero transactions Thebank computes the homomorphic sum of the new com-mitments to bits~b and opens it to reveal how manytransactions were non-zero This is the reduce stepThis is the correct denominator to compute the meantransaction size The auditor cannot tell anything aboutthe values in~b beyond what is revealed by the sum

4 Respond to auditor The bank then sends the auditorthe sum of the values in its column the vector of bitcommitments and corresponding NIZK proofs thenumber of its non-zero transactions n and the sum ofthe r values in the commitments

5 Verification The auditor verifies the map step byverifying the commitments were done correctly andverifies the reduce step and the number of non-zerotransactions by confirming that the product of the vec-tor of bit commitments is gnhsum

Nk=1 rk

6 Compute answer The auditor computes the meanfrom the sum of the bankrsquos column and the number ofnon-zero transactionsAn auditor could ask a bank for outlier transactions

using a similar technique For each row the bank willcommit to a bit b where b = 1 if a transactionrsquos value forthat bank is outside a specified range As when computingthe mean the auditor can verify these commitments wereproduced correctly and obtain the sum The bank can thenopen only the transactions where b = 1 and the auditorknows exactly how many transactions should be opened

More complex auditing queries require multiple mapand reduce computations For example here is howan auditor can learn the variance of transaction valuesv1 vN

1 Compute the average transaction value Executethe protocol described above to compute the numberof non-zero transactions n and their average value v

2 Apply the squaring map For each entry vi in its rowthe bank produces a fresh commitment cmprimei to v2

i andsends these commitments to the auditor The bank alsosupplies NIZK proofs that the value hidden in eachcmprimei is exactly the square of the value vi committed toon the ledger

3 Apply the reduce step The auditor computes theproduct of the commitments cmprimei and the bank opensup this commitment as V = v2

1 + middot middot middot+ v2N by revealing

R = sumNi=1 ri The auditor confirms that the product of

the commitments is equal to gV hR

The auditor now computes the variance σ as followsσ2 = 1

n sumvi 6=0(viminus v)2 = 1nV minus v2

We note that whereas the square mapping used abovecorresponds to the second moment (variance) zkLedgercan also compute higher statistical moments (eg skew-ness and kurtosis) using similar techniques and usingcubing and fourth power mappings respectively See Ap-pendix A for a list of measurements zkLedger supports

zkLedger can support limited information release byusing more complex reduce mappings For example in-stead of releasing the sum of values the bank can producea commitment to the rounded sum of values (eg to thefirst two decimal places) and use range proofs also im-plemented in zkLedger to show that the rounding wasdone correctly Revealing just the order of magnitude ofthe quantity at hand lets the parties balance the granularityof information disclosure6 ImplementationTo evaluate zkLedgerrsquos design we implemented a pro-totype of zkLedger in Go Our prototype uses a modi-fied version of the btcec library [2] that contains the pa-rameters and methods to compute with the elliptic curvesecp256k1 We use Gorsquos built-in SHA-256 implementa-tion for our cryptographic hash function and determin-istically pick g and h by applying point decompressionto the ldquonothing-up-my-sleeverdquo strings SHA256(0) andSHA256(1) Our prototype consists of approximately3200 lines of code of which 40 implement crypto-graphic tools used by zkLedger (zero-knowledge proofsrange proofs etc)

The implementation of the curve in zkLedger uses GorsquosbigInt type which we make no effort to compress orserialize in an efficient way A more optimized imple-mentation could compress curve points Our range proofsimplement the protocol used in Confidential Assets [42]Our NIZKs are based on Generalized Schnorr Proofswhich are three move interactive protocols to make themnon-interactive we apply the Fiat-Shamir heuristic [26]where we instantiate the random oracle using the SHA-256 hash function Our prototype implementation doesnot implement the complex queries described in sect5 andthus we do not evaluate them in sect7

7 EvaluationOur evaluation answers the following questionsbull How expensive is it to store prove and verify the differ-

ent proofs in zkLedger (sect72)bull How does auditing scale with the size of the ledger

(sect73)bull How does zkLedger scale with the number of banks

(sect74)

74 15th USENIX Symposium on Networked Systems Design and Implementation USENIX Association

Component Create Verify Size

2k Commitment 05 ms 05 ms 64 B2k Consistency 07 ms 08 ms 224 Bk Disjunctive 09 ms 09 ms 288 Bk Range 47 ms 35 ms 3936 B

Table 1 Number of each proof component in a transaction for k banksSize of and time to create and verify the components with 12 cores Therange proof create and verify benefit from the additional cores

71 Experimental setup

Microbenchmarks We run microbenchmarks on a 12core Intel machine with i7-X980 333 GHz CPUs and24GB of RAM running 64-bit Linux 440 on Ubuntu16043 Each microbenchmark runs the same code aBank runs to create and validate transactions

Distributed experiment We run the distributed experi-ments on a set of 12 virtual machines each with 4 cores ofIntel Xeon E5-2640 25 GHz processors 24GB of RAMand the same software setup as above There is one au-ditor one server providing the service of the ledger anda varying number of banks one per server Servers com-municate using the netrpc Go package over TCP Allexperiments use Go version 19

72 Proof overhead in zkLedgerTable 1 shows the time to prove and verify the proofs in atransaction in zkLedger There are two commitments twoconsistency proofs and one each of the disjunctive andrange proofs in a transaction entry There is a transactionentry per Bank Table 1 also shows the sizes of the variousproofs in bytes These sizes are estimated based on thesize of the underlying fields in the struct in memorythese proofs could be further compressed Range proofsdominate the size of the transactions

The left graph in Figure 3 shows the time it takes tocreate and verify a transaction varying the number ofoverall banks which increases the number of entries pertransaction This indicates that as we increase the numberof banks both transaction creation and verification timesper bank increase linearly but parallelization helps Prov-ing and validating range proofs dominates transactioncreation and verification but this cost is also highly paral-lelizable 12 cores gives a 28times speedup when creating atransaction with 20 banks a bank can create or validate atransaction for up to 20 banks in less than 200ms

As described in sect41 zkLedger uses Borromean ringsignatures to prove that a value is in a certain range andsupports values up to 240 Reducing the supported rangeof values would reduce range proof cost since that cost islinear in the number of bits in the size of the range Thereare also newer proof systems such as Bulletproofs which

might create much smaller range proofs [13] We plan toevaluate zkLedger with Bulletproofs in future work

73 Cost of auditing ledgersThe left graph in Figure 4 shows that for certain func-tions the time to audit is independent of the number oftransactions in the ledger This is because the Auditorand Banks maintain commitment caches which alreadyhave the commitment product necessary to prove to theauditor the sum of the values in its column The auditfunction is measuring the Herfindhal-Hirschman Indexso the auditor communicates with each bank

When the auditor cannot use a commitment cache per-haps because it was offline it must process the wholeledger to compute the commitment product This alsoapplies to more complex auditing like the types describedin sect5 when the auditor has to verify recommitments forevery row in the ledger These costs are shown in themiddle graph in Figure 4 This graph shows how long ittakes the auditor to compute the Herfindahl-HirschmanIndex on a ledger of varying sizes without using the com-mitment caches so the auditor must process every row ofthe ledger In these measurements the auditor does notverify each row As expected this time increases linearlywith the number of rows This indicates that maintainingcommitment caches is important for real-time auditingHowever even without commitment caches auditing timeis reasonable 35 seconds for 100K transactions Thissuggests the complex auditing queries in which the au-ditor computes a similar set of operations per row willalso be on the order of many seconds zkLedger currentlyonly maintains commitment product caches per asset perbank but could maintain more

For a fixed size ledger this audit function costs orderthe number of banks The right graph in Figure 4 demon-strates the auditing costs of computing the Herfindahl-Hirschman Index on a ledger of 2000 transactions as wevary the number of banks both with and without com-mitment caches The auditor audits the banks in parallelAuditing cost for this function grows slightly with thenumber of banks since more banks increase the variabil-ity in parallel auditing and the auditor must wait for thelast bank to respond before computing the final answer

In these figures each point is the mean of running theauditing query 20 times with error bars representing onestandard deviation from the mean

74 Scaling with more banksThere are two significant costs that grow with the numberof banks in zkLedger a serial step to create transactionsthat increases linearly and verifying transactions whichincreases quadratically with the number of banks As

USENIX Association 15th USENIX Symposium on Networked Systems Design and Implementation 75

0

100

200

300

400

500

600

2 4 6 8 10 12 14 16 18 20

Tim

e (

ms)

number of banks

verify-1create-1verify-12

create-12

0

200

400

600

800

1000

2 3 4 5 6 7 8 9 10

Tim

e (

ms)

number of banks

complete transactions

0

2

4

6

8

10

12

2 3 4 5 6 7 8 9 10

Th

rou

gh

pu

t (t

xn

ss

ec)

number of banks

all banks transactingone bank transacting

Figure 3 Transaction creation and verification time for one bank (left) varying the number of entries in the transaction Single-threaded andmulti-threaded performance with 12 threads Time to fully process a transaction including creation broadcast to ledger banks and auditor andverification by all parties (middle) Throughput (right) varying the number of banks

0

2

4

6

8

10

12

0K 20K 40K 60K 80K 100K

Au

ditin

g t

ime

(m

s)

Transactions in ledger

online auditor

0

500

1000

1500

2000

2500

3000

3500

0K 20K 40K 60K 80K 100K

Transactions in ledger

offline auditor

0

20

40

60

80

100

120

2 3 4 5 6 7 8 9 10

Number of banks

offline auditor

online auditor

Figure 4 Time to audit ledgers of different sizes (4 banks) and with a varying number of banks (2000 row ledger) Audit time is independent of thesize of the ledger (left) thanks to commitment caches maintained by the online auditor When commitment cache optimization is turned off (middle)the audit time is linear in the size of the ledger Audit time grows with the number of banks (right) and is much higher without commitment caches

described in sect41 a bank needs to use its entry fromtransaction nminus1 to create transaction n So though a bankcan use many cores to produce the proofs for a singletransaction in parallel multiple banks cannot producedifferent transactions in parallel In zkLedger banks startcreating transaction n before seeing nminus 1 but the bankcannot complete the transaction until nminus1 is accepted tothe ledger and verified causing an inherent bottleneck

The second major cost is around verification Everybank must verify every transaction so the more banksthe larger each transaction and thus the more work thatneeds to be done by each bank The middle graph inFigure 3 measures the time it takes one bank to createand all participants in zkLedger to completely processa transaction One bank creates a transaction and sendsit to the ledger which then broadcasts the transaction toall banks and an online auditor The auditor and everybank verify the transaction As we increase the numberof banks work increases quadratically however bankscan verify transactions in parallel so the time to processtransactions only increases linearly The right graph inFigure 3 shows that as we surmised zkLedgerrsquos through-put worsens with more banks The one bank transactingline in this graph is the same data as the middle graph

Since range proofs dominate the costs of transactioncreation and verification we are optimistic that a fasterrange proof implementation will directly improve perfor-mance zkLedgerrsquos current performance is comparableto Solidus a privacy-preserving distributed ledger whichachieves 3-4 transactions per second with online valida-tion but unlike zkLedger does not support auditing

8 Future workzkLedger focuses on providing provably correct auditingover private transaction data but zkLedger does not havea way to recover if the distributed ledger is corrupted Inthis case the parties maintaining the ledger would haveto come together to recreate historical transactions zk-Ledger also does not provide recourse if a bank commitsan unintended transaction to the ledger A future ver-sion of zkLedger might provide rectifying transactions orparticipant agreed-upon rollback

9 ConclusionzkLedger is the first distributed ledger system to providestrong transaction privacy public verifiability and com-plete provably correct auditing zkLedger supports a richset of auditing queries which are useful to measure thefinancial health of a market We developed a design usingnon-interactive zero-knowledge proofs to prove transac-tions maintain financial invariants and to support auditingOur evaluation shows that zkLedger has reasonable per-formance for transaction settlement and auditing

10 AcknowledgementsWe thank Alexander Chernyakhovsky Thaddeus DryjaDavid Lazar Ronald L Rivest CJ Williams and ourshepherd and reviewers for helpful comments The re-search leading to these results has received funding fromthe Center for Science of Information (CSoI) an NSFScience and Technology Center under grant agreementCCF-0939370 and the Ethics and Governance of Artifi-cial Intelligence Fund

76 15th USENIX Symposium on Networked Systems Design and Implementation USENIX Association

References[1] Bank secrecy act of 1970 October 1970 12 USC 103[2] Package btcec implements support for the elliptic curves

needed for Bitcoin July 2017 httpsgodocorggithubcombtcsuitebtcdbtcec

[3] ABBE E A KHANDANI A E AND LO A WPrivacy-preserving methods for sharing financial risk ex-posures The American Economic Review 102 3 (2012)65ndash70

[4] ARASU A BLANAS S EGURO K KAUSHIK RKOSSMANN D RAMAMURTHY R AND VENKATE-SAN R Orthogonal security with cipherbase In CIDR(2013)

[5] BAJAJ S AND SION R Trusteddb A trusted hardware-based database with privacy and data confidentiality IEEETransactions on Knowledge and Data Engineering 26 3(2014) 752ndash765

[6] BAUMANN A PEINADO M AND HUNT G Shieldingapplications from an untrusted cloud with haven ACMTransactions on Computer Systems (TOCS) 33 3 (2015)8

[7] BEN-SASSON E CHIESA A GENKIN D TROMERE AND VIRZA M SNARKs for C Verifying programexecutions succinctly and in zero knowledge In Advancesin CryptologyndashCRYPTO 2013 Springer 2013 pp 90ndash108

[8] BEN-SASSON E CHIESA A GREEN M TROMERE AND VIRZA M Secure sampling of public parametersfor succinct zero knowledge proofs In Proceedings of the2015 IEEE Symposium on Security and Privacy (2015)SP rsquo15 pp 287ndash304

[9] BLUM M FELDMAN P AND MICALI S Non-interactive zero-knowledge and its applications In Pro-ceedings of the 20th Annual ACM Symposium on Theoryof Computing (1988) STOC rsquo88 pp 103ndash112

[10] BOGDANOV D TALVISTE R AND WILLEMSON JDeploying secure multi-party computation for financialdata analysis In International Conference on FinancialCryptography and Data Security (2012) Springer pp 57ndash64

[11] BOWE S GABIZON A AND GREEN M A multi-party protocol for constructing the public parameters ofthe Pinocchio zk-SNARK Cryptology ePrint ArchiveReport 2017602 2017

[12] BOWE S GABIZON A AND MIERS I Scalable multi-party computation for zk-SNARK parameters in the ran-dom beacon model Cryptology ePrint Archive Report20171050 2017

[13] BUNZ B BOOTLE J BONEH D POELSTRA AAND MAXWELL G Bulletproofs Short proofs for Con-fidential Transactions and more In Security and Privacy(SP) 2018 IEEE Symposium on (2018) IEEE

[14] BURKHART M STRASSER M MANY D AND DIM-ITROPOULOS X Sepia Privacy-preserving aggregationof multi-domain network events and statistics Network 1101101 (2010)

[15] CASTRO M AND LISKOV B Practical byzantine faulttolerance In OSDI (1999) vol 99 pp 173ndash186

[16] CECCHETTI E ZHANG F JI Y KOSBA A JUELSA AND SHI E Solidus Confidential distributed ledgertransactions via pvorm

[17] CHAIN I Confidential assets httpsblogchaincomhidden-in-plain-sight-transacting-privately-on-a-blockchain-835ab75c01cb

[18] CORRIGAN-GIBBS H AND BONEH D Prio Privaterobust and scalable computation of aggregate statisticsarXiv preprint arXiv170306255 (2017)

[19] COUNCIL F R Developments in audit 20162017full report 2017 httpwwwfrcorgukgetattachment915c15a4-dbc7-4223-b8ae-cad53dbcca17Developments-in-Audit-2016-17-Full-reportpdf

[20] CRAMER R DAMGARD I AND SCHOENMAKERSB Proofs of partial knowledge and simplified design ofwitness hiding protocols In Advances in Cryptology -CRYPTO rsquo94 14th Annual International Cryptology Con-ference Santa Barbara California USA August 21-251994 Proceedings (1994) pp 174ndash187

[21] DAGHER G G BUNZ B BONNEAU J CLARK JAND BONEH D Provisions Privacy-preserving proofsof solvency for Bitcoin exchanges In Proceedings of the22nd ACM SIGSAC Conference on Computer and Com-munications Security (Denver CO 2015) ACM pp 720ndash731

[22] Corda 2017 httpsgithubcomcordacorda

[23] Digital asset holdings 2017 httpdigitalassetcom

[24] Regulation (EU) 2016679 of the European Parliamentand of the Council of 27 April 2016 on the protection ofnatural persons with regard to the processing of personaldata and on the free movement of such data and repealingDirective 9546EC (General Data Protection Regulation)Official Journal of the European Union L119 (May 2016)1ndash88

[25] FELDMAN A J ZELLER W P FREEDMAN M JAND FELTEN E W Sporc Group collaboration us-ing untrusted cloud resources In OSDI (2010) vol 10pp 337ndash350

[26] FIAT A AND SHAMIR A How to prove yourselfpractical solutions to identification and signature problemsIn Proceedings of the 6th Annual International CryptologyConference (1987) CRYPTO rsquo87 pp 186ndash194

[27] GARMAN C GREEN M AND MIERS I Accountableprivacy for decentralized anonymous payments Cryp-tology ePrint Archive Report 2016061 2016 httpeprintiacrorg2016061

[28] GREENBERG A Fbi says itrsquos seized $285 million inbitcoins from ross ulbricht alleged owner of silk roadForbes 25 (2013)

USENIX Association 15th USENIX Symposium on Networked Systems Design and Implementation 77

bull Proof of Consistency (πC) two zero-knowledgeproofs asserting the randomness used in cmi and Tokeniare the same and the randomness used in cmprimei andTokenprimei are the same This is to prevent a maliciousbank from adding data to the ledger that would stopanother bank from being able to open its commitmentsfor the AuditorTransactions may contain additional metadata in plain-

text or not For example banks might want to includeencrypted account numbers addresses or identifying in-formation on behalf of a customer to satisfy the TravelRule specified in the Bank Secrecy Act of 1970 [1] zk-Ledger supports auditing over metadata in the transactionas well but it does not have a way to publicly verifyadditional metadata

44 Adding or removing bankszkLedger can support dynamically adding or removingbanks if done so publicly The participants (or anotherauthority) append a signed transaction to the ledger indi-cating which banks and thus columns should be addedor removed For example to add a new bank to theledger shown in Figure 2 the involved banks would ap-pend a transaction to the ledger indicating an intent toadd Bankn+1 From that point forward all transactionsshould contain n+ 1 entries The Proof of Assets forBankn+1rsquos entry in each transaction will start at the rowwhere Bankn+1 was added Similarly if a bank is re-moved later transactions should not include entries forthat bank Since all participants can see which bankswere added or removed they can adjust their proofs andverifications accordingly

45 OptimizationszkLedger employs several optimizations to make produc-ing and verifying these proofs faster and to support fasterauditing First caching the product of the commitmentsin a bankrsquos column improves auditing and proof creationspeed Each bank stores a rolling product of commitmentsby row and by asset so that it can quickly produce proofsof assets and answer queries from auditors Using thesecaches a bank can quickly answer an auditorrsquos query ona subset of rows in the ledger

Most transactions in zkLedger do not include everybank Every bank can pre-generate many range proofsfor the value 0 We speedup transaction throughput byparallelizing range proof generation and validation

5 AuditingAuditing is a critical component of the financial systemand regulators use various techniques to measure systemicfinancial risk Through the use of sums means ratios

variance co-variance and standard deviation an auditorin zkLedger can determine the following among othermeasurementsbull Leverage ratios zkLedger can show how much of an

asset a bank has on its books compared to its otherholdings This is helpful to estimate counterparty risk

bull Concentration Regulators use a measure called theHerfindahl-Hirschman Index (HHI) to measure howcompetitive an industry is [29]

bull Real-time price indexes Auditors can get a sense ofthe price of assets that are traded over-the-counter andthus not tracked through exchangesNatively zkLedger supports sums which means linear

combinations of values stored in the ledger This comesfrom the additive structure of Pedersen commitmentsBut zkLedger also supports a more general query modelwhich can be considered in two parts A map step and areduce stepBasic auditing Consider the basic example where anauditor wants to determine how much of an asset a bankhas on its books As described in sect42 the auditor willfilter the rows by asset multiply the entries in the bankrsquoscolumn and then ask the bank to open the commitmentproduct This only requires one round of communica-tion between the auditor and the bank and the messagesare a constant size independent of the number of rowsBecause of zkLedgerrsquos commitment caches this is veryfastMapreduce An auditor can issue more complex queriesthat might require the exchange of more data or mightrequire the participants to look at most of the rows in theledger Letrsquos consider an auditor which wants to know themean transaction size for a given bank and asset An au-ditor cannot verify a bankrsquos answer by simply totaling thebankrsquos column of commitments and dividing the openedvalue by the number of rows because such a computationwould have an incorrect denominator Namely when thebank is not involved in a transaction its column in therow will be commitment to 0 and should be discountedIn order to determine the correct denominator the auditorand the bank run the following protocol1 Filter The bank will filter the rows by asset2 Produce new commitments For each row the bank

will commit to a single bit b 1 or 0 depending on ifthe bank was involved in the transaction or not and cre-ate a proof that the bank has done this recommitmentcorrectly Crucially the auditor cannot distinguishbetween these commitments and so the bankrsquos trans-actions are not revealed We call this act of producingnew commitments the map step The map step alsorequires producing proofs that the new values were

USENIX Association 15th USENIX Symposium on Networked Systems Design and Implementation 73

correctly computed in our example for each transac-tion the bank would produce a NIZK proof that b = 1if and only if the transaction value was not equal to 0

3 Compute number of non-zero transactions Thebank computes the homomorphic sum of the new com-mitments to bits~b and opens it to reveal how manytransactions were non-zero This is the reduce stepThis is the correct denominator to compute the meantransaction size The auditor cannot tell anything aboutthe values in~b beyond what is revealed by the sum

4 Respond to auditor The bank then sends the auditorthe sum of the values in its column the vector of bitcommitments and corresponding NIZK proofs thenumber of its non-zero transactions n and the sum ofthe r values in the commitments

5 Verification The auditor verifies the map step byverifying the commitments were done correctly andverifies the reduce step and the number of non-zerotransactions by confirming that the product of the vec-tor of bit commitments is gnhsum

Nk=1 rk

6 Compute answer The auditor computes the meanfrom the sum of the bankrsquos column and the number ofnon-zero transactionsAn auditor could ask a bank for outlier transactions

using a similar technique For each row the bank willcommit to a bit b where b = 1 if a transactionrsquos value forthat bank is outside a specified range As when computingthe mean the auditor can verify these commitments wereproduced correctly and obtain the sum The bank can thenopen only the transactions where b = 1 and the auditorknows exactly how many transactions should be opened

More complex auditing queries require multiple mapand reduce computations For example here is howan auditor can learn the variance of transaction valuesv1 vN

1 Compute the average transaction value Executethe protocol described above to compute the numberof non-zero transactions n and their average value v

2 Apply the squaring map For each entry vi in its rowthe bank produces a fresh commitment cmprimei to v2

i andsends these commitments to the auditor The bank alsosupplies NIZK proofs that the value hidden in eachcmprimei is exactly the square of the value vi committed toon the ledger

3 Apply the reduce step The auditor computes theproduct of the commitments cmprimei and the bank opensup this commitment as V = v2

1 + middot middot middot+ v2N by revealing

R = sumNi=1 ri The auditor confirms that the product of

the commitments is equal to gV hR

The auditor now computes the variance σ as followsσ2 = 1

n sumvi 6=0(viminus v)2 = 1nV minus v2

We note that whereas the square mapping used abovecorresponds to the second moment (variance) zkLedgercan also compute higher statistical moments (eg skew-ness and kurtosis) using similar techniques and usingcubing and fourth power mappings respectively See Ap-pendix A for a list of measurements zkLedger supports

zkLedger can support limited information release byusing more complex reduce mappings For example in-stead of releasing the sum of values the bank can producea commitment to the rounded sum of values (eg to thefirst two decimal places) and use range proofs also im-plemented in zkLedger to show that the rounding wasdone correctly Revealing just the order of magnitude ofthe quantity at hand lets the parties balance the granularityof information disclosure6 ImplementationTo evaluate zkLedgerrsquos design we implemented a pro-totype of zkLedger in Go Our prototype uses a modi-fied version of the btcec library [2] that contains the pa-rameters and methods to compute with the elliptic curvesecp256k1 We use Gorsquos built-in SHA-256 implementa-tion for our cryptographic hash function and determin-istically pick g and h by applying point decompressionto the ldquonothing-up-my-sleeverdquo strings SHA256(0) andSHA256(1) Our prototype consists of approximately3200 lines of code of which 40 implement crypto-graphic tools used by zkLedger (zero-knowledge proofsrange proofs etc)

The implementation of the curve in zkLedger uses GorsquosbigInt type which we make no effort to compress orserialize in an efficient way A more optimized imple-mentation could compress curve points Our range proofsimplement the protocol used in Confidential Assets [42]Our NIZKs are based on Generalized Schnorr Proofswhich are three move interactive protocols to make themnon-interactive we apply the Fiat-Shamir heuristic [26]where we instantiate the random oracle using the SHA-256 hash function Our prototype implementation doesnot implement the complex queries described in sect5 andthus we do not evaluate them in sect7

7 EvaluationOur evaluation answers the following questionsbull How expensive is it to store prove and verify the differ-

ent proofs in zkLedger (sect72)bull How does auditing scale with the size of the ledger

(sect73)bull How does zkLedger scale with the number of banks

(sect74)

74 15th USENIX Symposium on Networked Systems Design and Implementation USENIX Association

Component Create Verify Size

2k Commitment 05 ms 05 ms 64 B2k Consistency 07 ms 08 ms 224 Bk Disjunctive 09 ms 09 ms 288 Bk Range 47 ms 35 ms 3936 B

Table 1 Number of each proof component in a transaction for k banksSize of and time to create and verify the components with 12 cores Therange proof create and verify benefit from the additional cores

71 Experimental setup

Microbenchmarks We run microbenchmarks on a 12core Intel machine with i7-X980 333 GHz CPUs and24GB of RAM running 64-bit Linux 440 on Ubuntu16043 Each microbenchmark runs the same code aBank runs to create and validate transactions

Distributed experiment We run the distributed experi-ments on a set of 12 virtual machines each with 4 cores ofIntel Xeon E5-2640 25 GHz processors 24GB of RAMand the same software setup as above There is one au-ditor one server providing the service of the ledger anda varying number of banks one per server Servers com-municate using the netrpc Go package over TCP Allexperiments use Go version 19

72 Proof overhead in zkLedgerTable 1 shows the time to prove and verify the proofs in atransaction in zkLedger There are two commitments twoconsistency proofs and one each of the disjunctive andrange proofs in a transaction entry There is a transactionentry per Bank Table 1 also shows the sizes of the variousproofs in bytes These sizes are estimated based on thesize of the underlying fields in the struct in memorythese proofs could be further compressed Range proofsdominate the size of the transactions

The left graph in Figure 3 shows the time it takes tocreate and verify a transaction varying the number ofoverall banks which increases the number of entries pertransaction This indicates that as we increase the numberof banks both transaction creation and verification timesper bank increase linearly but parallelization helps Prov-ing and validating range proofs dominates transactioncreation and verification but this cost is also highly paral-lelizable 12 cores gives a 28times speedup when creating atransaction with 20 banks a bank can create or validate atransaction for up to 20 banks in less than 200ms

As described in sect41 zkLedger uses Borromean ringsignatures to prove that a value is in a certain range andsupports values up to 240 Reducing the supported rangeof values would reduce range proof cost since that cost islinear in the number of bits in the size of the range Thereare also newer proof systems such as Bulletproofs which

might create much smaller range proofs [13] We plan toevaluate zkLedger with Bulletproofs in future work

73 Cost of auditing ledgersThe left graph in Figure 4 shows that for certain func-tions the time to audit is independent of the number oftransactions in the ledger This is because the Auditorand Banks maintain commitment caches which alreadyhave the commitment product necessary to prove to theauditor the sum of the values in its column The auditfunction is measuring the Herfindhal-Hirschman Indexso the auditor communicates with each bank

When the auditor cannot use a commitment cache per-haps because it was offline it must process the wholeledger to compute the commitment product This alsoapplies to more complex auditing like the types describedin sect5 when the auditor has to verify recommitments forevery row in the ledger These costs are shown in themiddle graph in Figure 4 This graph shows how long ittakes the auditor to compute the Herfindahl-HirschmanIndex on a ledger of varying sizes without using the com-mitment caches so the auditor must process every row ofthe ledger In these measurements the auditor does notverify each row As expected this time increases linearlywith the number of rows This indicates that maintainingcommitment caches is important for real-time auditingHowever even without commitment caches auditing timeis reasonable 35 seconds for 100K transactions Thissuggests the complex auditing queries in which the au-ditor computes a similar set of operations per row willalso be on the order of many seconds zkLedger currentlyonly maintains commitment product caches per asset perbank but could maintain more

For a fixed size ledger this audit function costs orderthe number of banks The right graph in Figure 4 demon-strates the auditing costs of computing the Herfindahl-Hirschman Index on a ledger of 2000 transactions as wevary the number of banks both with and without com-mitment caches The auditor audits the banks in parallelAuditing cost for this function grows slightly with thenumber of banks since more banks increase the variabil-ity in parallel auditing and the auditor must wait for thelast bank to respond before computing the final answer

In these figures each point is the mean of running theauditing query 20 times with error bars representing onestandard deviation from the mean

74 Scaling with more banksThere are two significant costs that grow with the numberof banks in zkLedger a serial step to create transactionsthat increases linearly and verifying transactions whichincreases quadratically with the number of banks As

USENIX Association 15th USENIX Symposium on Networked Systems Design and Implementation 75

0

100

200

300

400

500

600

2 4 6 8 10 12 14 16 18 20

Tim

e (

ms)

number of banks

verify-1create-1verify-12

create-12

0

200

400

600

800

1000

2 3 4 5 6 7 8 9 10

Tim

e (

ms)

number of banks

complete transactions

0

2

4

6

8

10

12

2 3 4 5 6 7 8 9 10

Th

rou

gh

pu

t (t

xn

ss

ec)

number of banks

all banks transactingone bank transacting

Figure 3 Transaction creation and verification time for one bank (left) varying the number of entries in the transaction Single-threaded andmulti-threaded performance with 12 threads Time to fully process a transaction including creation broadcast to ledger banks and auditor andverification by all parties (middle) Throughput (right) varying the number of banks

0

2

4

6

8

10

12

0K 20K 40K 60K 80K 100K

Au

ditin

g t

ime

(m

s)

Transactions in ledger

online auditor

0

500

1000

1500

2000

2500

3000

3500

0K 20K 40K 60K 80K 100K

Transactions in ledger

offline auditor

0

20

40

60

80

100

120

2 3 4 5 6 7 8 9 10

Number of banks

offline auditor

online auditor

Figure 4 Time to audit ledgers of different sizes (4 banks) and with a varying number of banks (2000 row ledger) Audit time is independent of thesize of the ledger (left) thanks to commitment caches maintained by the online auditor When commitment cache optimization is turned off (middle)the audit time is linear in the size of the ledger Audit time grows with the number of banks (right) and is much higher without commitment caches

described in sect41 a bank needs to use its entry fromtransaction nminus1 to create transaction n So though a bankcan use many cores to produce the proofs for a singletransaction in parallel multiple banks cannot producedifferent transactions in parallel In zkLedger banks startcreating transaction n before seeing nminus 1 but the bankcannot complete the transaction until nminus1 is accepted tothe ledger and verified causing an inherent bottleneck

The second major cost is around verification Everybank must verify every transaction so the more banksthe larger each transaction and thus the more work thatneeds to be done by each bank The middle graph inFigure 3 measures the time it takes one bank to createand all participants in zkLedger to completely processa transaction One bank creates a transaction and sendsit to the ledger which then broadcasts the transaction toall banks and an online auditor The auditor and everybank verify the transaction As we increase the numberof banks work increases quadratically however bankscan verify transactions in parallel so the time to processtransactions only increases linearly The right graph inFigure 3 shows that as we surmised zkLedgerrsquos through-put worsens with more banks The one bank transactingline in this graph is the same data as the middle graph

Since range proofs dominate the costs of transactioncreation and verification we are optimistic that a fasterrange proof implementation will directly improve perfor-mance zkLedgerrsquos current performance is comparableto Solidus a privacy-preserving distributed ledger whichachieves 3-4 transactions per second with online valida-tion but unlike zkLedger does not support auditing

8 Future workzkLedger focuses on providing provably correct auditingover private transaction data but zkLedger does not havea way to recover if the distributed ledger is corrupted Inthis case the parties maintaining the ledger would haveto come together to recreate historical transactions zk-Ledger also does not provide recourse if a bank commitsan unintended transaction to the ledger A future ver-sion of zkLedger might provide rectifying transactions orparticipant agreed-upon rollback

9 ConclusionzkLedger is the first distributed ledger system to providestrong transaction privacy public verifiability and com-plete provably correct auditing zkLedger supports a richset of auditing queries which are useful to measure thefinancial health of a market We developed a design usingnon-interactive zero-knowledge proofs to prove transac-tions maintain financial invariants and to support auditingOur evaluation shows that zkLedger has reasonable per-formance for transaction settlement and auditing

10 AcknowledgementsWe thank Alexander Chernyakhovsky Thaddeus DryjaDavid Lazar Ronald L Rivest CJ Williams and ourshepherd and reviewers for helpful comments The re-search leading to these results has received funding fromthe Center for Science of Information (CSoI) an NSFScience and Technology Center under grant agreementCCF-0939370 and the Ethics and Governance of Artifi-cial Intelligence Fund

76 15th USENIX Symposium on Networked Systems Design and Implementation USENIX Association

References[1] Bank secrecy act of 1970 October 1970 12 USC 103[2] Package btcec implements support for the elliptic curves

needed for Bitcoin July 2017 httpsgodocorggithubcombtcsuitebtcdbtcec

[3] ABBE E A KHANDANI A E AND LO A WPrivacy-preserving methods for sharing financial risk ex-posures The American Economic Review 102 3 (2012)65ndash70

[4] ARASU A BLANAS S EGURO K KAUSHIK RKOSSMANN D RAMAMURTHY R AND VENKATE-SAN R Orthogonal security with cipherbase In CIDR(2013)

[5] BAJAJ S AND SION R Trusteddb A trusted hardware-based database with privacy and data confidentiality IEEETransactions on Knowledge and Data Engineering 26 3(2014) 752ndash765

[6] BAUMANN A PEINADO M AND HUNT G Shieldingapplications from an untrusted cloud with haven ACMTransactions on Computer Systems (TOCS) 33 3 (2015)8

[7] BEN-SASSON E CHIESA A GENKIN D TROMERE AND VIRZA M SNARKs for C Verifying programexecutions succinctly and in zero knowledge In Advancesin CryptologyndashCRYPTO 2013 Springer 2013 pp 90ndash108

[8] BEN-SASSON E CHIESA A GREEN M TROMERE AND VIRZA M Secure sampling of public parametersfor succinct zero knowledge proofs In Proceedings of the2015 IEEE Symposium on Security and Privacy (2015)SP rsquo15 pp 287ndash304

[9] BLUM M FELDMAN P AND MICALI S Non-interactive zero-knowledge and its applications In Pro-ceedings of the 20th Annual ACM Symposium on Theoryof Computing (1988) STOC rsquo88 pp 103ndash112

[10] BOGDANOV D TALVISTE R AND WILLEMSON JDeploying secure multi-party computation for financialdata analysis In International Conference on FinancialCryptography and Data Security (2012) Springer pp 57ndash64

[11] BOWE S GABIZON A AND GREEN M A multi-party protocol for constructing the public parameters ofthe Pinocchio zk-SNARK Cryptology ePrint ArchiveReport 2017602 2017

[12] BOWE S GABIZON A AND MIERS I Scalable multi-party computation for zk-SNARK parameters in the ran-dom beacon model Cryptology ePrint Archive Report20171050 2017

[13] BUNZ B BOOTLE J BONEH D POELSTRA AAND MAXWELL G Bulletproofs Short proofs for Con-fidential Transactions and more In Security and Privacy(SP) 2018 IEEE Symposium on (2018) IEEE

[14] BURKHART M STRASSER M MANY D AND DIM-ITROPOULOS X Sepia Privacy-preserving aggregationof multi-domain network events and statistics Network 1101101 (2010)

[15] CASTRO M AND LISKOV B Practical byzantine faulttolerance In OSDI (1999) vol 99 pp 173ndash186

[16] CECCHETTI E ZHANG F JI Y KOSBA A JUELSA AND SHI E Solidus Confidential distributed ledgertransactions via pvorm

[17] CHAIN I Confidential assets httpsblogchaincomhidden-in-plain-sight-transacting-privately-on-a-blockchain-835ab75c01cb

[18] CORRIGAN-GIBBS H AND BONEH D Prio Privaterobust and scalable computation of aggregate statisticsarXiv preprint arXiv170306255 (2017)

[19] COUNCIL F R Developments in audit 20162017full report 2017 httpwwwfrcorgukgetattachment915c15a4-dbc7-4223-b8ae-cad53dbcca17Developments-in-Audit-2016-17-Full-reportpdf

[20] CRAMER R DAMGARD I AND SCHOENMAKERSB Proofs of partial knowledge and simplified design ofwitness hiding protocols In Advances in Cryptology -CRYPTO rsquo94 14th Annual International Cryptology Con-ference Santa Barbara California USA August 21-251994 Proceedings (1994) pp 174ndash187

[21] DAGHER G G BUNZ B BONNEAU J CLARK JAND BONEH D Provisions Privacy-preserving proofsof solvency for Bitcoin exchanges In Proceedings of the22nd ACM SIGSAC Conference on Computer and Com-munications Security (Denver CO 2015) ACM pp 720ndash731

[22] Corda 2017 httpsgithubcomcordacorda

[23] Digital asset holdings 2017 httpdigitalassetcom

[24] Regulation (EU) 2016679 of the European Parliamentand of the Council of 27 April 2016 on the protection ofnatural persons with regard to the processing of personaldata and on the free movement of such data and repealingDirective 9546EC (General Data Protection Regulation)Official Journal of the European Union L119 (May 2016)1ndash88

[25] FELDMAN A J ZELLER W P FREEDMAN M JAND FELTEN E W Sporc Group collaboration us-ing untrusted cloud resources In OSDI (2010) vol 10pp 337ndash350

[26] FIAT A AND SHAMIR A How to prove yourselfpractical solutions to identification and signature problemsIn Proceedings of the 6th Annual International CryptologyConference (1987) CRYPTO rsquo87 pp 186ndash194

[27] GARMAN C GREEN M AND MIERS I Accountableprivacy for decentralized anonymous payments Cryp-tology ePrint Archive Report 2016061 2016 httpeprintiacrorg2016061

[28] GREENBERG A Fbi says itrsquos seized $285 million inbitcoins from ross ulbricht alleged owner of silk roadForbes 25 (2013)

USENIX Association 15th USENIX Symposium on Networked Systems Design and Implementation 77

correctly computed in our example for each transac-tion the bank would produce a NIZK proof that b = 1if and only if the transaction value was not equal to 0

3 Compute number of non-zero transactions Thebank computes the homomorphic sum of the new com-mitments to bits~b and opens it to reveal how manytransactions were non-zero This is the reduce stepThis is the correct denominator to compute the meantransaction size The auditor cannot tell anything aboutthe values in~b beyond what is revealed by the sum

4 Respond to auditor The bank then sends the auditorthe sum of the values in its column the vector of bitcommitments and corresponding NIZK proofs thenumber of its non-zero transactions n and the sum ofthe r values in the commitments

5 Verification The auditor verifies the map step byverifying the commitments were done correctly andverifies the reduce step and the number of non-zerotransactions by confirming that the product of the vec-tor of bit commitments is gnhsum

Nk=1 rk

6 Compute answer The auditor computes the meanfrom the sum of the bankrsquos column and the number ofnon-zero transactionsAn auditor could ask a bank for outlier transactions

using a similar technique For each row the bank willcommit to a bit b where b = 1 if a transactionrsquos value forthat bank is outside a specified range As when computingthe mean the auditor can verify these commitments wereproduced correctly and obtain the sum The bank can thenopen only the transactions where b = 1 and the auditorknows exactly how many transactions should be opened

More complex auditing queries require multiple mapand reduce computations For example here is howan auditor can learn the variance of transaction valuesv1 vN

1 Compute the average transaction value Executethe protocol described above to compute the numberof non-zero transactions n and their average value v

2 Apply the squaring map For each entry vi in its rowthe bank produces a fresh commitment cmprimei to v2

i andsends these commitments to the auditor The bank alsosupplies NIZK proofs that the value hidden in eachcmprimei is exactly the square of the value vi committed toon the ledger

3 Apply the reduce step The auditor computes theproduct of the commitments cmprimei and the bank opensup this commitment as V = v2

1 + middot middot middot+ v2N by revealing

R = sumNi=1 ri The auditor confirms that the product of

the commitments is equal to gV hR

The auditor now computes the variance σ as followsσ2 = 1

n sumvi 6=0(viminus v)2 = 1nV minus v2

We note that whereas the square mapping used abovecorresponds to the second moment (variance) zkLedgercan also compute higher statistical moments (eg skew-ness and kurtosis) using similar techniques and usingcubing and fourth power mappings respectively See Ap-pendix A for a list of measurements zkLedger supports

zkLedger can support limited information release byusing more complex reduce mappings For example in-stead of releasing the sum of values the bank can producea commitment to the rounded sum of values (eg to thefirst two decimal places) and use range proofs also im-plemented in zkLedger to show that the rounding wasdone correctly Revealing just the order of magnitude ofthe quantity at hand lets the parties balance the granularityof information disclosure6 ImplementationTo evaluate zkLedgerrsquos design we implemented a pro-totype of zkLedger in Go Our prototype uses a modi-fied version of the btcec library [2] that contains the pa-rameters and methods to compute with the elliptic curvesecp256k1 We use Gorsquos built-in SHA-256 implementa-tion for our cryptographic hash function and determin-istically pick g and h by applying point decompressionto the ldquonothing-up-my-sleeverdquo strings SHA256(0) andSHA256(1) Our prototype consists of approximately3200 lines of code of which 40 implement crypto-graphic tools used by zkLedger (zero-knowledge proofsrange proofs etc)

The implementation of the curve in zkLedger uses GorsquosbigInt type which we make no effort to compress orserialize in an efficient way A more optimized imple-mentation could compress curve points Our range proofsimplement the protocol used in Confidential Assets [42]Our NIZKs are based on Generalized Schnorr Proofswhich are three move interactive protocols to make themnon-interactive we apply the Fiat-Shamir heuristic [26]where we instantiate the random oracle using the SHA-256 hash function Our prototype implementation doesnot implement the complex queries described in sect5 andthus we do not evaluate them in sect7

7 EvaluationOur evaluation answers the following questionsbull How expensive is it to store prove and verify the differ-

ent proofs in zkLedger (sect72)bull How does auditing scale with the size of the ledger

(sect73)bull How does zkLedger scale with the number of banks

(sect74)

74 15th USENIX Symposium on Networked Systems Design and Implementation USENIX Association

Component Create Verify Size

2k Commitment 05 ms 05 ms 64 B2k Consistency 07 ms 08 ms 224 Bk Disjunctive 09 ms 09 ms 288 Bk Range 47 ms 35 ms 3936 B

Table 1 Number of each proof component in a transaction for k banksSize of and time to create and verify the components with 12 cores Therange proof create and verify benefit from the additional cores

71 Experimental setup

Microbenchmarks We run microbenchmarks on a 12core Intel machine with i7-X980 333 GHz CPUs and24GB of RAM running 64-bit Linux 440 on Ubuntu16043 Each microbenchmark runs the same code aBank runs to create and validate transactions

Distributed experiment We run the distributed experi-ments on a set of 12 virtual machines each with 4 cores ofIntel Xeon E5-2640 25 GHz processors 24GB of RAMand the same software setup as above There is one au-ditor one server providing the service of the ledger anda varying number of banks one per server Servers com-municate using the netrpc Go package over TCP Allexperiments use Go version 19

72 Proof overhead in zkLedgerTable 1 shows the time to prove and verify the proofs in atransaction in zkLedger There are two commitments twoconsistency proofs and one each of the disjunctive andrange proofs in a transaction entry There is a transactionentry per Bank Table 1 also shows the sizes of the variousproofs in bytes These sizes are estimated based on thesize of the underlying fields in the struct in memorythese proofs could be further compressed Range proofsdominate the size of the transactions

The left graph in Figure 3 shows the time it takes tocreate and verify a transaction varying the number ofoverall banks which increases the number of entries pertransaction This indicates that as we increase the numberof banks both transaction creation and verification timesper bank increase linearly but parallelization helps Prov-ing and validating range proofs dominates transactioncreation and verification but this cost is also highly paral-lelizable 12 cores gives a 28times speedup when creating atransaction with 20 banks a bank can create or validate atransaction for up to 20 banks in less than 200ms

As described in sect41 zkLedger uses Borromean ringsignatures to prove that a value is in a certain range andsupports values up to 240 Reducing the supported rangeof values would reduce range proof cost since that cost islinear in the number of bits in the size of the range Thereare also newer proof systems such as Bulletproofs which

might create much smaller range proofs [13] We plan toevaluate zkLedger with Bulletproofs in future work

73 Cost of auditing ledgersThe left graph in Figure 4 shows that for certain func-tions the time to audit is independent of the number oftransactions in the ledger This is because the Auditorand Banks maintain commitment caches which alreadyhave the commitment product necessary to prove to theauditor the sum of the values in its column The auditfunction is measuring the Herfindhal-Hirschman Indexso the auditor communicates with each bank

When the auditor cannot use a commitment cache per-haps because it was offline it must process the wholeledger to compute the commitment product This alsoapplies to more complex auditing like the types describedin sect5 when the auditor has to verify recommitments forevery row in the ledger These costs are shown in themiddle graph in Figure 4 This graph shows how long ittakes the auditor to compute the Herfindahl-HirschmanIndex on a ledger of varying sizes without using the com-mitment caches so the auditor must process every row ofthe ledger In these measurements the auditor does notverify each row As expected this time increases linearlywith the number of rows This indicates that maintainingcommitment caches is important for real-time auditingHowever even without commitment caches auditing timeis reasonable 35 seconds for 100K transactions Thissuggests the complex auditing queries in which the au-ditor computes a similar set of operations per row willalso be on the order of many seconds zkLedger currentlyonly maintains commitment product caches per asset perbank but could maintain more

For a fixed size ledger this audit function costs orderthe number of banks The right graph in Figure 4 demon-strates the auditing costs of computing the Herfindahl-Hirschman Index on a ledger of 2000 transactions as wevary the number of banks both with and without com-mitment caches The auditor audits the banks in parallelAuditing cost for this function grows slightly with thenumber of banks since more banks increase the variabil-ity in parallel auditing and the auditor must wait for thelast bank to respond before computing the final answer

In these figures each point is the mean of running theauditing query 20 times with error bars representing onestandard deviation from the mean

74 Scaling with more banksThere are two significant costs that grow with the numberof banks in zkLedger a serial step to create transactionsthat increases linearly and verifying transactions whichincreases quadratically with the number of banks As

USENIX Association 15th USENIX Symposium on Networked Systems Design and Implementation 75

0

100

200

300

400

500

600

2 4 6 8 10 12 14 16 18 20

Tim

e (

ms)

number of banks

verify-1create-1verify-12

create-12

0

200

400

600

800

1000

2 3 4 5 6 7 8 9 10

Tim

e (

ms)

number of banks

complete transactions

0

2

4

6

8

10

12

2 3 4 5 6 7 8 9 10

Th

rou

gh

pu

t (t

xn

ss

ec)

number of banks

all banks transactingone bank transacting

Figure 3 Transaction creation and verification time for one bank (left) varying the number of entries in the transaction Single-threaded andmulti-threaded performance with 12 threads Time to fully process a transaction including creation broadcast to ledger banks and auditor andverification by all parties (middle) Throughput (right) varying the number of banks

0

2

4

6

8

10

12

0K 20K 40K 60K 80K 100K

Au

ditin

g t

ime

(m

s)

Transactions in ledger

online auditor

0

500

1000

1500

2000

2500

3000

3500

0K 20K 40K 60K 80K 100K

Transactions in ledger

offline auditor

0

20

40

60

80

100

120

2 3 4 5 6 7 8 9 10

Number of banks

offline auditor

online auditor

Figure 4 Time to audit ledgers of different sizes (4 banks) and with a varying number of banks (2000 row ledger) Audit time is independent of thesize of the ledger (left) thanks to commitment caches maintained by the online auditor When commitment cache optimization is turned off (middle)the audit time is linear in the size of the ledger Audit time grows with the number of banks (right) and is much higher without commitment caches

described in sect41 a bank needs to use its entry fromtransaction nminus1 to create transaction n So though a bankcan use many cores to produce the proofs for a singletransaction in parallel multiple banks cannot producedifferent transactions in parallel In zkLedger banks startcreating transaction n before seeing nminus 1 but the bankcannot complete the transaction until nminus1 is accepted tothe ledger and verified causing an inherent bottleneck

The second major cost is around verification Everybank must verify every transaction so the more banksthe larger each transaction and thus the more work thatneeds to be done by each bank The middle graph inFigure 3 measures the time it takes one bank to createand all participants in zkLedger to completely processa transaction One bank creates a transaction and sendsit to the ledger which then broadcasts the transaction toall banks and an online auditor The auditor and everybank verify the transaction As we increase the numberof banks work increases quadratically however bankscan verify transactions in parallel so the time to processtransactions only increases linearly The right graph inFigure 3 shows that as we surmised zkLedgerrsquos through-put worsens with more banks The one bank transactingline in this graph is the same data as the middle graph

Since range proofs dominate the costs of transactioncreation and verification we are optimistic that a fasterrange proof implementation will directly improve perfor-mance zkLedgerrsquos current performance is comparableto Solidus a privacy-preserving distributed ledger whichachieves 3-4 transactions per second with online valida-tion but unlike zkLedger does not support auditing

8 Future workzkLedger focuses on providing provably correct auditingover private transaction data but zkLedger does not havea way to recover if the distributed ledger is corrupted Inthis case the parties maintaining the ledger would haveto come together to recreate historical transactions zk-Ledger also does not provide recourse if a bank commitsan unintended transaction to the ledger A future ver-sion of zkLedger might provide rectifying transactions orparticipant agreed-upon rollback

9 ConclusionzkLedger is the first distributed ledger system to providestrong transaction privacy public verifiability and com-plete provably correct auditing zkLedger supports a richset of auditing queries which are useful to measure thefinancial health of a market We developed a design usingnon-interactive zero-knowledge proofs to prove transac-tions maintain financial invariants and to support auditingOur evaluation shows that zkLedger has reasonable per-formance for transaction settlement and auditing

10 AcknowledgementsWe thank Alexander Chernyakhovsky Thaddeus DryjaDavid Lazar Ronald L Rivest CJ Williams and ourshepherd and reviewers for helpful comments The re-search leading to these results has received funding fromthe Center for Science of Information (CSoI) an NSFScience and Technology Center under grant agreementCCF-0939370 and the Ethics and Governance of Artifi-cial Intelligence Fund

76 15th USENIX Symposium on Networked Systems Design and Implementation USENIX Association

References[1] Bank secrecy act of 1970 October 1970 12 USC 103[2] Package btcec implements support for the elliptic curves

needed for Bitcoin July 2017 httpsgodocorggithubcombtcsuitebtcdbtcec

[3] ABBE E A KHANDANI A E AND LO A WPrivacy-preserving methods for sharing financial risk ex-posures The American Economic Review 102 3 (2012)65ndash70

[4] ARASU A BLANAS S EGURO K KAUSHIK RKOSSMANN D RAMAMURTHY R AND VENKATE-SAN R Orthogonal security with cipherbase In CIDR(2013)

[5] BAJAJ S AND SION R Trusteddb A trusted hardware-based database with privacy and data confidentiality IEEETransactions on Knowledge and Data Engineering 26 3(2014) 752ndash765

[6] BAUMANN A PEINADO M AND HUNT G Shieldingapplications from an untrusted cloud with haven ACMTransactions on Computer Systems (TOCS) 33 3 (2015)8

[7] BEN-SASSON E CHIESA A GENKIN D TROMERE AND VIRZA M SNARKs for C Verifying programexecutions succinctly and in zero knowledge In Advancesin CryptologyndashCRYPTO 2013 Springer 2013 pp 90ndash108

[8] BEN-SASSON E CHIESA A GREEN M TROMERE AND VIRZA M Secure sampling of public parametersfor succinct zero knowledge proofs In Proceedings of the2015 IEEE Symposium on Security and Privacy (2015)SP rsquo15 pp 287ndash304

[9] BLUM M FELDMAN P AND MICALI S Non-interactive zero-knowledge and its applications In Pro-ceedings of the 20th Annual ACM Symposium on Theoryof Computing (1988) STOC rsquo88 pp 103ndash112

[10] BOGDANOV D TALVISTE R AND WILLEMSON JDeploying secure multi-party computation for financialdata analysis In International Conference on FinancialCryptography and Data Security (2012) Springer pp 57ndash64

[11] BOWE S GABIZON A AND GREEN M A multi-party protocol for constructing the public parameters ofthe Pinocchio zk-SNARK Cryptology ePrint ArchiveReport 2017602 2017

[12] BOWE S GABIZON A AND MIERS I Scalable multi-party computation for zk-SNARK parameters in the ran-dom beacon model Cryptology ePrint Archive Report20171050 2017

[13] BUNZ B BOOTLE J BONEH D POELSTRA AAND MAXWELL G Bulletproofs Short proofs for Con-fidential Transactions and more In Security and Privacy(SP) 2018 IEEE Symposium on (2018) IEEE

[14] BURKHART M STRASSER M MANY D AND DIM-ITROPOULOS X Sepia Privacy-preserving aggregationof multi-domain network events and statistics Network 1101101 (2010)

[15] CASTRO M AND LISKOV B Practical byzantine faulttolerance In OSDI (1999) vol 99 pp 173ndash186

[16] CECCHETTI E ZHANG F JI Y KOSBA A JUELSA AND SHI E Solidus Confidential distributed ledgertransactions via pvorm

[17] CHAIN I Confidential assets httpsblogchaincomhidden-in-plain-sight-transacting-privately-on-a-blockchain-835ab75c01cb

[18] CORRIGAN-GIBBS H AND BONEH D Prio Privaterobust and scalable computation of aggregate statisticsarXiv preprint arXiv170306255 (2017)

[19] COUNCIL F R Developments in audit 20162017full report 2017 httpwwwfrcorgukgetattachment915c15a4-dbc7-4223-b8ae-cad53dbcca17Developments-in-Audit-2016-17-Full-reportpdf

[20] CRAMER R DAMGARD I AND SCHOENMAKERSB Proofs of partial knowledge and simplified design ofwitness hiding protocols In Advances in Cryptology -CRYPTO rsquo94 14th Annual International Cryptology Con-ference Santa Barbara California USA August 21-251994 Proceedings (1994) pp 174ndash187

[21] DAGHER G G BUNZ B BONNEAU J CLARK JAND BONEH D Provisions Privacy-preserving proofsof solvency for Bitcoin exchanges In Proceedings of the22nd ACM SIGSAC Conference on Computer and Com-munications Security (Denver CO 2015) ACM pp 720ndash731

[22] Corda 2017 httpsgithubcomcordacorda

[23] Digital asset holdings 2017 httpdigitalassetcom

[24] Regulation (EU) 2016679 of the European Parliamentand of the Council of 27 April 2016 on the protection ofnatural persons with regard to the processing of personaldata and on the free movement of such data and repealingDirective 9546EC (General Data Protection Regulation)Official Journal of the European Union L119 (May 2016)1ndash88

[25] FELDMAN A J ZELLER W P FREEDMAN M JAND FELTEN E W Sporc Group collaboration us-ing untrusted cloud resources In OSDI (2010) vol 10pp 337ndash350

[26] FIAT A AND SHAMIR A How to prove yourselfpractical solutions to identification and signature problemsIn Proceedings of the 6th Annual International CryptologyConference (1987) CRYPTO rsquo87 pp 186ndash194

[27] GARMAN C GREEN M AND MIERS I Accountableprivacy for decentralized anonymous payments Cryp-tology ePrint Archive Report 2016061 2016 httpeprintiacrorg2016061

[28] GREENBERG A Fbi says itrsquos seized $285 million inbitcoins from ross ulbricht alleged owner of silk roadForbes 25 (2013)

USENIX Association 15th USENIX Symposium on Networked Systems Design and Implementation 77

Component Create Verify Size

2k Commitment 05 ms 05 ms 64 B2k Consistency 07 ms 08 ms 224 Bk Disjunctive 09 ms 09 ms 288 Bk Range 47 ms 35 ms 3936 B

Table 1 Number of each proof component in a transaction for k banksSize of and time to create and verify the components with 12 cores Therange proof create and verify benefit from the additional cores

71 Experimental setup

Microbenchmarks We run microbenchmarks on a 12core Intel machine with i7-X980 333 GHz CPUs and24GB of RAM running 64-bit Linux 440 on Ubuntu16043 Each microbenchmark runs the same code aBank runs to create and validate transactions

Distributed experiment We run the distributed experi-ments on a set of 12 virtual machines each with 4 cores ofIntel Xeon E5-2640 25 GHz processors 24GB of RAMand the same software setup as above There is one au-ditor one server providing the service of the ledger anda varying number of banks one per server Servers com-municate using the netrpc Go package over TCP Allexperiments use Go version 19

72 Proof overhead in zkLedgerTable 1 shows the time to prove and verify the proofs in atransaction in zkLedger There are two commitments twoconsistency proofs and one each of the disjunctive andrange proofs in a transaction entry There is a transactionentry per Bank Table 1 also shows the sizes of the variousproofs in bytes These sizes are estimated based on thesize of the underlying fields in the struct in memorythese proofs could be further compressed Range proofsdominate the size of the transactions

The left graph in Figure 3 shows the time it takes tocreate and verify a transaction varying the number ofoverall banks which increases the number of entries pertransaction This indicates that as we increase the numberof banks both transaction creation and verification timesper bank increase linearly but parallelization helps Prov-ing and validating range proofs dominates transactioncreation and verification but this cost is also highly paral-lelizable 12 cores gives a 28times speedup when creating atransaction with 20 banks a bank can create or validate atransaction for up to 20 banks in less than 200ms

As described in sect41 zkLedger uses Borromean ringsignatures to prove that a value is in a certain range andsupports values up to 240 Reducing the supported rangeof values would reduce range proof cost since that cost islinear in the number of bits in the size of the range Thereare also newer proof systems such as Bulletproofs which

might create much smaller range proofs [13] We plan toevaluate zkLedger with Bulletproofs in future work

73 Cost of auditing ledgersThe left graph in Figure 4 shows that for certain func-tions the time to audit is independent of the number oftransactions in the ledger This is because the Auditorand Banks maintain commitment caches which alreadyhave the commitment product necessary to prove to theauditor the sum of the values in its column The auditfunction is measuring the Herfindhal-Hirschman Indexso the auditor communicates with each bank

When the auditor cannot use a commitment cache per-haps because it was offline it must process the wholeledger to compute the commitment product This alsoapplies to more complex auditing like the types describedin sect5 when the auditor has to verify recommitments forevery row in the ledger These costs are shown in themiddle graph in Figure 4 This graph shows how long ittakes the auditor to compute the Herfindahl-HirschmanIndex on a ledger of varying sizes without using the com-mitment caches so the auditor must process every row ofthe ledger In these measurements the auditor does notverify each row As expected this time increases linearlywith the number of rows This indicates that maintainingcommitment caches is important for real-time auditingHowever even without commitment caches auditing timeis reasonable 35 seconds for 100K transactions Thissuggests the complex auditing queries in which the au-ditor computes a similar set of operations per row willalso be on the order of many seconds zkLedger currentlyonly maintains commitment product caches per asset perbank but could maintain more

For a fixed size ledger this audit function costs orderthe number of banks The right graph in Figure 4 demon-strates the auditing costs of computing the Herfindahl-Hirschman Index on a ledger of 2000 transactions as wevary the number of banks both with and without com-mitment caches The auditor audits the banks in parallelAuditing cost for this function grows slightly with thenumber of banks since more banks increase the variabil-ity in parallel auditing and the auditor must wait for thelast bank to respond before computing the final answer

In these figures each point is the mean of running theauditing query 20 times with error bars representing onestandard deviation from the mean

74 Scaling with more banksThere are two significant costs that grow with the numberof banks in zkLedger a serial step to create transactionsthat increases linearly and verifying transactions whichincreases quadratically with the number of banks As

USENIX Association 15th USENIX Symposium on Networked Systems Design and Implementation 75

0

100

200

300

400

500

600

2 4 6 8 10 12 14 16 18 20

Tim

e (

ms)

number of banks

verify-1create-1verify-12

create-12

0

200

400

600

800

1000

2 3 4 5 6 7 8 9 10

Tim

e (

ms)

number of banks

complete transactions

0

2

4

6

8

10

12

2 3 4 5 6 7 8 9 10

Th

rou

gh

pu

t (t

xn

ss

ec)

number of banks

all banks transactingone bank transacting

Figure 3 Transaction creation and verification time for one bank (left) varying the number of entries in the transaction Single-threaded andmulti-threaded performance with 12 threads Time to fully process a transaction including creation broadcast to ledger banks and auditor andverification by all parties (middle) Throughput (right) varying the number of banks

0

2

4

6

8

10

12

0K 20K 40K 60K 80K 100K

Au

ditin

g t

ime

(m

s)

Transactions in ledger

online auditor

0

500

1000

1500

2000

2500

3000

3500

0K 20K 40K 60K 80K 100K

Transactions in ledger

offline auditor

0

20

40

60

80

100

120

2 3 4 5 6 7 8 9 10

Number of banks

offline auditor

online auditor

Figure 4 Time to audit ledgers of different sizes (4 banks) and with a varying number of banks (2000 row ledger) Audit time is independent of thesize of the ledger (left) thanks to commitment caches maintained by the online auditor When commitment cache optimization is turned off (middle)the audit time is linear in the size of the ledger Audit time grows with the number of banks (right) and is much higher without commitment caches

described in sect41 a bank needs to use its entry fromtransaction nminus1 to create transaction n So though a bankcan use many cores to produce the proofs for a singletransaction in parallel multiple banks cannot producedifferent transactions in parallel In zkLedger banks startcreating transaction n before seeing nminus 1 but the bankcannot complete the transaction until nminus1 is accepted tothe ledger and verified causing an inherent bottleneck

The second major cost is around verification Everybank must verify every transaction so the more banksthe larger each transaction and thus the more work thatneeds to be done by each bank The middle graph inFigure 3 measures the time it takes one bank to createand all participants in zkLedger to completely processa transaction One bank creates a transaction and sendsit to the ledger which then broadcasts the transaction toall banks and an online auditor The auditor and everybank verify the transaction As we increase the numberof banks work increases quadratically however bankscan verify transactions in parallel so the time to processtransactions only increases linearly The right graph inFigure 3 shows that as we surmised zkLedgerrsquos through-put worsens with more banks The one bank transactingline in this graph is the same data as the middle graph

Since range proofs dominate the costs of transactioncreation and verification we are optimistic that a fasterrange proof implementation will directly improve perfor-mance zkLedgerrsquos current performance is comparableto Solidus a privacy-preserving distributed ledger whichachieves 3-4 transactions per second with online valida-tion but unlike zkLedger does not support auditing

8 Future workzkLedger focuses on providing provably correct auditingover private transaction data but zkLedger does not havea way to recover if the distributed ledger is corrupted Inthis case the parties maintaining the ledger would haveto come together to recreate historical transactions zk-Ledger also does not provide recourse if a bank commitsan unintended transaction to the ledger A future ver-sion of zkLedger might provide rectifying transactions orparticipant agreed-upon rollback

9 ConclusionzkLedger is the first distributed ledger system to providestrong transaction privacy public verifiability and com-plete provably correct auditing zkLedger supports a richset of auditing queries which are useful to measure thefinancial health of a market We developed a design usingnon-interactive zero-knowledge proofs to prove transac-tions maintain financial invariants and to support auditingOur evaluation shows that zkLedger has reasonable per-formance for transaction settlement and auditing

10 AcknowledgementsWe thank Alexander Chernyakhovsky Thaddeus DryjaDavid Lazar Ronald L Rivest CJ Williams and ourshepherd and reviewers for helpful comments The re-search leading to these results has received funding fromthe Center for Science of Information (CSoI) an NSFScience and Technology Center under grant agreementCCF-0939370 and the Ethics and Governance of Artifi-cial Intelligence Fund

76 15th USENIX Symposium on Networked Systems Design and Implementation USENIX Association

References[1] Bank secrecy act of 1970 October 1970 12 USC 103[2] Package btcec implements support for the elliptic curves

needed for Bitcoin July 2017 httpsgodocorggithubcombtcsuitebtcdbtcec

[3] ABBE E A KHANDANI A E AND LO A WPrivacy-preserving methods for sharing financial risk ex-posures The American Economic Review 102 3 (2012)65ndash70

[4] ARASU A BLANAS S EGURO K KAUSHIK RKOSSMANN D RAMAMURTHY R AND VENKATE-SAN R Orthogonal security with cipherbase In CIDR(2013)

[5] BAJAJ S AND SION R Trusteddb A trusted hardware-based database with privacy and data confidentiality IEEETransactions on Knowledge and Data Engineering 26 3(2014) 752ndash765

[6] BAUMANN A PEINADO M AND HUNT G Shieldingapplications from an untrusted cloud with haven ACMTransactions on Computer Systems (TOCS) 33 3 (2015)8

[7] BEN-SASSON E CHIESA A GENKIN D TROMERE AND VIRZA M SNARKs for C Verifying programexecutions succinctly and in zero knowledge In Advancesin CryptologyndashCRYPTO 2013 Springer 2013 pp 90ndash108

[8] BEN-SASSON E CHIESA A GREEN M TROMERE AND VIRZA M Secure sampling of public parametersfor succinct zero knowledge proofs In Proceedings of the2015 IEEE Symposium on Security and Privacy (2015)SP rsquo15 pp 287ndash304

[9] BLUM M FELDMAN P AND MICALI S Non-interactive zero-knowledge and its applications In Pro-ceedings of the 20th Annual ACM Symposium on Theoryof Computing (1988) STOC rsquo88 pp 103ndash112

[10] BOGDANOV D TALVISTE R AND WILLEMSON JDeploying secure multi-party computation for financialdata analysis In International Conference on FinancialCryptography and Data Security (2012) Springer pp 57ndash64

[11] BOWE S GABIZON A AND GREEN M A multi-party protocol for constructing the public parameters ofthe Pinocchio zk-SNARK Cryptology ePrint ArchiveReport 2017602 2017

[12] BOWE S GABIZON A AND MIERS I Scalable multi-party computation for zk-SNARK parameters in the ran-dom beacon model Cryptology ePrint Archive Report20171050 2017

[13] BUNZ B BOOTLE J BONEH D POELSTRA AAND MAXWELL G Bulletproofs Short proofs for Con-fidential Transactions and more In Security and Privacy(SP) 2018 IEEE Symposium on (2018) IEEE

[14] BURKHART M STRASSER M MANY D AND DIM-ITROPOULOS X Sepia Privacy-preserving aggregationof multi-domain network events and statistics Network 1101101 (2010)

[15] CASTRO M AND LISKOV B Practical byzantine faulttolerance In OSDI (1999) vol 99 pp 173ndash186

[16] CECCHETTI E ZHANG F JI Y KOSBA A JUELSA AND SHI E Solidus Confidential distributed ledgertransactions via pvorm

[17] CHAIN I Confidential assets httpsblogchaincomhidden-in-plain-sight-transacting-privately-on-a-blockchain-835ab75c01cb

[18] CORRIGAN-GIBBS H AND BONEH D Prio Privaterobust and scalable computation of aggregate statisticsarXiv preprint arXiv170306255 (2017)

[19] COUNCIL F R Developments in audit 20162017full report 2017 httpwwwfrcorgukgetattachment915c15a4-dbc7-4223-b8ae-cad53dbcca17Developments-in-Audit-2016-17-Full-reportpdf

[20] CRAMER R DAMGARD I AND SCHOENMAKERSB Proofs of partial knowledge and simplified design ofwitness hiding protocols In Advances in Cryptology -CRYPTO rsquo94 14th Annual International Cryptology Con-ference Santa Barbara California USA August 21-251994 Proceedings (1994) pp 174ndash187

[21] DAGHER G G BUNZ B BONNEAU J CLARK JAND BONEH D Provisions Privacy-preserving proofsof solvency for Bitcoin exchanges In Proceedings of the22nd ACM SIGSAC Conference on Computer and Com-munications Security (Denver CO 2015) ACM pp 720ndash731

[22] Corda 2017 httpsgithubcomcordacorda

[23] Digital asset holdings 2017 httpdigitalassetcom

[24] Regulation (EU) 2016679 of the European Parliamentand of the Council of 27 April 2016 on the protection ofnatural persons with regard to the processing of personaldata and on the free movement of such data and repealingDirective 9546EC (General Data Protection Regulation)Official Journal of the European Union L119 (May 2016)1ndash88

[25] FELDMAN A J ZELLER W P FREEDMAN M JAND FELTEN E W Sporc Group collaboration us-ing untrusted cloud resources In OSDI (2010) vol 10pp 337ndash350

[26] FIAT A AND SHAMIR A How to prove yourselfpractical solutions to identification and signature problemsIn Proceedings of the 6th Annual International CryptologyConference (1987) CRYPTO rsquo87 pp 186ndash194

[27] GARMAN C GREEN M AND MIERS I Accountableprivacy for decentralized anonymous payments Cryp-tology ePrint Archive Report 2016061 2016 httpeprintiacrorg2016061

[28] GREENBERG A Fbi says itrsquos seized $285 million inbitcoins from ross ulbricht alleged owner of silk roadForbes 25 (2013)

USENIX Association 15th USENIX Symposium on Networked Systems Design and Implementation 77

0

100

200

300

400

500

600

2 4 6 8 10 12 14 16 18 20

Tim

e (

ms)

number of banks

verify-1create-1verify-12

create-12

0

200

400

600

800

1000

2 3 4 5 6 7 8 9 10

Tim

e (

ms)

number of banks

complete transactions

0

2

4

6

8

10

12

2 3 4 5 6 7 8 9 10

Th

rou

gh

pu

t (t

xn

ss

ec)

number of banks

all banks transactingone bank transacting

Figure 3 Transaction creation and verification time for one bank (left) varying the number of entries in the transaction Single-threaded andmulti-threaded performance with 12 threads Time to fully process a transaction including creation broadcast to ledger banks and auditor andverification by all parties (middle) Throughput (right) varying the number of banks

0

2

4

6

8

10

12

0K 20K 40K 60K 80K 100K

Au

ditin

g t

ime

(m

s)

Transactions in ledger

online auditor

0

500

1000

1500

2000

2500

3000

3500

0K 20K 40K 60K 80K 100K

Transactions in ledger

offline auditor

0

20

40

60

80

100

120

2 3 4 5 6 7 8 9 10

Number of banks

offline auditor

online auditor

Figure 4 Time to audit ledgers of different sizes (4 banks) and with a varying number of banks (2000 row ledger) Audit time is independent of thesize of the ledger (left) thanks to commitment caches maintained by the online auditor When commitment cache optimization is turned off (middle)the audit time is linear in the size of the ledger Audit time grows with the number of banks (right) and is much higher without commitment caches

described in sect41 a bank needs to use its entry fromtransaction nminus1 to create transaction n So though a bankcan use many cores to produce the proofs for a singletransaction in parallel multiple banks cannot producedifferent transactions in parallel In zkLedger banks startcreating transaction n before seeing nminus 1 but the bankcannot complete the transaction until nminus1 is accepted tothe ledger and verified causing an inherent bottleneck

The second major cost is around verification Everybank must verify every transaction so the more banksthe larger each transaction and thus the more work thatneeds to be done by each bank The middle graph inFigure 3 measures the time it takes one bank to createand all participants in zkLedger to completely processa transaction One bank creates a transaction and sendsit to the ledger which then broadcasts the transaction toall banks and an online auditor The auditor and everybank verify the transaction As we increase the numberof banks work increases quadratically however bankscan verify transactions in parallel so the time to processtransactions only increases linearly The right graph inFigure 3 shows that as we surmised zkLedgerrsquos through-put worsens with more banks The one bank transactingline in this graph is the same data as the middle graph

Since range proofs dominate the costs of transactioncreation and verification we are optimistic that a fasterrange proof implementation will directly improve perfor-mance zkLedgerrsquos current performance is comparableto Solidus a privacy-preserving distributed ledger whichachieves 3-4 transactions per second with online valida-tion but unlike zkLedger does not support auditing

8 Future workzkLedger focuses on providing provably correct auditingover private transaction data but zkLedger does not havea way to recover if the distributed ledger is corrupted Inthis case the parties maintaining the ledger would haveto come together to recreate historical transactions zk-Ledger also does not provide recourse if a bank commitsan unintended transaction to the ledger A future ver-sion of zkLedger might provide rectifying transactions orparticipant agreed-upon rollback

9 ConclusionzkLedger is the first distributed ledger system to providestrong transaction privacy public verifiability and com-plete provably correct auditing zkLedger supports a richset of auditing queries which are useful to measure thefinancial health of a market We developed a design usingnon-interactive zero-knowledge proofs to prove transac-tions maintain financial invariants and to support auditingOur evaluation shows that zkLedger has reasonable per-formance for transaction settlement and auditing

10 AcknowledgementsWe thank Alexander Chernyakhovsky Thaddeus DryjaDavid Lazar Ronald L Rivest CJ Williams and ourshepherd and reviewers for helpful comments The re-search leading to these results has received funding fromthe Center for Science of Information (CSoI) an NSFScience and Technology Center under grant agreementCCF-0939370 and the Ethics and Governance of Artifi-cial Intelligence Fund

76 15th USENIX Symposium on Networked Systems Design and Implementation USENIX Association

References[1] Bank secrecy act of 1970 October 1970 12 USC 103[2] Package btcec implements support for the elliptic curves

needed for Bitcoin July 2017 httpsgodocorggithubcombtcsuitebtcdbtcec

[3] ABBE E A KHANDANI A E AND LO A WPrivacy-preserving methods for sharing financial risk ex-posures The American Economic Review 102 3 (2012)65ndash70

[4] ARASU A BLANAS S EGURO K KAUSHIK RKOSSMANN D RAMAMURTHY R AND VENKATE-SAN R Orthogonal security with cipherbase In CIDR(2013)

[5] BAJAJ S AND SION R Trusteddb A trusted hardware-based database with privacy and data confidentiality IEEETransactions on Knowledge and Data Engineering 26 3(2014) 752ndash765

[6] BAUMANN A PEINADO M AND HUNT G Shieldingapplications from an untrusted cloud with haven ACMTransactions on Computer Systems (TOCS) 33 3 (2015)8

[7] BEN-SASSON E CHIESA A GENKIN D TROMERE AND VIRZA M SNARKs for C Verifying programexecutions succinctly and in zero knowledge In Advancesin CryptologyndashCRYPTO 2013 Springer 2013 pp 90ndash108

[8] BEN-SASSON E CHIESA A GREEN M TROMERE AND VIRZA M Secure sampling of public parametersfor succinct zero knowledge proofs In Proceedings of the2015 IEEE Symposium on Security and Privacy (2015)SP rsquo15 pp 287ndash304

[9] BLUM M FELDMAN P AND MICALI S Non-interactive zero-knowledge and its applications In Pro-ceedings of the 20th Annual ACM Symposium on Theoryof Computing (1988) STOC rsquo88 pp 103ndash112

[10] BOGDANOV D TALVISTE R AND WILLEMSON JDeploying secure multi-party computation for financialdata analysis In International Conference on FinancialCryptography and Data Security (2012) Springer pp 57ndash64

[11] BOWE S GABIZON A AND GREEN M A multi-party protocol for constructing the public parameters ofthe Pinocchio zk-SNARK Cryptology ePrint ArchiveReport 2017602 2017

[12] BOWE S GABIZON A AND MIERS I Scalable multi-party computation for zk-SNARK parameters in the ran-dom beacon model Cryptology ePrint Archive Report20171050 2017

[13] BUNZ B BOOTLE J BONEH D POELSTRA AAND MAXWELL G Bulletproofs Short proofs for Con-fidential Transactions and more In Security and Privacy(SP) 2018 IEEE Symposium on (2018) IEEE

[14] BURKHART M STRASSER M MANY D AND DIM-ITROPOULOS X Sepia Privacy-preserving aggregationof multi-domain network events and statistics Network 1101101 (2010)

[15] CASTRO M AND LISKOV B Practical byzantine faulttolerance In OSDI (1999) vol 99 pp 173ndash186

[16] CECCHETTI E ZHANG F JI Y KOSBA A JUELSA AND SHI E Solidus Confidential distributed ledgertransactions via pvorm

[17] CHAIN I Confidential assets httpsblogchaincomhidden-in-plain-sight-transacting-privately-on-a-blockchain-835ab75c01cb

[18] CORRIGAN-GIBBS H AND BONEH D Prio Privaterobust and scalable computation of aggregate statisticsarXiv preprint arXiv170306255 (2017)

[19] COUNCIL F R Developments in audit 20162017full report 2017 httpwwwfrcorgukgetattachment915c15a4-dbc7-4223-b8ae-cad53dbcca17Developments-in-Audit-2016-17-Full-reportpdf

[20] CRAMER R DAMGARD I AND SCHOENMAKERSB Proofs of partial knowledge and simplified design ofwitness hiding protocols In Advances in Cryptology -CRYPTO rsquo94 14th Annual International Cryptology Con-ference Santa Barbara California USA August 21-251994 Proceedings (1994) pp 174ndash187

[21] DAGHER G G BUNZ B BONNEAU J CLARK JAND BONEH D Provisions Privacy-preserving proofsof solvency for Bitcoin exchanges In Proceedings of the22nd ACM SIGSAC Conference on Computer and Com-munications Security (Denver CO 2015) ACM pp 720ndash731

[22] Corda 2017 httpsgithubcomcordacorda

[23] Digital asset holdings 2017 httpdigitalassetcom

[24] Regulation (EU) 2016679 of the European Parliamentand of the Council of 27 April 2016 on the protection ofnatural persons with regard to the processing of personaldata and on the free movement of such data and repealingDirective 9546EC (General Data Protection Regulation)Official Journal of the European Union L119 (May 2016)1ndash88

[25] FELDMAN A J ZELLER W P FREEDMAN M JAND FELTEN E W Sporc Group collaboration us-ing untrusted cloud resources In OSDI (2010) vol 10pp 337ndash350

[26] FIAT A AND SHAMIR A How to prove yourselfpractical solutions to identification and signature problemsIn Proceedings of the 6th Annual International CryptologyConference (1987) CRYPTO rsquo87 pp 186ndash194

[27] GARMAN C GREEN M AND MIERS I Accountableprivacy for decentralized anonymous payments Cryp-tology ePrint Archive Report 2016061 2016 httpeprintiacrorg2016061

[28] GREENBERG A Fbi says itrsquos seized $285 million inbitcoins from ross ulbricht alleged owner of silk roadForbes 25 (2013)

USENIX Association 15th USENIX Symposium on Networked Systems Design and Implementation 77

References[1] Bank secrecy act of 1970 October 1970 12 USC 103[2] Package btcec implements support for the elliptic curves

needed for Bitcoin July 2017 httpsgodocorggithubcombtcsuitebtcdbtcec

[3] ABBE E A KHANDANI A E AND LO A WPrivacy-preserving methods for sharing financial risk ex-posures The American Economic Review 102 3 (2012)65ndash70

[4] ARASU A BLANAS S EGURO K KAUSHIK RKOSSMANN D RAMAMURTHY R AND VENKATE-SAN R Orthogonal security with cipherbase In CIDR(2013)

[5] BAJAJ S AND SION R Trusteddb A trusted hardware-based database with privacy and data confidentiality IEEETransactions on Knowledge and Data Engineering 26 3(2014) 752ndash765

[6] BAUMANN A PEINADO M AND HUNT G Shieldingapplications from an untrusted cloud with haven ACMTransactions on Computer Systems (TOCS) 33 3 (2015)8

[7] BEN-SASSON E CHIESA A GENKIN D TROMERE AND VIRZA M SNARKs for C Verifying programexecutions succinctly and in zero knowledge In Advancesin CryptologyndashCRYPTO 2013 Springer 2013 pp 90ndash108

[8] BEN-SASSON E CHIESA A GREEN M TROMERE AND VIRZA M Secure sampling of public parametersfor succinct zero knowledge proofs In Proceedings of the2015 IEEE Symposium on Security and Privacy (2015)SP rsquo15 pp 287ndash304

[9] BLUM M FELDMAN P AND MICALI S Non-interactive zero-knowledge and its applications In Pro-ceedings of the 20th Annual ACM Symposium on Theoryof Computing (1988) STOC rsquo88 pp 103ndash112

[10] BOGDANOV D TALVISTE R AND WILLEMSON JDeploying secure multi-party computation for financialdata analysis In International Conference on FinancialCryptography and Data Security (2012) Springer pp 57ndash64

[11] BOWE S GABIZON A AND GREEN M A multi-party protocol for constructing the public parameters ofthe Pinocchio zk-SNARK Cryptology ePrint ArchiveReport 2017602 2017

[12] BOWE S GABIZON A AND MIERS I Scalable multi-party computation for zk-SNARK parameters in the ran-dom beacon model Cryptology ePrint Archive Report20171050 2017

[13] BUNZ B BOOTLE J BONEH D POELSTRA AAND MAXWELL G Bulletproofs Short proofs for Con-fidential Transactions and more In Security and Privacy(SP) 2018 IEEE Symposium on (2018) IEEE

[14] BURKHART M STRASSER M MANY D AND DIM-ITROPOULOS X Sepia Privacy-preserving aggregationof multi-domain network events and statistics Network 1101101 (2010)

[15] CASTRO M AND LISKOV B Practical byzantine faulttolerance In OSDI (1999) vol 99 pp 173ndash186

[16] CECCHETTI E ZHANG F JI Y KOSBA A JUELSA AND SHI E Solidus Confidential distributed ledgertransactions via pvorm

[17] CHAIN I Confidential assets httpsblogchaincomhidden-in-plain-sight-transacting-privately-on-a-blockchain-835ab75c01cb

[18] CORRIGAN-GIBBS H AND BONEH D Prio Privaterobust and scalable computation of aggregate statisticsarXiv preprint arXiv170306255 (2017)

[19] COUNCIL F R Developments in audit 20162017full report 2017 httpwwwfrcorgukgetattachment915c15a4-dbc7-4223-b8ae-cad53dbcca17Developments-in-Audit-2016-17-Full-reportpdf

[20] CRAMER R DAMGARD I AND SCHOENMAKERSB Proofs of partial knowledge and simplified design ofwitness hiding protocols In Advances in Cryptology -CRYPTO rsquo94 14th Annual International Cryptology Con-ference Santa Barbara California USA August 21-251994 Proceedings (1994) pp 174ndash187

[21] DAGHER G G BUNZ B BONNEAU J CLARK JAND BONEH D Provisions Privacy-preserving proofsof solvency for Bitcoin exchanges In Proceedings of the22nd ACM SIGSAC Conference on Computer and Com-munications Security (Denver CO 2015) ACM pp 720ndash731

[22] Corda 2017 httpsgithubcomcordacorda

[23] Digital asset holdings 2017 httpdigitalassetcom

[24] Regulation (EU) 2016679 of the European Parliamentand of the Council of 27 April 2016 on the protection ofnatural persons with regard to the processing of personaldata and on the free movement of such data and repealingDirective 9546EC (General Data Protection Regulation)Official Journal of the European Union L119 (May 2016)1ndash88

[25] FELDMAN A J ZELLER W P FREEDMAN M JAND FELTEN E W Sporc Group collaboration us-ing untrusted cloud resources In OSDI (2010) vol 10pp 337ndash350

[26] FIAT A AND SHAMIR A How to prove yourselfpractical solutions to identification and signature problemsIn Proceedings of the 6th Annual International CryptologyConference (1987) CRYPTO rsquo87 pp 186ndash194

[27] GARMAN C GREEN M AND MIERS I Accountableprivacy for decentralized anonymous payments Cryp-tology ePrint Archive Report 2016061 2016 httpeprintiacrorg2016061

[28] GREENBERG A Fbi says itrsquos seized $285 million inbitcoins from ross ulbricht alleged owner of silk roadForbes 25 (2013)

USENIX Association 15th USENIX Symposium on Networked Systems Design and Implementation 77

[29] HERFINDAHL O C Concentration in the steel industryPhD thesis Columbia University New York 1950

[30] LAMPORT L ET AL Paxos made simple ACM SigactNews 32 4 (2001) 18ndash25

[31] LI J KROHN M N MAZIERES D AND SHASHAD E Secure untrusted data repository (sundr) In OSDI(2004) vol 4 pp 9ndash9

[32] MAHAJAN P SETTY S LEE S CLEMENT AALVISI L DAHLIN M AND WALFISH M DepotCloud storage with minimal trust ACM Transactions onComputer Systems (TOCS) 29 4 (2011) 12

[33] MAURER U Unifying zero-knowledge proofs of knowl-edge Proceedings of the 2nd International Conference onCryptology in Africa (2009) 272ndash286

[34] MAXWELL G Confidential transactions httpspeoplexiphorg˜gregconfidential_valuestxt (Accessed 82017) (2015)

[35] MAXWELL G AND POELSTRA A Borromean ringsignatures httpsrawgithubusercontentcomBlockstreamborromean_papermasterborromean_draft_001_34241bbpdf (Accessed 62017) (2015)

[36] MEIKLEJOHN S POMAROLE M JORDAN GLEVCHENKO K MCCOY D VOELKER G M AND

SAVAGE S A fistful of bitcoins characterizing paymentsamong men with no names In Proceedings of the 2013conference on Internet measurement conference (2013)ACM pp 127ndash140

[37] NAKAMOTO S Bitcoin A peer-to-peer electronic cashsystem 2008

[38] OBER M KATZENBEISSER S AND HAMACHER KStructure and anonymity of the bitcoin transaction graphFuture internet 5 2 (2013) 237ndash250

[39] ONGARO D AND OUSTERHOUT J K In search of anunderstandable consensus algorithm In USENIX AnnualTechnical Conference (2014) pp 305ndash319

[40] PAPADIMITRIOU A BHAGWAN R CHANDRAN NRAMJEE R HAEBERLEN A SINGH H MODI AAND BADRINARAYANAN S Big data analytics overencrypted datasets with seabed In OSDI (2016) pp 587ndash602

[41] PEDERSEN T P Non-interactive and information-theoretic secure verifiable secret sharing In Proceedingsof the 11th Annual International Cryptology Conference(1992) CRYPTO rsquo91 pp 129ndash140

[42] POELSTRA A BACK A FRIEDENBACH MMAXWELL G AND WUILLE P Confidential assets2017 4th Workshop on Bitcoin and Blockchain Research

[43] POPA R A REDFIELD C ZELDOVICH N AND BAL-AKRISHNAN H CryptDB protecting confidentiality withencrypted query processing In Proceedings of the Twenty-Third ACM Symposium on Operating Systems Principles(2011) ACM pp 85ndash100

[44] POPA R A STARK E HELFER J VALDEZ S ZEL-DOVICH N KAASHOEK M F AND BALAKRISHNAN

H Building web applications on top of encrypted datausing mylar In NSDI (2014) pp 157ndash172

[45] REID F AND HARRIGAN M An analysis of anonymityin the bitcoin system In Security and privacy in socialnetworks Springer 2013 pp 197ndash223

[46] RON D AND SHAMIR A Quantitative analysis ofthe full bitcoin transaction graph In International Confer-ence on Financial Cryptography and Data Security (2013)Springer pp 6ndash24

[47] SASSON E B CHIESA A GARMAN C GREENM MIERS I TROMER E AND VIRZA M ZerocashDecentralized anonymous payments from Bitcoin In Se-curity and Privacy (SP) 2014 IEEE Symposium on (2014)IEEE pp 459ndash474

[48] SCHNORR C-P Efficient signature generation by smartcards Journal of cryptology 4 3 (1991) 161ndash174

[49] SCHUSTER F COSTA M FOURNET C GKANTSIDISC PEINADO M MAINAR-RUIZ G AND RUSSI-NOVICH M Vc3 Trustworthy data analytics in the cloudusing sgx In Security and Privacy (SP) 2015 IEEE Sym-posium on (2015) IEEE pp 38ndash54

[50] TU S KAASHOEK M F MADDEN S AND ZEL-DOVICH N Processing analytical queries over encrypteddata In Proceedings of the VLDB Endowment (2013)vol 6 VLDB Endowment pp 289ndash300

[51] Zcash 2017 httpzcash[52] ZHENG W DAVE A BEEKMAN J G POPA R A

GONZALEZ J E AND STOICA I Opaque An obliviousand encrypted distributed analytics platform In NSDI(2017) pp 283ndash298

A Auditing QueriesFigure 5 is a list of the types of measurements zkLedgersupports including the estimated running time and thedata beyond the measurement that is leaked For exampleas described in sect5 computing transaction size variancerequires leaking the mean transaction size and number oftransactions per bank

B Zero-knowledge proofs and privacyguarantees

To build our zero-knowledge protocols we rely on thefollowing general result of Maurer (Theorem 3 [33])

Theorem B1 Let (H1) and (H2otimes) be two (not-necessarily commutative) groups and f H1rarr H2 be agroup homomorphism f (x y) = f (x)otimes f (y) Let ` isin Zu isin H1 C sub Z be such that1 gcd(c1minus c2 `) = 1 for all c1c2 isin C (with c1 6= c2)

and2 f (u) = z`There exists a 2-extractable Σ-protocol for languageL = z existw st z = f (w) Moreover a protocol con-

78 15th USENIX Symposium on Networked Systems Design and Implementation USENIX Association

Measurement Time Additional information leaked

Sum total of asset(s) per bank O(1) noneOutlier transactions per bank O(n) noneConcentration O(k) Sum totals per bankRatio holdings O(k) Sum totals per bank number of transactions per bankMean transaction size per bank O(kn) Number of transactions per bankVariance skew kurtosis O(kn) Mean per bank number of transactions per bankReal-time price averages O(kn) Number of transactions and average per bank over time period t

Figure 5 Types of supported auditing queries their running time to audit based on the number of banks k and the number of rows in the ledger nand a description of what information is leaked to the auditor

sisting of s rounds is proof-of-knowledge if 1|C |s is negli-gible and zero-knowledge if |C | is polynomially bounded

Using Theorem B1 we can now unify the treatmentof most of the zero-knowledge proofs used in our sys-tem For example the consistency proofs πC rely on thefollowing result

Theorem B2 Let G be an order-r cyclic group andghpk be any three elements of G There exists a2-extractable Σ-protocol for language Laux = (cmToken) existvr st cm= gvhr andToken= pkr

Proof Consider H1 = ZrtimesZr defining the group opera-tion to be component-wise addition and let H2 =GtimesGsimilarly defining group operation to be component-wise Then f (xy) = (gxhypky) is a group homomor-phism between H1 and H2 Indeed f (x1 + x2y1 + y2) =(gx1+x2hy1+y2 pky1+y2) = f (x1y1)otimes f (x2y2) Further-more setting ` = r and u = (00) we have that for allz isinH2 the following holds z` = (11) = f (u) Thereforewe can apply Theorem B1 and conclude that Laux has a2-extractable Σ-protocol

To summarize the three proofs in zkLedger (see Sec-tion 43) that relate commitments cmi = gvihri and audittokens Tokeni = (pki)

ri have the following formbull Proof of Assets (πA) This proof consists of a new

commitment cmprimei together with an audit token Tokenprimeiand a zero-knowledge proof asserting that either cmprimei isa re-commitment of the value in cmi or a recommitmentto the sum of the values in prod

mj=0 cm j To create this

proof zkLedger relies on Theorem B1 for constituentproofs as these are Sigma-protocols we apply the stan-dard OR-composition [20] to get the final disjunctivezero-knowledge proof To prove that the commitedvalue is in the range we use the range proofs in Confi-dential Assets [42] We are investigating more recentproof systems (eg Bulletproofs [13]) to further reducethe proof size

bull Proof of Balance (πB) In our implementation thisproof is an empty string the prover simply chooses the

commitment randomness subject to condition sumri = 0With such a choice the auditor homomorphically addsthe commitments and checks that this addition resultsin the neutral element of the group prodcmi = gsumvihsumri =g0h0 = 1

bull Proof of Consistency (πC) We use two proofs derivedfrom Theorem B2 to assert that the randomness usedin cmi and Tokeni are the same and the randomnessused in cmprimei and Tokenprimei are the same

C Privacy in the combined systemPedersen commitments provide information-theoretic pri-vacy In zkLedger Pedersen commitments are publishedtogether with authentication tokens and zero-knowledgeproofs We note that zero-knowledge proofs indeed donrsquotspoil the information-theoretic privacy of committed val-ues the output of the zero-knowledge proof simulatoris identical to the output produced by parties in the sys-tem However when combining Pedersen commitmentsand authentication tokens the privacy guarantees becomecomputational as we now explain

The commitment audit token and public keytriple (cmToken) is of the form (gvhrpkrpk) =(gvhrhskmiddotrhsk) and these three values uniquely deter-mine the v That is if an adversary could break the dis-crete logarithm problem it could solve for sk use that andvalue of Token to infer r and finally recover v That saidunder the Decisional Diffie-Hellman (DDH) assumptionno information is leaked Furthermore the DDH assump-tion is widely assumed to hold in zkLedgerrsquos elliptic curvegroup

Recall that DDH holds if no polynomially-boundedadversary can distinguish between tuples of the form(hhahbhab) and (hhahbhc) for a randomly chosengenerator h and exponents abc Assume that a state-ful adversary AzkL when given input (ghpk) is able toproduce two values v1 and v2 such that it can distinguishcommitments (and associated audit tokens) to v1 fromcommitments (and audit tokens) to v2 ie the adversaryis able to distinguish the distributions (gv1hrhskmiddotrhsk)

USENIX Association 15th USENIX Symposium on Networked Systems Design and Implementation 79

and (gv2hrhskmiddotrhsk) We now show how to use AzkL toconstruct an adversary ADDH breaking the DDH assump-tions

After receiving its challenge (hxyz) where (xyz)is distributed either as (hahbhab) or as (hahbhc) theadversary ADDH proceeds as follows It samples a randomgenerator g and calls AzkL on input (ghx) x now servingthe role of the bankrsquos public key When AzkL returnstwo values v1 and v2 the DDH adversary ADDH picks arandom k isin 12 and prepares cmk = gvk y Token = zand sends (cmkToken) to AzkL Finally if AzkLrsquos guessfor k is correct ADDH responds that the DDH challengewas of the form (hhahbhab) (ie a DDH quadruple)otherwise it responds that the DDH challenge was of the

form (hhahbhc) (ie a random quadruple)Note that when ADDHrsquos challenge is a DDH quadru-

ple the zkLedger adversary AzkL is run on a distributionit expects In particular all of its inputs are correctlyformed with respect to sk= a and r = b Whereas whenADDHrsquos challenge is a random quadruple the inputs toAzkL have information-theoretically no information aboutthe committed value indeed Token= hc is unrelated tocm = gvhb Therefore if the zkLedger adversary AzkL

wins the commitment hiding game with non-negligibleadvantage so does ADDH in the DDH game Note thatthe proof extends to the multiple entry case by a standardhybrid argument

80 15th USENIX Symposium on Networked Systems Design and Implementation USENIX Association

• 1 Introduction
• 2 Related Work
• • 21 Computing on Private Data
  • 22 Privacy-preserving blockchains
  • • 3 zkLedger Overview
    • • 31 Architecture
      • 32 Cryptographic building blocks
      • 33 Security Goals
      • 34 Threat model
      • • 4 Design
        • • 41 Transactions
          • 42 Auditing Protocol
          • 43 Final transaction construction
          • 44 Adding or removing banks
          • 45 Optimizations
          • • 5 Auditing
            • 6 Implementation
            • 7 Evaluation
            • • 71 Experimental setup
              • 72 Proof overhead in zkLedger
              • 73 Cost of auditing ledgers
              • 74 Scaling with more banks
              • • 8 Future work
                • 9 Conclusion
                • 10 Acknowledgements
                • A Auditing Queries
                • B Zero-knowledge proofs and privacy guarantees
                • C Privacy in the combined system

and (gv2hrhskmiddotrhsk) We now show how to use AzkL toconstruct an adversary ADDH breaking the DDH assump-tions

After receiving its challenge (hxyz) where (xyz)is distributed either as (hahbhab) or as (hahbhc) theadversary ADDH proceeds as follows It samples a randomgenerator g and calls AzkL on input (ghx) x now servingthe role of the bankrsquos public key When AzkL returnstwo values v1 and v2 the DDH adversary ADDH picks arandom k isin 12 and prepares cmk = gvk y Token = zand sends (cmkToken) to AzkL Finally if AzkLrsquos guessfor k is correct ADDH responds that the DDH challengewas of the form (hhahbhab) (ie a DDH quadruple)otherwise it responds that the DDH challenge was of the

form (hhahbhc) (ie a random quadruple)Note that when ADDHrsquos challenge is a DDH quadru-

ple the zkLedger adversary AzkL is run on a distributionit expects In particular all of its inputs are correctlyformed with respect to sk= a and r = b Whereas whenADDHrsquos challenge is a random quadruple the inputs toAzkL have information-theoretically no information aboutthe committed value indeed Token= hc is unrelated tocm = gvhb Therefore if the zkLedger adversary AzkL

wins the commitment hiding game with non-negligibleadvantage so does ADDH in the DDH game Note thatthe proof extends to the multiple entry case by a standardhybrid argument

80 15th USENIX Symposium on Networked Systems Design and Implementation USENIX Association

• 1 Introduction
• 2 Related Work
• • 21 Computing on Private Data
  • 22 Privacy-preserving blockchains
  • • 3 zkLedger Overview
    • • 31 Architecture
      • 32 Cryptographic building blocks
      • 33 Security Goals
      • 34 Threat model
      • • 4 Design
        • • 41 Transactions
          • 42 Auditing Protocol
          • 43 Final transaction construction
          • 44 Adding or removing banks
          • 45 Optimizations
          • • 5 Auditing
            • 6 Implementation
            • 7 Evaluation
            • • 71 Experimental setup
              • 72 Proof overhead in zkLedger
              • 73 Cost of auditing ledgers
              • 74 Scaling with more banks
              • • 8 Future work
                • 9 Conclusion
                • 10 Acknowledgements
                • A Auditing Queries
                • B Zero-knowledge proofs and privacy guarantees
                • C Privacy in the combined system