DOCSLIB.ORG

Downloads the Full Hash-Chain Representing the Decisions of the Shard from the Beginning of Time, and Re-Executes All the Transactions in Sequence

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Downloads the Full Hash-Chain Representing the Decisions of the Shard from the Beginning of Time, and Re-Executes All the Transactions in Sequence Scaling Distributed Ledgers and Privacy-Preserving Applications Alberto Sonnino A dissertation submitted in partial fulfillment of the requirements for the degree of Doctor of Philosophy of University College London. arXiv:2102.12273v1 [cs.CR] 24 Feb 2021 Department of Computer Science University College London February 25, 2021 2 I, Alberto Sonnino, confirm that the work presented in this thesis is my own. Where information has been derived from other sources, I confirm that this has been indicated in the work. Abstract This thesis proposes techniques aiming to make blockchain technologies and smart contract platforms practical by improving their scalability, latency, and privacy. This thesis starts by presenting the design and implementation of Chainspace, a distributed ledger that supports user defined smart contracts and execute user-supplied transac- tions on their objects. The correct execution of smart contract transactions is publicly verifiable. Chainspace is scalable by sharding state; it is secure against subsets of nodes trying to compromise its integrity or availability properties through Byzantine Fault Tolerance (BFT). This thesis also introduces a family of replay attacks against sharded distributed ledgers targeting cross-shard consensus protocols; they allow an attacker, with network access only, to double-spend resources with minimal efforts. We then build Byzcuit, a new cross-shard consensus protocol that is immune to those attacks and that is tailored to run at the heart of Chainspace. Next, we propose FastPay, a high-integrity settlement system for pre-funded payments that can be used as a financial side-infrastructure for Chainspace to support low-latency retail payments. This settlement system is based on Byzantine Consistent Broadcast as its core primitive, foregoing the expenses of full atomic commit channels (consen- sus). The resulting system has extremely low-latency for both confirmation and payment finality. Finally, this thesis proposes Coconut, a selective disclosure creden- tial scheme supporting distributed threshold issuance, public and private attributes, re-randomization, and multiple unlinkable selective attribute revelations. It ensures authenticity and availability even when a subset of credential issuing authorities are malicious or offline, and natively integrates with Chainspace to enable a number of scalable privacy-preserving applications. Impact Statement The work in this thesis can inform the design of new and existing projects that implement distributed ledgers, smart contract platforms or applications, in order to increase their scalability, security, and privacy. Chainspace (Chapter 3) and Co- conut (Chapter 6) are used as part of DECODE (DEcentralized Citizen-owned Data Ecosystems) [1], a European project with a digital democracy pilot in Barcelona implementing a decentralized petitions platform. Chainspace was also commer- cialized in a company (chainspace.io) co-founded by the author of this thesis, and the team was acquired by Facebook. Coconut was also integrated into Cos- mos SDK [2] and commercialized in a company (Nym [3]) aiming to provide an open-ended anonymous overlay network that disguise patterns in internet traffic; it uses the scheme described in Chapter 6 as anonymous authentication credentials to enable privacy-enhanced data transfer and decentralized identity. Byzcuit and the work done on replay attacks against sharded distributed ledgers (Chapter 4) have profound impact on the security of recently proposed systems such as Omniledger [4] and RapidChain [5]; these systems were presented at top security conferences and form the basis of numerous start-ups and open-source projects such as Harmony [6]. Finally, the content of this thesis has been presented on multiple occasions, both at academic venues and industry conferences; some of its chapters have been published at top-tier security conferences. It produced multiple tools and open-source software, and is freely available online. Acknowledgements This work would not have been possible without my primary supervisor George Danezis, who helped me throughout the past few years of research, and to whom I wish to express my profound gratitude. Special thanks to my secondary super- visors Jens Groth and Ioannis Psaras for their unwavering support and generous encouragement, and to my close collaborators, Mustafa Al-Bassam and Shehar Bano, who have been the source of many fruitful discussions. I have been privileged to have had the opportunity to work with many brilliant and helpful people around the world. Specifically, I thank all my co-authors (in alphabetic order) Christos Andrikos, Sarah Azouvi, Lejla Batina, Mathieu Baudet, Vitalik Buterin, Avery Ching, Lukasz Chmielewski, Andrey Chursin, Dave Hrycyszyn, Ismail Khoffi, Michał Krol,´ Liran Lerman, Zekun Li, Dahlia Malkhi, Vasilis Mavroudis, Sarah Meiklejohn, Patrick McCorry, Kostas Papagiannopoulos, Dmitri Perelman, Guilherme Perin, Giorgos Rassias, Etienne Riviere,` Argyrios Tasiopoulos, Lixia Zhang, and Zhiyi Zhang. I would also like to thank Ramsey Khoury, my other co-founder at chainspace.io not mentioned above, and all my other former colleagues at chainspace.io: Penny Andrews, Andy Bennett, Stuart Chinery, Jer´ emy´ Letang, and Lola Oyelayo-Pearson. I also thank everyone at Facebook Novi, specifically David Marcus, James Evering- ham, Christian Catalini, Kevin Weil, Ben Maurer, Morgan Beller, and Evan Cheng for providing a supportive working environment. Finally, I would like to thank the European Commission for funding my research with a PhD scholarship, and all my friends and family for their continuous support and encouragement. Contents 1 Introduction 14 1.1 Problem Statement . 14 1.2 Overview . 16 1.3 Dissertation Organization and Contributions . 18 1.4 Additional Work . 21 1.5 Work Done in Collaboration . 22 2 Background and Related Work 24 2.1 Terminology and Assumptions . 24 2.2 Consensus in the Age of Blockchains . 27 2.2.1 Classical Consensus . 28 2.2.2 Elected Leader Consensus . 31 2.2.3 Hybrid Consensus: Single Committee . 34 2.2.4 Hybrid Consensus: Multiple Committees . 37 2.3 Cross-Shard Consensus Protocols . 39 2.3.1 Two-Phases Atomic Commit Protocols . 39 2.3.2 Mutex-Based Consensus Protocols . 40 2.4 Sybil Resistance and Committee Management . 41 2.4.1 Sybil Resistance . 41 2.4.2 Committee Reconfiguration . 44 2.5 Selective Disclosure Credentials . 45 2.5.1 Cryptographic Building Blocks . 46 2.5.2 The Predecessors of Coconut . 47 Contents 7 2.6 Blockchains Data Structures . 49 2.7 Chapter Summary . 50 3 Chainspace: A Sharded Smart Contracts Platform 51 3.1 Overview . 53 3.1.1 Data Model: Objects, Contracts, Transactions. 53 3.1.2 System Design, Threat Model and Security Properties . 56 3.2 The Chainspace Application Interface . 58 3.3 The Chainspace System Design . 62 3.3.1 High-Integrity Data Structures . 62 3.3.2 Distributed Architecture & Consensus . 65 3.3.3 Cross-Shard Consensus Protocol . 67 3.4 Security and Correctness . 68 3.4.1 Auditability . 68 3.5 System and Applications Smart Contracts . 70 3.5.1 System Contracts . 70 3.5.2 Application Level Smart Contracts . 72 3.6 Smart Contract Evaluation . 74 3.7 Limitations . 77 3.8 Comparison with Related Work . 78 3.9 Chapter Summary . 79 4 Replay Attacks and Defenses Against Cross-shard Consensus 80 4.1 Attack Overview . 83 4.2 Shard-led Cross-Shard Consensus Protocol . 85 4.2.1 S-BAC Overview . 85 4.2.2 Message Recording . 87 4.2.3 Attacks on the First Phase of S-BAC . 88 4.2.4 Attacks on the Second Phase of S-BAC . 89 4.2.5 Real-world Impact . 91 4.3 Client-led Cross-shard Consensus Protocol . 92 Contents 8 4.3.1 Atomix Overview . 92 4.3.2 Message Recording . 93 4.3.3 Attacks on the First Phase of Atomix . 94 4.3.4 Attacks on the Second Phase of Atomix . 95 4.3.5 Real-world Impact . 97 4.4 Eliciting Messages to Replay . 98 4.4.1 Shard-led Cross-Shard Consensus . 98 4.4.2 Client-led Cross-Shard Consensus . 99 4.5 Defenses Against Replay Attacks . 100 4.6 The Byzcuit Atomic Commit Protocol . 100 4.6.1 Byzcuit Protocol Design . 101 4.6.2 Security against Replay Attacks . 105 4.6.3 Byzcuit Security & Correctness . 108 4.7 Implementation & Evaluation . 110 4.8 Chapter Summary . 113 5 FastPay: High-Performance Byzantine Fault Tolerant Settlement 114 5.1 Background . 117 5.2 Overview . 118 5.2.1 Participants . 118 5.2.2 Accounts & Actions . 119 5.2.3 Protocol Messages . 119 5.2.4 Security Properties & Threat Model . 120 5.3 The FastPay Protocol . 121 5.3.1 Transferring Funds within FastPay . 123 5.3.2 Sharding authorities . 127 5.3.3 Interfacing with the Primary . 128 5.3.4 State Recovery & Auditing . 130 5.3.5 Correct Users & Client Implementation . 131 5.4 Security Analysis . 131 5.4.1 Safety . 132 Contents 9 5.4.2 Liveness . 135 5.4.3 Performance under Byzantine Failures . 137 5.4.4 Worst-Case Efficiency of FastPay Clients . 138 5.5 Implementation . 138 5.6 Evaluation . 139 5.6.1 Microbenchmarks . 139 5.6.2 Throughput . 140 5.6.3 Latency . 144 5.7 Limitations & Future Work . 147 5.8 Comparison with Related Work . 149 5.9 Chapter Summary . 151 6 Coconut: Threshold Issuance Selective Disclosure Credentials 153 6.1 Overview . 157 6.2 The Coconut Construction . 159 6.2.1 Notations & Assumptions . 159 6.2.2 Scheme Definitions and Security Properties . 160 6.2.3 Foundations of Coconut . 161 6.2.4 The Coconut Threshold Credential Scheme . 162 6.2.5 Multi-Attribute Credentials . 168 6.3 Sketch of Security Proofs . 171 6.4 Implementation . 172 6.4.1 The Coconut Smart Contract Library . 173 6.4.2 Ethereum Smart Contract Library . 174 6.4.3 Deeper Blockchain Integration . 175 6.5 Applications . 176 6.5.1 Coin Tumbler . 177 6.5.2 Privacy-Preserving Petition . 180 6.5.3 Censorship-Resistant Distribution of Proxies .
Load more

Recommended publications
  • IPFS and Friends: a Qualitative Comparison of Next Generation Peer-To-Peer Data Networks Erik Daniel and Florian Tschorsch
    1 IPFS and Friends: A Qualitative Comparison of Next Generation Peer-to-Peer Data Networks Erik Daniel and Florian Tschorsch Abstract—Decentralized, distributed storage offers a way to types of files [1]. Napster and Gnutella marked the beginning reduce the impact of data silos as often fostered by centralized and were followed by many other P2P networks focusing on cloud storage. While the intentions of this trend are not new, the specialized application areas or novel network structures. For topic gained traction due to technological advancements, most notably blockchain networks. As a consequence, we observe that example, Freenet [2] realizes anonymous storage and retrieval. a new generation of peer-to-peer data networks emerges. In this Chord [3], CAN [4], and Pastry [5] provide protocols to survey paper, we therefore provide a technical overview of the maintain a structured overlay network topology. In particular, next generation data networks. We use select data networks to BitTorrent [6] received a lot of attention from both users and introduce general concepts and to emphasize new developments. the research community. BitTorrent introduced an incentive Specifically, we provide a deeper outline of the Interplanetary File System and a general overview of Swarm, the Hypercore Pro- mechanism to achieve Pareto efficiency, trying to improve tocol, SAFE, Storj, and Arweave. We identify common building network utilization achieving a higher level of robustness. We blocks and provide a qualitative comparison. From the overview, consider networks such as Napster, Gnutella, Freenet, BitTor- we derive future challenges and research goals concerning data rent, and many more as first generation P2P data networks, networks.
    [Show full text]
  • Lab 5: Bittorrent Client Implementation
    Lab 5: BitTorrent Client Implementation Due: Nov. 30th at 11:59 PM Milestone: Nov. 19th during Lab Overview In this lab, you and your lab parterner will develop a basic BitTorrent client that can, at minimal, exchange a file between multiple peers, and at best, function as a full feature BitTorrent Client. The programming in this assignment will be in C requiring standard sockets, and thus you will not need to have root access. You should be able to develop your code on any CS lab machine or your personal machine, but all code will be tested on the CS lab. Deliverable Your submission should minimally include the following programs and files: • REDME • Makefile • bencode.c|h • bt lib.c|h • bt setup.c|h • bt client • client trace.[n].log • sample torrent.torrent Your README file should contain a short header containing your name, username, and the assignment title. The README should additionally contain a short description of your code, tasks accomplished, and how to compile, execute, and interpret the output of your programs. Your README should also contain a list of all submitted files and code and the functionality implemented in different code files. This is a large assignment, and this will greatly aid in grading. As always, if there are any short answer questions in this lab write-up, you should provide well marked answers in the README, as well as indicate that you’ve completed any of the extra credit (so that I don’t forget to grade it). Milestones The entire assignment will be submitted and graded, but your group will also hold a milestone meeting to receive feedback on your current implementation.
    [Show full text]
  • A Decentralized Cloud Storage Network Framework
    Storj: A Decentralized Cloud Storage Network Framework Storj Labs, Inc. October 30, 2018 v3.0 https://github.com/storj/whitepaper 2 Copyright © 2018 Storj Labs, Inc. and Subsidiaries This work is licensed under a Creative Commons Attribution-ShareAlike 3.0 license (CC BY-SA 3.0). All product names, logos, and brands used or cited in this document are property of their respective own- ers. All company, product, and service names used herein are for identification purposes only. Use of these names, logos, and brands does not imply endorsement. Contents 0.1 Abstract 6 0.2 Contributors 6 1 Introduction ...................................................7 2 Storj design constraints .......................................9 2.1 Security and privacy 9 2.2 Decentralization 9 2.3 Marketplace and economics 10 2.4 Amazon S3 compatibility 12 2.5 Durability, device failure, and churn 12 2.6 Latency 13 2.7 Bandwidth 14 2.8 Object size 15 2.9 Byzantine fault tolerance 15 2.10 Coordination avoidance 16 3 Framework ................................................... 18 3.1 Framework overview 18 3.2 Storage nodes 19 3.3 Peer-to-peer communication and discovery 19 3.4 Redundancy 19 3.5 Metadata 23 3.6 Encryption 24 3.7 Audits and reputation 25 3.8 Data repair 25 3.9 Payments 26 4 4 Concrete implementation .................................... 27 4.1 Definitions 27 4.2 Peer classes 30 4.3 Storage node 31 4.4 Node identity 32 4.5 Peer-to-peer communication 33 4.6 Node discovery 33 4.7 Redundancy 35 4.8 Structured file storage 36 4.9 Metadata 39 4.10 Satellite 41 4.11 Encryption 42 4.12 Authorization 43 4.13 Audits 44 4.14 Data repair 45 4.15 Storage node reputation 47 4.16 Payments 49 4.17 Bandwidth allocation 50 4.18 Satellite reputation 53 4.19 Garbage collection 53 4.20 Uplink 54 4.21 Quality control and branding 55 5 Walkthroughs ...............................................
    [Show full text]
  • How to Invest in Filecoin
    How to Invest in Filecoin Part I: Preparing to Invest Filecoin investments will be made on CoinList (coinlist.co), a US-based funding platform that connects investors to promising early-stage token sales. Created by Protocol Labs in partnership with AngelList, CoinList simplifies the token sale process and implements robust legal frameworks for token sales in the U.S. Before the sale begins, you will need to complete several preparation steps. Note that some steps include wait time of several days. For this reason, we recommend getting started as soon as possible and working in parallel while waiting for other steps to be reviewed or confirmed. Step 1: Create a CoinList account (5 min) Visit https://coinlist.co. Sign in with your AngelList account, or create a new account if needed. Step 2: Become a US accredited investor through AngelList (30 min + 1-3 day review) All token investors will need to meet US accredited investor requirements. Non-US investors can invest, but must meet the same requirements. You will be prompted to submit accreditation evidence. Step 3: Submit information for KYC/AML checks (15 min + instant review if no issues) You will be prompted to submit the details required for KYC/AML (Know Your Customer/Anti-Money Laundering) checks as soon as accreditation evidence has been submitted. You do not need to wait until accreditation review is complete. Step 4: Transfer funds to relevant accounts (10min + 1-5 day wait) You can invest with your choice of the following currencies: US Dollars, Bitcoin, Ether, and Zcash. To invest using US Dollars: Go to https://coinlist.co/settings/wallet.
    [Show full text]
  • Filecoin Token Sale Economics
    Filecoin Token Sale Economics This document describes various aspects of the Filecoin Network, the Filecoin Token Sale, and the economics of both. Any updates to this document will be posted on the CoinList webpage for the Filecoin Token Sale: https://coinlist.co/currencies/filecoin. LEGAL DISCLAIMER: This document contains forward-looking statements, ​ ​ ​ ​ ​ subject to risks and uncertainties that could cause actual results to differ materially. 1. Token Allocation The Filecoin Token will be distributed to the 4 major participating groups in the Filecoin Network. This allocation is written into the protocol itself and the Filecoin blockchain’s Genesis block. Each group is critical to the network’s creation, development, growth, and maintenance: ● 70% to Filecoin Miners (Mining block reward) ​ For providing data storage service, maintaining the blockchain, distributing data, running contracts, and more. ● 15% to Protocol Labs (Genesis allocation, 6-year linear vesting) ​ For research, engineering, deployment, business development, marketing, distribution, and more. ● 10% to Investors (Genesis allocation, 6 month to 3 year linear vesting) ​ ​ For funding network development, business development, partnerships, support, and more. ● 5% to Filecoin Foundation (Genesis allocation, 6-year linear vesting) ​ ​ For long-term network governance, partner support, academic grants, public works, community building, et cetera. 2. The Filecoin Token Sale Fundraising. Protocol Labs requires significant funding to develop, launch, and grow the Filecoin network. We ​ ​ ​ must develop all the software required: the mining software, the client software, user interfaces and apps, network infrastructure and monitoring, software that third-party wallets and exchanges need to support Filecoin, integrations with other data storage software, tooling for web applications and dapps to use Filecoin, and much more.
    [Show full text]
  • The Book of Swarm Storage and Communication Infrastructure for Self-Sovereign Digital Society Back-End Stack for the Decentralised Web
    the book of Swarm storage and communication infrastructure for self-sovereign digital society back-end stack for the decentralised web Viktor Trón v1.0 pre-release 7 - worked on November 17, 2020 the swarm is headed toward us Satoshi Nakamoto ii CONTENTS Prolegomena xi Acknowledgments xii i prelude 1 the evolution2 1.1 Historical context 2 1.1.1 Web 1.02 1.1.2 Web 2.03 1.1.3 Peer-to-peer networks 6 1.1.4 The economics of BitTorrent and its limits 7 1.1.5 Towards Web 3.08 1.2 Fair data economy 12 1.2.1 The current state of the data economy 12 1.2.2 The current state and issues of data sovereignty 13 1.2.3 Towards self-sovereign data 15 1.2.4 Artificial intelligence and self-sovereign data 16 1.2.5 Collective information 17 1.3 The vision 18 1.3.1 Values 18 1.3.2 Design principles 19 1.3.3 Objectives 19 1.3.4 Impact areas 20 1.3.5 The future 21 ii design and architecture 2 network 25 2.1 Topology and routing 25 2.1.1 Requirements for underlay network 25 2.1.2 Overlay addressing 26 2.1.3 Kademlia routing 27 2.1.4 Bootstrapping and maintaining Kademlia topology 32 2.2 Swarm storage 35 2.2.1 Distributed immutable store for chunks 35 2.2.2 Content addressed chunks 38 2.2.3 Single-owner chunks 41 2.2.4 Chunk encryption 42 2.2.5 Redundancy by replication 43 2.3 Push and pull: chunk retrieval and syncing 47 iii 2.3.1 Retrieval 47 2.3.2 Push syncing 51 2.3.3 Pull syncing 53 2.3.4 Light nodes 55 3 incentives 57 3.1 Sharing bandwidth 58 3.1.1 Incentives for serving and relaying 58 3.1.2 Pricing protocol for chunk retrieval 59 3.1.3 Incentivising push-syncing
    [Show full text]
  • Sok: Tools for Game Theoretic Models of Security for Cryptocurrencies
    SoK: Tools for Game Theoretic Models of Security for Cryptocurrencies Sarah Azouvi Alexander Hicks Protocol Labs University College London University College London Abstract form of mining rewards, suggesting that they could be prop- erly aligned and avoid traditional failures. Unfortunately, Cryptocurrencies have garnered much attention in recent many attacks related to incentives have nonetheless been years, both from the academic community and industry. One found for many cryptocurrencies [45, 46, 103], due to the interesting aspect of cryptocurrencies is their explicit consid- use of lacking models. While many papers aim to consider eration of incentives at the protocol level, which has motivated both standard security and game theoretic guarantees, the vast a large body of work, yet many open problems still exist and majority end up considering them separately despite their current systems rarely deal with incentive related problems relation in practice. well. This issue arises due to the gap between Cryptography Here, we consider the ways in which models in Cryptog- and Distributed Systems security, which deals with traditional raphy and Distributed Systems (DS) can explicitly consider security problems that ignore the explicit consideration of in- game theoretic properties and incorporated into a system, centives, and Game Theory, which deals best with situations looking at requirements based on existing cryptocurrencies. involving incentives. With this work, we offer a systemati- zation of the work that relates to this problem, considering papers that blend Game Theory with Cryptography or Dis- Methodology tributed systems. This gives an overview of the available tools, and we look at their (potential) use in practice, in the context As we are covering a topic that incorporates many different of existing blockchain based systems that have been proposed fields coming up with an extensive list of papers would have or implemented.
    [Show full text]
  • A Privacy-Preserving Decentralized Storage with Payments Based on a Blockchain
    A Privacy-preserving Decentralized Storage with Payments Based on a Blockchain Dissertation zur Erlangung des Doktorgrades Dr. rer. nat. der Fakultat¨ fur¨ Ingenieurwissenschaften, Informatik und Psychologie der Universitat¨ Ulm Henning Johannes Gustav Kopp aus Villingen-Schwenningen 2018 Institut f¨urVerteilte Systeme Universit¨atUlm, Deutschland Amtierender Dekan: Prof. Maurits Ortmanns Gutachter: Prof. Frank Kargl Gutachter: Prof. Frederik Armknecht Tag der Promotion: 20.12.2018 Summary Recently, the paradigm of cloud storage has seen wide acceptance in industry and for personal use. One of its core principles is to outsource storage, such that users can be billed flexibly by their actual demand. However, outsourcing storage such as private data or business secrets leads to privacy problems, as control over the data is lost to the storage provider. This is intensified by the fact that often privacy is considered only as an afterthought in these systems and not integrated into the design from the beginning. Privacy-preserving alternatives to these centralized cloud storage providers are peer-to-peer systems like Freenet or GNUnet. In these systems, participants can donate storage to other users of the system. Privacy plays a vital role in these systems, as, e. g., participants are unable to access data of other users if they are not authorized to do so, even if the data of the other users resides on their own hard disk. However, these decentralized systems suffer from limited contribution due to a lack of incentives to participate. Naively enhancing these systems with the possibility of payments such that storage providers can earn money, infringes privacy, since tracing of payment flows provides links between users and their storage providers.
    [Show full text]
  • Blockchain and The
    NOTES ACKNOWLEDGMENTS INDEX Notes Introduction 1. The manifesto dates back to 1988. See Timothy May, “The Crypto Anarchist Manifesto” (1992), https:// www . activism . net / cypherpunk / crypto - anarchy . html. 2. Ibid. 3. Ibid. 4. Ibid. 5. Ibid. 6. Timothy May, “Crypto Anarchy and Virtual Communities” (1994), http:// groups . csail . mit . edu / mac / classes / 6 . 805 / articles / crypto / cypherpunks / may - virtual - comm . html. 7. Ibid. 8. For example, as we wi ll describe in more detail in Chapter 1, the Bitcoin blockchain is currently stored on over 6,000 computers in eighty- nine jurisdictions. See “Global Bitcoin Node Distribution,” Bitnodes, 21 . co, https:// bitnodes . 21 . co / . Another large blockchain- based network, Ethereum, has over 12,000 nodes, also scattered across the globe. See Ethernodes, https:// www . ethernodes . org / network / 1. 9. See note 8. 10. Some blockchains are not publicly accessible (for more on this, see Chapter 1). These blockchains are referred to as “private blockchains” and are not the focus of this book. 11. See Chapter 1. 12. The Eu ro pean Securities and Market Authority, “Discussion Paper: The Dis- tributed Ledger Technology Applied to Securities Markets,” ESMA / 2016 / 773, June 2, 2016: at 17, https:// www . esma . europa . eu / sites / default / files / library / 2016 - 773 _ dp _ dlt . pdf. 213 214 NOTES TO PAGES 5–13 13. The phenomena of order without law also has been described in other con- texts, most notably by Robert Ellickson in his seminal work Order without Law (Cambridge, MA: Harvard University Press, 1994). 14. Joel Reidenberg has used the term “lex informatica” to describe rules imple- mented by centralized operators online.
    [Show full text]
  • Proofs of Replication Are Also Relevant in the Private-Verifier Setting of Proofs of Data Replication
    PoReps: Proofs of Space on Useful Data Ben Fisch Stanford University, Protocol Labs Abstract A proof-of-replication (PoRep) is an interactive proof system in which a prover defends a publicly verifiable claim that it is dedicating unique resources to storing one or more retrievable replicas of a data file. In this sense a PoRep is both a proof of space (PoS) and a proof of retrievability (PoR). This paper establishes a foundation for PoReps, exploring both their capabilities and their limitations. While PoReps may unconditionally demonstrate possession of data, they fundamentally cannot guarantee that the data is stored redundantly. Furthermore, as PoReps are proofs of space, they must rely either on rational time/space tradeoffs or timing bounds on the online prover's runtime. We introduce a rational security notion for PoReps called -rational replication based on the notion of an -Nash equilibrium, which captures the property that a server does not gain any significant advantage by storing its data in any other (non-redundant) format. We apply our definitions to formally analyze two recently proposed PoRep constructions based on verifiable delay functions and depth robust graphs. Lastly, we reflect on a notable application of PoReps|its unique suitability as a Nakamoto consensus mechanism that replaces proof-of-work with PoReps on real data, simultaneously incentivizing and subsidizing the cost of file storage. 1 Introduction A proof-of-replication (PoRep) builds on the two prior concepts of proofs-of-retrievability (PoR) [30] and proofs-of-space (PoS) [24]. In the former a prover demonstrates that it can retrieve a file and in the latter the prover demonstrates that it is using some minimum amount of space to store information.
    [Show full text]
  • Convergence-2020.Pdf
    A universal architecture to anonymize any application or protocol and turn it into an independent decentralized p2p network inside browsers and servers, with browsers acting as servers CONVERGENCE 1. Description This proposal is a complete redesign of our initial Convergence proposal from 2015 (http://www.peersm.com/Convergence.pdf ) which was intended as a research study for an EU call By “Convergence” in this proposal we don’t refer to a specific network or node but to methods using the Convergence principles 1.1 Background and rationale The initial Convergence proposal was written based on the observation that we must invent one network/system per need if we want to evade big data centralization and protect privacy/anonymity: to browse, to chat, to email, to exchange files, to do social networking or cooperative work, to do crypto currency, to protect the users from their connected objects, to handle peer identities. So it did envision the support of any type of applications and protocols on top of a secure anonymization system, inside browsers and servers The first part is very exactly what IPFS did, including the crypto currency concept in our proposal to sustain the network (Filecoin) But IPFS is not at all designed for privacy, the IPFS team knows that they will have to address the issue but it’s not even part of their roadmap And IPFS adoption is not for all protocols, many other networks will not use it and lack privacy too That’s why we are proposing the Convergence concepts, which are still very up to date, with a major novelty:
    [Show full text]
  • Initial Coin Offerings
    Initial Coin Offerings: Financing Growth with Cryptocurrency Token Sales Sabrina T. Howell, Marina Niessner, and David Yermack⇤ August, 2018 Abstract Initial coin offerings (ICOs) are a significant innovation in entrepreneurial finance. The sale of a blockchain-based digital token associated with a specific platform or venture is a new financing instrument with some parallels to IPOs, venture capital, and pre-sale crowdfunding. We examine the relationship between issuer characteristics and measures of success, with a focus on liquidity, using 453 ICOs that collectively raise $5.7 billion. We also employ proprietary transaction data in a case study of Filecoin, one of the most successful ICOs. We find that liquidity and trading volume are higher when issuers offer voluntary disclosure, credibly commit to the project, and signal quality. s s ss s ss ss ss s ⇤NYU Stern and NBER; AQR; NYU Stern, ECGI and NBER. Email: [email protected]. For helpful comments, we are grateful to Yakov Amihud, Bruno Biais, Will Cong, Darrell Duffie, Alex Edmans, seminar participants at the OECD Paris Workshop on Digital Financial Assets, Erasmus University, the Swedish House of Finance, the Munich Crowdfunding Symposium, the University of Adelaide, Deakin University, Melbourne University, Monash University, LaTrobe University, and the University of Western Australia. We thank Protocol Labs and particularly Evan Miyazono and Juan Benet for providing data. Sabrina Howell thanks the Kauffman Foundation for financial support. We are also grateful to all of our research assistants, especially Jae Hyung (Fred) Kim. Part of this paper was written while David Yermack was a visiting professor at Erasmus University Rotterdam.
    [Show full text]