The Keep Network: A Privacy Layer for Public Blockchains Matt Luongo Corbin Pon [email protected] [email protected] Abstract Zcash [6], a cryptocurrency using zk-SNARKs to ensure transaction privacy. We introduce the keep, a new privacy As early as December 2014, Vitalik Buterin, primitive for developing smart con- one of the founders of Ethereum, explored tracts on public blockchains, enabling solving this problem with secure multi party secure storage and usage of secrets, as computation (sMPC) [7]. In more recent writ- well as supporting infrastructure, in- ing, Buterin shares that “when [he] and others cluding the keep market and token. talk to companies about building their appli- Our incremental approach to privacy cations on a blockchain, two primary issues infrastructure can be brought to mar- always come up: scalability and privacy” [8]. ket on the Ethereum public network, it- Scalability of public blockchains is a hur- erated on, and adapted for other public dle to mainstream adoption. Some of the best blockchains and cross-blockchain use. minds in the cryptocurrency space [9] [10] [11] are working on multiple order-of-magnitude 1 Motivation improvements. Privacy, however, hasn’t gar- 1.1 The irony of public blockchains nered the same attention, especially in smart Public blockchains have brought unprece- contracts. dented transparency and auditability to finan- Basic use cases of smart contracts, includ- cial technology. Records are immutable, veri- ing publishing secrets after certain criteria are fiable, and censorship-resistant. met, assessing borrower risk for a loan, and Unfortunately, these strengths are also signing messages and transactions, are incred- weaknesses for many potential users. ibly difficult on today’s public blockchains. For every financial use case a public 1.2 Existing approaches blockchain enables, its public status restricts another. Bitcoin is touted as a more private In practice, developers have found a number of payment method than the traditional finan- ways to build decentralized applications that cial system, but those familiar with the tech- use private data. nology know that while it may be censorship- resistant, it’s certainly not private by de- 1.2.1 The hash-reveal pattern fault [1]. Developers introduced to Ethereum A common pattern on public blockchains is to quickly learn to adjust their expectations keep private data with the application’s users. [2]- all contract state is published to the Contracts can receive and manipulate hashes blockchain, and can be easily read by compet- of private data, more generally called commit- ing interests. ments [12], while users withold the original un- These issues are recognized by developers of til revealing the private data off-chain. We call the Bitcoin and Ethereum projects. this the “hash-reveal” pattern. Confidential transactions [3] is an ongoing For many applications, this approach is sat- effort to bring better privacy, and therefore isfactory. There’s a clear privacy benefit over fungibility, to Bitcoin via sidechains [4]. The typical web applications- no centralized third- Zerocash project [5] applied zero-knowledge party database is at risk. Spreading storage proofs to Bitcoin, leading to the creation of across many users means a distributed, diverse Draft: 518f7b5fa4 - November 27, 2018
target for attackers. prove they have access to funds, or in the case There are significant downsides, however. of Zcash, for a party to prove to miners that a The hash-reveal pattern requires that all users transaction is valid according to the consensus party to a transaction be online, monitoring rules of the network. the system, providing private data when nec- Zero-knowledge proofs can be used to con- essary, and validating hashes against private struct private financial systems on a public data provided by other users. blockchain. On their own, however, they stop This requirement makes the hash-reveal short of allowing safe delegation of private pattern inflexible for complex protocols, and data from one party to another, and suffer the unsuitable for systems that don’t revolve solely same always-online requirements of the “hash- around active human participants, like decen- reveal” pattern. tralized autonomous organizations (DAOs). Zero-knowledge proofs are a powerful cryp- tographic tool, and can be used in conjunction 1.2.2 Private blockchains with other techniques to safely delegate secret Another response to privacy restrictions, pri- access and computation (see section 3.1). marily from the finance industry, has been to build private blockchains, or so-called “per- 1.3 Public applications, private data missioned ledgers”. None of these techniques adequately address These systems operate in a trusted or semi- how to build a publicly verifiable, decen- trusted manner. Instead of using proof-of- tralized, censorship-resistant application that work or other consensus mechanisms designed makes use of private data. with an adversarial network in mind, they can Consider contracts to reveal a secret in case use systems like RAFT to reach consensus. of a dispute between two parties, to sign a mes- One such system, J.P. Morgan’s Quorum sage verifying contract identity off-chain, or to [13], is a fork of Ethereum supporting pri- securely encrypt files 1 . vate contract state and messaging between network participants. Another, Microsoft’s re- 2 Introducing keeps cently announced Coco Framework [14], pro- vides data privacy atop an existing private To solve this mismatch between the trans- blockchain. parency of public blockchains, and the need of These systems solve privacy at the ex- many autonomous smart contracts for private pense of many of the benefits of a public data, we introduce the keep. blockchain- trustlessness, public accountabil- A keep is an off-chain container for private ity, censorship-resistance, and permissionless data. Keeps allow contracts to manage and innovation. use private data without exposing the data to the public blockchain. 1.2.3 Zero-knowledge proofs 2.1 Keep operations Zero-knowledge proofs have been leveraged to maintain privacy on public blockchains- most Though keeps maintain state off-chain, they famously, by the Zcash [6] project. are provisioned and messaged by contracts on- Zero-knowledge proofs allow one party, the chain. We will describe the keep in terms of prover, to prove a statement to another party, these on-chain operations. The practical im- the verifier, without revealing the knowledge plementation of keeps, including security guar- used to prove that statement. For example, a antees, is covered in sections 3 and 4. prover could show that they have access to a 2.1.1 Creation and population private key by encrypting a message chosen by a verifier. The proof can be trivially checked A contract, Contractowner , requests a keep by by the verifier by decrypting the cyphertext publishing a request to the blockchain. Once a with the public key. The private key, however, keep, Keepaccepted , has accepted a request and remains secret. finished initializing off-chain, it will respond to More relevant to the domain, zero- 1 We go over applications in more depth later in sec- knowledge proofs can be used for a party to tion 8 Draft: 518f7b5fa4 - November 27, 2018
Keep operations Create: Contractowner publishes a creation request, including an ini- tial deposit and a public key, KContractowner . Accept: A keep, Keepaccepted , publishes one or more public keys KKeepacceptedi signalling readiness. Populate: Contractowner publishes an initial secret on-chain, en- crypted in total or in shares by one or more KKeepacceptedi , or a specification for a secret to be generated. Grant: Contractowner publishes another contract address, Contractdelegate , and a permission level, Pread or Padmin . Compute: Contractowner or Contractdelegate publishes a function to compute over the secret, F (S, ...), as well as other arguments to F . Initially F ∈{fidentity , frsa , fecdsa }, though additional functions are planned. Results: Keepaccepted publishes the results of its computation, either in whole or in part, over one or more invocations. Shutdown: Contractowner or Contractdelegate with permission Padmin publishes a shutdown request. the request with a set of public keys the call- to request that a keep’s content be published ing contract can use to communicate privately (read permission, Pread ), or to delegate further with the keep. access to other contracts (admin permission, Once the keep has been created, it can Padmin ). Owners (Contractowner ) can also re- be populated in a number of ways. dApps voke their own access. can publish secret data to the blockchain, en- Access management enables multi-party se- crypted by the keep’s public keys, or send cret escrow and auditability of secret access. the data to the keep off-chain. Alternatively, 2.1.4 Destruction a keep can self-populate with pseudorandom data. Depending on the use case, keeps can be long- or short-lived. Contracts can request that a 2.1.2 Publishing data on-chain keep shut down, and should also handle keeps The purpose of a keep is to compute a function that are terminated unexpectedly, scenarios over its secret and publish the results to the which are covered in more detail later in sec- blockchain. tion 5.2. Initially, keeps will support publishing their 3 Eliminating third-party risk secrets on-chain, unmodified or encrypted with a public key provided by Contractowner . We’ve described a simple black box for off- This enables functionality that’s difficult in chain data storage. The standardization of today’s public smart contracts, like a secret- this method of secret management will enable exposing dead man switch, useful in a variety secrets to be bought, sold, and transferred on a of decentralized market schemes. public blockchain, but doesn’t inherently solve Keeps can be extended to use their secret in third-party risks. a variety of other ways, including as key ma- Next, we’ll describe techniques to eliminate terial for symmetric encryption and signing. third-party risk. 2.1.3 Access management 3.1 Secure multi party computation The owning contract Contractowner of a keep Secure multi party computation (sMPC) is a can delegate access to the keep to other con- type of cryptographic system where a compu- tracts. tation is distributed across multiple partici- Read and admin access can each be granted, pants, some of which may be dishonest. Each allowing another contract i(Contractdelegate ) participant is initially given access to a share Draft: 518f7b5fa4 - November 27, 2018
of a secret by a dealer, and computes a func- due to restrictions on the security model. Ex- tion over that share. The outputs are then isting sMPC solutions only maintain security reported to the dealer, who can assemble the in the face of an honest majority of parties. final output, without any participant learning The advent of the blockchain enables se- more than their initial secret share. cure usage of sMPC in adversarial scenarios. Intuitively, sMPC works like this: By using a public blockchain as an immutable ledger, sMPC can be made secure in the face of 1. A dealer D wants to compute a function a dishonest supermajority [17], and, with the F over a secret, S. requirement of a network token, can be made 2. The dealer selects n parties to the com- strongly Sybil-resistant (see section 5). putation, sending each of them a share of For these reasons, sMPC and blockchains the secret, si . are a natural fit. In the smart contract space, sMPC has been proposed before as a privacy 3. Each party computes a function over their mechanic. share fi (si ) and reports the result to the In 2014, Vitalik Buterin gave a strong in- dealer. troduction to the subject in an early blog post on privacy on the Ethereum public blockchain 4. The dealer combines these outputs, such [7]. In 2016, a team from UMD designed Hawk that G(f1 (s1 ), f2 (s2 ), ...fn (sn )) = F (S) [18], a system that marries public and private The shares si should be chosen in such a way smart contracts via sMPC, and the Enigma that exposing any share does not jeopardize project out of MIT describes a system related the secret S. A common approach is to use to ours [19], with a wider focus on general pri- Shamir’s secret sharing [15], such that details vate computation. about the secret remain confidential in the face The Keep network will incorporate these of n − 1 dishonest parties. ideas into the first production-ready sMPC This explanation holds for all F including system for a public blockchain. addition, subtraction, and multiplication by a known constant. To achieve general compu- 4 Keep providers tation, however, we also need to be able to multiply secrets securely. The Keep network includes a number of dif- Multiplication adds what the literature calls ferent provider types, each with their own “rounds”- communication between the parties, strengths and tradeoffs. The most important rather than just the dealer D. provider, however, is a novel application of se- To multiply two secrets, each party Pi of cure multi party computation. the n chosen by the dealer splits its share, si , into two components, si1 and si2 . The party 4.1 Simple sMPC multiplies those two components, resulting in si0 . Each Pi then acts as a dealer among the Simple sMPC keeps are backed by n nodes, the remaining parties, splitting si0 into n − 1 each of which maintain a share of the pro- pieces. vided secret, such that the secret can’t be re- Each Pi can now resolve their resulting share constructed without all n nodes colluding. of the round of multiplication, s0i , given their These keeps can be populated securely by access to n − 1 shares of si0 . divvying up a secret into shares via Shamir With addition and multiplication, sMPC secret sharing [15], and encrypting each share can securely execute general computation, at with its respective node’s public key. The en- the expense of communication overhead be- crypted shares can then be published to the tween the computing parties. public blockchain, or communicated off-chain. The only computation these keeps will run 3.2 sMPC and the blockchain is an implementation of distributed RSA [20] sMPC was originally conceived in 1982 [16], on sMPC, used to publish encrypted data to but its practical application has been limited the blockchain. Draft: 518f7b5fa4 - November 27, 2018
4.2 Signing sMPC imize the attack surface on keeps in a produc- The next provider will extend the sMPC keep tion network. with two new operations- securely generating In later work, sMPC schemes can be used pseudorandom numbers, and signing and en- to build more feature-rich keeps. These keeps crypting data, using the keep’s contents as a will enable complex use cases, like operating key. private ledgers against public blockchains, or In addition to simple pseudorandom num- running third-party code trustlessly on private bers, signing keeps will be able to generate data. RSA [20] and Bitcoin [21, 22] key pairs, or be 5 Incentivizing keep providers populated with them via secret sharing. This means signing keeps will be able to sign Providers need to be incentivized to maintain and secure contract communications on- and capacity on the network. Running and secur- off-chain, as well as sign transactions for Bit- ing keeps should be a profitable way to use coin, Ethereum, and other cryptocurrencies. excess compute and storage resources. Finally, signing keeps can act as pRNG or- Consumer contracts, on the other hand, acles, significantly improving current meth- need keeps that will provide: ods of random number generation on public blockchains. High availability 4.3 Future providers Robustness against data loss The off-chain keep pattern is flexible enough to Maintenance of confidentiality include a variety of other pluggable providers, each with their own unique benefits. Data integrity 4.3.1 Secure hardware 5.1 Paying for keeps Keeps backed by secure hardware can be used The best payment structure for keep providers to lower the cost of securing private data by will reward highly available keeps, and punish verifying that only signed code is run against poor performance. privileged data. ¡sequence diagram of deposit + per- Instead of requiring n nodes to safely split operation payment¿ a secret, a secret can be sent to a single The two primary costs providers incur are node that’s properly responded to a chal- storage and compute, which map naturally to lenge, proving it’s running signed code. Not paying keeps per block and per operation. only are fewer nodes required, but these keeps Payment per block can be accomplished via wouldn’t suffer the computation overhead of a deposit to the managing contract at the time secure multi-party computation. of keep initialization, metered out over the life- This sort of security is fundamentally time of the keep, and refilled occasionally by weaker than that provided by secure multi- the calling contract. Though this seems like party computation. If a single secure hard- a good fit for payment channels, minimizing ware manufacturer is compromised, it puts all on-chain fees, the security ramifications differ nodes using that hardware at risk, shifting the from typical two-party channels. These differ- threat model. The cost and benefit of this ap- ences are discussed further in the next section. proach will depend on the application. Payment per operation is simpler. Each re- quest to publish a keep’s contents will require 4.3.2 Private smart contracts payment of an amount agreed to at the initial- Unlike related work on systems like Enigma ization of a keep. [19] or Hawk [18], which use sMPC to build off- chain and alternative-chain computation net- 5.2 Concerns with uptime and works for private smart contracts, we’ve cho- reliability sen to restrict the initial sMPC keeps to gener- Because availability is vital to using keeps in ating, securing, storing, encrypting, and trans- practice, improper termination must be disin- mitting secrets. Such restrictions help to min- centivized. Draft: 518f7b5fa4 - November 27, 2018
¡proper shutdown protocol¿ to ensure their overwhelming selection backing Any keep that doesn’t respond properly new keeps. within a certain block count threshold to a Second, keep redundancy can be used to request will be considered aborted. Aborted further minimize availability disruptions [25]. keeps will forfeit all client deposits that have All nodes can be required to include a deposit yet to be disbursed. To avoid skewing client when they publish their results. If their results incentives, the deposits that have been earned, can’t be verified by the included SPDZ proof, but not yet disbursed, will be burned, and their deposit is forfeit to competing nodes. the unearned deposits will be returned to the client. 6 High-level network design Volatility in the crypto currency markets Deploying sMPC-based privacy on a public can provide a strong incentive for a keep blockchain requires supporting infrastructure. provider to improperly terminate a keep. If To build a functional privacy network against the value of the paid currency drops signifi- Ethereum, our first target blockchain, we’ll in- cantly relative to the cost of running a keep, troduce components to ensure fair keep node it’s in a provider’s best interest to devote their selection, report results, and incentivize net- limited resources to a better-paying client. work actors. To counter this issue, keep providers will need a protocol to optionally re-negotiate fees 6.1 The Keep network token for a running keep. The native network token, KEEP, will be re- quired for providers to participate. 5.3 Concerns with active attacks To be chosen to provide a node for a new Existing open-source sMPC frameworks, such keep, a provider must lock up a minimum as VIFF [23], are secure against active attacks stake in KEEP tokens, using a shared staking in the presence of a ¾ supermajority of honest contract. nodes. In such an attack, keeps can be forced At any time, a provider can choose to re- to return malformed data, but secrets can’t be trieve their stake— for example, to liquidate compromised unless all nodes with a unique their position. All withdrawals, however, will share backing an sMPC keep are colluding- an be subject to a two-week waiting period to dis- extremely high bar for a Sybil attack. incentivize providers from quickly staking and Recent approaches using SPDZ proofs [17] withdrawing their position, which could have anchored on the blockchain [24, 25] make adverse effects on running keeps and fair keep such correctness attacks impossible, even if selection. all nodes backing a keep are compromised. Requiring a native token, rather than sMPC keeps will publish proofs to the pub- the underlying blockchain’s currency, means lic blockchain that can be used to verify cor- providers will suffer from negative externali- rectness. The threat of active attacks is then ties in the presence of malicious behavior (see reduced to disrupting keep availability, rather section 5.3). This sort of staking also strength- than returning malformed data. ens the system against Sybil attacks (see sec- We address the issue of network disrup- tion 6.2). tion by introducing two incentives to keep providers, making active attacks on data avail- 6.2 Ensuring fair keep selection ability impractically expensive. Contracts requesting keeps and keep providers First, keep providers will be required to need to be matched. An ideal system prove their holdings in a token native to the would enable price discovery, incentivizing system. Significant disruption of the network new providers to join if capacity is low, across should lead to a drop in the value of the to- different keep types. ken, incentivizing provider honesty, lest they This matching problem is a great fit for devalue their holdings. This scheme also pro- a market. Unfortunately, on-chain markets vides resistance to Sybil attacks— an active are a difficult problem, prone to complexity, attacker would need to obtain an outsize por- miner frontrunning, and orderbook manipula- tion of all tokens locked up by keep providers tion. A clever attacker could manipulate a Draft: 518f7b5fa4 - November 27, 2018
market, giving them an unfair advantage to key generation process and providing a large be chosen for a particular keep. Essentially, a surface for communication failure. two-sided market would expose the network to Fortunately, the Dfinity team has solved Sybil attacks. these issues with their random beacon design, In lieu of a market, we need a fair keep se- based on a concept they call threshold relay lection mechanism. [26]. 6.2.1 Random beacons 6.2.2 Threshold relay The best way to select providers for a new This work relies on the idea of threshold secret keep is with a fair coin toss. Unfortunately, sharing schemes—secret sharing schemes that Ethereum only supports deterministic func- retain confidentiality up to some threshold t of tions. Contracts that require a random num- honest actors. ber often rely on a trusted oracle. Threshold signatures are a related idea. A A system is only as decentralized as its most threshold signature is a signature across n par- centralized component. Relying on a trusted ties that requires some minimum t actively third party for such a core function of the participating to sign. It’s a similar idea to project isn’t an acceptable risk. ”multi-sig” as deployed in cryptocurrencies to- Instead, we can utilize our keep providers as day. a decentralized source of entropy. All staked Traditional multi-sig, however, requires a providers can be required to take part in the smart contract on the blockchain to validate random number generation process. each signature and release funds. Threshold There are a few design considerations for signature schemes actually require a threshold such a system: t to construct a signature at all, removing a layer of complexity and coordination between Providers can’t be allowed an unfair ad- parties. vantage over each other in the node selec- The use of threshold signatures means a tion process. number of participating signers in a signing Each block on the public chain will re- group can be unavailable, and the signature quire at least one random number of suf- will still succeed in the presence of t function- ficient size. Today’s Ethereum block time ing signers. This provides some of our bea- is 25 seconds, but that will likely change con’s required resilience in the face of failing significantly in the future. The RNG pro- or misbehaving nodes. cess needs to be fast enough to support If threshold signatures sound familiar, it much shorter block time, if necessary. might be because they’re a core functionality keeps provide. For example, a keep signing RNG needs to be resilient to node failure. a Bitcoin transaction does so using threshold Failure in production means no new keeps ECDSA. can be created, so resilience to partitions A threshold relay is a way to chain threshold between providers as well as against ac- signatures to create a random beacon. Par- tive denial of service attacks is desirable. ticipants in a threshold relay form threshold While not a hard system requirement, groups. These groups generate new public providing the Ethereum network with a keys that identify the group and correspond to trusted source of randomness will also be a newly generated threshold private key, split a great boon to other projects. across the participants. As providers join the network, they will Most distributed key generation schemes are form threshold groups. These groups will then too slow or prone to manipulation to be con- sign a piece of random data, initially provided sidered. Any scheme we choose should provide by early network contributors, to bootstrap good performance, regardless of the number of the relay. The resulting signature provides the participating providers. Instead, most gener- random data for the next iteration, which can ation schemes require rounds of communica- be verified by the rest of the network partici- tion between participants, slowing down the pants and rejected if invalid. Each iteration, a Draft: 518f7b5fa4 - November 27, 2018
Iterative threshold signatures for randomness on existing chains Registration: As providers join the network, they register with at least one threshold group Gi of all groups G, generating a share of the group’s private key, si . Threshold groups are capped at c members, and may intersect. Groups that have reached this maximum size publish their public key to the blockchain. We’ll designate such groups as Gregistered . Trusted setup: A trusted party posts a random value r0 to the blockchain as the beacon’s first output. Bootstrapping: mod(r0 , |Gregistered |) is used to select a registered threshold group, Gi , from Gregistered . Gi signs r0 and publishes the result, r1 = threshold(r0 , s0→t ) where s0→t is the minimal shares necessary for the group to produce a signature. Note that threshold(...) must be a deterministic signature scheme to avoid share withholding attacks leading to a biased out- put. Iteration: Each block published on the chain will include a signature from Gregistered of the random value ri . As the chain grows, the signing threshold groups will change based on provider availability. If any group is non-responsive up to its thresh- old t, the group is removed from Gregistered . Failure: Each iteration is an opportunity for a group to fail to gen- erate a valid signature. If a group Gi fails to sign the last iteration’s random value, Gi+1 will be used instead. new signing group is chosen by the previous it- 7 The result registry eration’s random value. As all groups sign the Keeps will offer a number of methods to pub- previous iteration’s value, if a signature that’s lish to the public blockchain. In the case where chosen is invalid, the signature from the next keeps publish to a smart contract provided by group in line can be chosen instead. the keep owner, coordination is simple. In uses Importantly, the threshold signature scheme that don’t have a natural contract to commu- needs to be deterministic to prevent individual nicate with, a result registry will be provided shareholders from biasing the signature out- as a default to simplify keep and owner coor- come in their favor. BLS signatures [27] have dination. been used in related work. 8 Applications 8.1 Dead man switch 6.2.3 Keep selection group A dead man switch is a device that is auto- Our threshold relay system will be composed matically activated in case its owner becomes of keep providers seeking to be chosen to back incapacitated. Keeps enable a particular kind a new keep, capturing the fees from that keep. of dead man switch- publishing a secret, under certain contract conditions. Each block will include a random signa- Examples of dead man switch applica- ture, published by the nominated keep selec- tions with keeps include automated inheri- tion group. Any keeps that require new nodes tance (“send my beneficiary my private key if will have their providers chosen randomly, us- I don’t check in quarterly”), arbitration with ing the beacon value from the last block. time limits (“if no decision is made in 10 In this way, we can ensure fair chances to blocks, publish a shared secret”), as well as all staked keep providers, keeping the cost of protection for leakers (“publish a key to these a Sybil attack high. insurance files if I don’t check in”). Draft: 518f7b5fa4 - November 27, 2018
8.2 Marketplaces for digital goods Other uses for such a service include second- factor authentication, where a contract can an- Buying and selling digital goods on public swer a challenge-response protocol based on blockchains today requires settling off-chain. rules on the blockchain. Keeps make marketplaces for digital goods, like audio and video files, straightforward. 8.5 Custodial wallets and cross-chain Without keeps, each transfer of a private trading digital good requires one or more hash-reveal constructions on-chain. More complex scenar- As a special case of a signing service, contracts ios that require escrow, arbitrators, and other can use keeps to generate their own cryptocur- parties who might need access to the trans- rency wallets, taking full custody of any re- fered digital good will need n2 on-chain trans- ceived funds. actions to maintain security. They also require For example, a contract can generate a Bit- each party to be online to participate. coin wallet, and sign Bitcoin transactions in Keeps obviate always-online requirements, response to receiving assets on the contract’s and simplify the hash-reveal protocol to access native blockchain. management. All keep access is auditable, and participants can have access to a keep with- 8.6 Encryption service for blockchain out viewing its contents, allowing further op- storage timization. Without an always-online requirement or Services like Filecoin [29] and Storj [30] are complex reveal protocols, keeps can efficiently being built to provide cheap, ubiquitous stor- support services like iTunes on the blockchain. age, accessible globally, via smart contracts and traditional storage interfaces. 8.3 Pseudorandomness oracle These services offer few privacy guarantees by default, leaving the onus of file encryption Since keeps can populate themselves with ran- on users. Keeps can provide a private bridge to dom data, they can act as pseudorandomness blockchain storage. By generating an AES key oracles, improving on currently popular meth- at keep initialization and providing off-chain ods [28]. sMPC and other secure keeps are a data access to the keep, smart contracts can good fit for decentralized lotteries and other use keeps to secure files stored on decentralized games of chance, as well as offering a build- services. ing block for other on-chain algorithms that require tamper-resistant pRNG. 8.7 Banking on public blockchains This capability is an important component of advanced keep uses, like decentralized sign- As more keep providers are developed, more ing. applications that once required a private blockchain can be built against public net- 8.4 Decentralized signing service works. Signing sMPC keep providers are able to sign Traditional finance offers many examples. messages, including blockchain transactions, Consider lending, a basic service provided by using a generated or provided private key. most banks. For the first time, contracts will be able There are a number of sensitive variables in- to assert their identity off-chain, without re- volved in the lending process. Borrower credit quiring the recipient’s awareness of blockchain scores are sensitive; risk assessment is highly state. competitive; the terms of a loan aren’t typi- Consider a decentralized signing service for cally made public. Bitcoin transactions. The service can partici- Keep providers that execute generic private pate in multi-signature transactions, only sign- smart contracts can protect scores and the ing transactions that follow a strict set of rules, risk assessment process, while maintaining au- including daily spending limits and recipient ditability and all other benefits of a public whitelists. blockchain. Draft: 518f7b5fa4 - November 27, 2018
References tracts. https://plasma.io/plasma.pdf Accessed: 2017-08-16. [1] Stan Higgins. Bitcoin’s privacy gets ’failing grade’ in 2016 threat re- [12] Commitment scheme - Wikipedia. port. https://www.coindesk.com/ https://en.wikipedia.org/wiki/ bitcoins-privacy-2016-threat-report/. Commitment_scheme. Accessed: 2017-09- Accessed: 2017-08-16. 02. [2] Ethereum StackExchange private info [13] Quorum. https://github.com/ on ethereum. https://ethereum. jpmorganchase/quorum. Accessed: stackexchange.com/questions/2624/ 2017-08-16. private-info-on-ethereum. Accessed: [14] The Coco Framework: Technical 2017-08-16. Overview. https://aka.ms/cocopaper. [3] Greg Maxwell. Confidential trans- Accessed: 2017-08-21. actions. https://people.xiph.org/ [15] Shamir’s secret sharing. https: ~greg/confidential_values.txt. //en.wikipedia.org/wiki/Shamir% [4] The Elements Project confi- 27s_Secret_Sharing. Accessed: 2017- dential transactions. https: 08-16. //elementsproject.org/elements/ [16] Andrew C Yao. Protocols for secure com- confidential-transactions/. Ac- putations. In Foundations of Computer cessed: 2017-08-16. Science, 1982. SFCS’08. 23rd Annual Symposium on, pages 160–164. IEEE, [5] Eli Ben Sasson, Alessandro Chiesa, 1982. Christina Garman, Matthew Green, Ian Miers, Eran Tromer, and Madars Virza. [17] Multiparty computation with spdz online Zerocash: Decentralized anonymous pay- phase and mascot offline phase. https: ments from bitcoin. In Security and Pri- //github.com/bristolcrypto/SPDZ-2. vacy (SP), 2014 IEEE Symposium on, Accessed: 2017-08-16. pages 459–474. IEEE, 2014. [18] Ahmed Kosba, Andrew Miller, Elaine [6] Zcash: All coins are created equal. Shi, Zikai Wen, and Charalampos Pa- https://z.cash/. Accessed: 2017-08-16. pamanthou. Hawk: The blockchain model of cryptography and privacy- [7] Secret sharing DAOs: crypto 2.0. https: preserving smart contracts. In Se- //blog.ethereum.org/2014/12/26/ curity and Privacy (SP), 2016 IEEE secret-sharing-daos-crypto-2-0/. Symposium on, pages 839–858. IEEE, Accessed: 2017-08-16. 2016. http://download.xuebalib.com/ [8] Vitalik Buterin. Privacy on xuebalib.com.27267.pdf. the blockchain. https://blog. [19] Guy Zyskind, Oz Nathan, and Alex ethereum.org/2016/01/15/ Pentland. Enigma: Decentralized com- privacy-on-the-blockchain/, 2016. putation platform with guaranteed pri- Accessed: 2017-08-16. vacy. arXiv preprint arXiv:1506.03471, [9] Joseph Poon and Thaddeus Dryja. 2015. https://arxiv.org/pdf/1506. The bitcoin lightning network: Scal- 03471.pdf. able off-chain instant payments. [20] Atle Mauland. Realizing distributed 2016. https://lightning.network/ rsa using secure multiparty compu- lightning-network-paper.pdf Ac- tations. Master’s thesis, Institutt for cessed: 2017-08-16, Draft Version 0.5.9.2. telematikk, 2009. https://brage. [10] On sharding blockchains. https: bibsys.no/xmlui/bitstream/handle/ //github.com/ethereum/wiki/wiki/ 11250/261858/347875_FULLTEXT01.pdf Sharding-FAQ. Accessed: 2017-08-16. Accessed: 2017-08-20. [11] Joseph Poon and Vitalik Buterin. [21] Rosario Gennaro, Steven Goldfeder, and Plasma: Scalable autonomous smart con- Arvind Narayanan. Threshold-optimal Draft: 518f7b5fa4 - November 27, 2018
dsa/ecdsa signatures and an application stackexchange.com/a/207. Accessed: to bitcoin wallet security. In Interna- 2017-08-16. tional Conference on Applied Cryptogra- [29] Filecoin: A Decentralized Storage Net- phy and Network Security, pages 156–174. work. https://filecoin.io/filecoin. Springer, 2016. https://eprint.iacr. pdf. Accessed: 2017-08-16. org/2016/013.pdf. [30] Storj: A Peer-to-Peer Cloud Storage Net- [22] Jan Henrik Ziegeldorf, Fred Gross- work. https://storj.io/storj.pdf. mann, Martin Henze, Nicolas Inden, Accessed: 2017-08-16. and Klaus Wehrle. Coinparty: Secure multi-party mixing of bitcoins. In Proceedings of the 5th ACM Confer- ence on Data and Application Security and Privacy, pages 75–86. ACM, 2015. https://www.comsys.rwth-aachen. de/fileadmin/papers/2015/ 2015-ziegeldorf-codaspy-coinparty. pdf. [23] Viff, the virtual ideal functionality frame- work. http://viff.dk/. Accessed: 2017- 08-16. [24] Marcin Andrychowicz, Stefan Dziem- bowski, Daniel Malinowski, and Lukasz Mazurek. Secure multiparty computa- tions on bitcoin. In Security and Privacy (SP), 2014 IEEE Symposium on, pages 443–458. IEEE, 2014. https://eprint. iacr.org/2013/784.pdf. [25] Charles Noyes. Blockchain multi- party computation markets at scale. https://www.overleaf.com/articles/ blockchain-multiparty-computation-markets-at-scale/ mwjgmsyybxvw/viewer.pdf Accessed: 2017-08-16. [26] Threshold relay: how to achieve near- instant finality in public blockchains using a vrf. https://dfinity.network/ pdfs/viewer.html?file=../library/ threshold-relay-blockchain-stanford. pdf. Accessed: 2017-09-02. [27] Dan Boneh, Ben Lynn, and Hovav Shacham. Short signatures from the weil pairing. Advances in Cryptol- ogy—ASIACRYPT 2001, pages 514–532, 2001. https://www.iacr.org/archive/ asiacrypt2001/22480516.pdf Ac- cessed: 2017-09-06. [28] Ethereum StackExchange: How can I se- curely generate a random number in my smart contract? https://ethereum. Draft: 518f7b5fa4 - November 27, 2018