Coins, Clubs, and Crowds: Coins, Clubs, and Crowds: Scaling and - PowerPoint PPT Presentation

Problem: Secure Public Randomness Vietnam War Lotteries (1969)

RandHound/RandHerd “Scalable Bias-Resistant Distributed Randomness” [IEEE Security & Privacy ‘17] ● Standard t-of-n TSS group 0 threshold model ● Efficient, scales to collective randomness thousands of parties CL CL (c,r 0 ) (c,r) ● Compatible with (c,r 1 ) (c,r 2 ) GL GL GL GL ByzCoin, OmniLedger blockchains TSS group 1 TSS group 2

The Chicken-and-Egg Problem More scalable if we could use smaller groups… but need randomness to sample them securely! ● Sharding needs randomness needs sharding Addressed by RandHound , RandHerd protocols ● Scalable Bias-Resistant Distributed Randomness [IEEE S&P ‘17] ● RandHound : bootstrap protocol, O( n log n ) efficiency ● RandHerd : repeating beacon, O(log n ) cost/node/round

The League of Entropy Public randomness beacon based on RandHerd ● Launched by EFPL-DEDIS, Cloudflare, Kudelski, University of Chile, Protocol Labs ● Simplifications, BLS instead of Schnorr signing

Future: Function Scaling How to manage the growing complexity of decentralized architectures as they evolve? ● Analogy: functional units in modern CPUs

PROTEAN: Functional Scaling Rethinking General-Purpose Decentralized Computing [HotOS ‘19] ● Ecosystem of decentralized Public Public Computation function units Storage Function Unit Function (EVM, WASM, ...) Unit Special Purpose Function Unit Secret (Public Randomness, Private Storage Verifiable Shuffle, …) Computation Function Function Unit Unit (SMPC, FHE, ...)

Scalable Coordination: Summary Bitcoin’s architecture was a brilliantly wrong conflation of membership & consensus protocols ● De-conflating them is not trivial but massively improves performance, scalability, consistency – Bitcoin-NG, ByzCoin, OmniLedger ● Critical scalability tool: public randomness – RandHound/RandHerd, used in OmniLedger ● In the future we’ll see many different types of shards with different compositions, purposes

DEDIS Blockchain Overview Key aspects of DEDIS blockchain architecture: ● Scaling: can we do enough, fast enough? ● Privacy: can we store and process secrets? ● Resilience: what if we’re poorly-connected? ● Stake: how to get equitable decentralization? Industry Impact, Applications, and Conclusion

The C-I-A (or A-I-C) Triad In information security and data protection, we generally want three fundamental properties Confidentiality Availability Integrity Blockchains strengthen Integrity and Availability, while by default weakening confidentiality!

The Blockchain Privacy Challenge Blockchains protect the integrity of data by giving everyone a copy for independent checking ● This works against privacy & confidentiality ● Current privacy provisions are leaky ● Solvable with proper use of encryption – When combined, important to remember: it’s the encryption , not the blockchain , that protects privacy.

So How Do We Get Privacy? Encryption , of course! Encrypt data before storing, decrypt on use…

But Who Holds the Keys? Any encrypted data is secured with a private key ● A private key is just information (a number)! ● If the key leaks, anyone can decrypt the data – Regardless of where it’s stored: cloud, blockchain… If the private key is held by a single party , then that party is a single point of compromise ● If key-holder hacked, attacker gets everything ● Even if it’s held on a “private blockchain”!

The Privacy Problem in Blockchains In current blockchains, secrets (keys, passwords) must be held “off-chain” by private parties ● Just a hash on-chain → document might be lost ● Encrypted on-chain → encrypted to whom? – Decided at encryption, cannot be changed/revoked Current blockchains can’t manage secrets, because they would leak to all participants ● Weakest-link security again

How to Get Privacy, Accountability? Blockchains don’t protect privacy & accountability without single points of compromise; how can we? With another classic technology: secret sharing . Essential idea: after encrypting data, ”deal” the secret key to a threshold t of n parties ● At least t parties must work together to recover ● If just one (or fewer than t ) compromised, attacker can’t recover the key (or the data)

Secret Sharing: Illustration Suppose you’re a pirate & bury your treasure… X

Keeping the Location Secret You have 3 henchmen who you want to send back for it later, but you don’t trust any one completely

Secret Sharing: Illustration You mark the spot between two reference points X Secret!

Secret Sharing: Illustration Then draw three parallel reference lines… X Secret!

Secret Sharing: Illustration …and another line intersecting all four… X Secret!

Secret Sharing: Illustration The intersection points are the secret shares... X Secret Secret! X XX Shares

Secret Sharing: Illustration You give one of these shares to each henchman X Secret Secret! X XX Shares

Threshold Secret Sharing Now suppose your henchmen come back later to recover the treasure… ● Any one henchman won’t know how to find it ● Any two henchmen will be able to! You get both threshold privacy of the secret… ● No single compromised party can recover it You also get threshold availability of the secret ● Can still recover if one henchman goes missing

Secret Sharing: Illustration One henchman alone can’t recover secret X Secret! X ???

Secret Sharing: Illustration …but any two working together can! X Secret! X X

On-Chain Secrets “CALYPSO: Auditable Sharing of Private Data” Encrypt (*) secrets care-of the blockchain itself, under a specific access policy or smart contract ● Threshold of trustees (1.1) Store secret and mediate all accesses access policy for id Ron ● Enforce policies, (2.1) Download Access-control cothority Wanda encrypted secret (1.2) Log (2.3) Log access recording (2.2) Request secret access Ron’s identity access to secret skipchain (id Ron ) ● Ensure data both Blockchain hidden and disclosed (3.1) Request secret re-encryption when policy requires (3.2) Deliver ● Can revoke access if Secret-management cothority re-encrypted secret Ron (4) Decrypt secret policy/ACLs change (*) with post-quantum security if desired

Application: Blockchain E-voting Prototyped blockchain-based e-voting system ● State-of-the-art cryptographic security/privacy ● Deployed within EPFL community of 10,000+ Helios-like workflow: ● Clients encrypt votes to threshold of trustees ● Blockchain records them ● Neff shuffle and decrypt

Privacy-Preserving Processing Can we compute on private data? At what cost? Intensely active area of cryptography research… ● Fully-homomorphic encryption (FHE) ● Secure multiparty computation (SMPC) …and blockchain/smart contract activities, e.g., ● MIT Enigma project ● EPFL UnLynx project

UnLynx: Privacy-Conscious, Blockchain-Secured Medical Data Sharing Functionality: SELECT AVG ( cholesterol_rate ) FROM DP 1 , …, DP n • Allow queriers to query a set of WHERE age in [40:50] AND ethnicity = Caucasian GROUP BY gender distributed databases Requirements: • Data Providers data confidentiality • No single point of failure • Computation correctness • Privacy of data providers (DP) and individuals storing their data in DPs Threat model: • Queriers, servers may be compromised • Data providers honest-but-curious

DEDIS Blockchain Overview Key aspects of DEDIS blockchain architecture: ● Scaling: can we do enough, fast enough? ● Privacy: can we store and process secrets? ● Resilience: what if we’re poorly-connected? ● Stake: how to get equitable decentralization? Industry Impact, Applications, and Conclusion

The C-I-A (or A-I-C) Triad In information security and data protection, we generally want three fundamental properties Confidentiality Availability Integrity Many copies mean availability , right? Well…

Some Blockchain Availability Risks What if a blockchain you rely on is: ● Overloaded by a load spike you can’t control? ● Under denial-of-service or bribery attack? ● Unreachable from a client that needs it? ● Disconnected/eclipsed by a network attacker? ● Just too slow due to global network latencies?

Blockchain Resilience Challenges Some challenges DEDIS design addresses: ● Can light/low-power clients verify transactions and the state of the blockchain offline? ● Can poorly-connected or disconnected devices securely update each other peer-to-peer ? ● Can a blockchain commit transactions quickly in local areas (by speed-of-light distance)? ● Can blockchain operate robustly in local areas when global connectivity is slow or expensive?

Backward and Forward Verifiability Standard blockchains traversable only backward ● Via hash back-links from current head Time Backward hash links, embedded in blocks at commit time Chainiac adds traversability forward in time ● Collective signature by prior consensus group Time Backward hash links, embedded in blocks at commit time Collectively signed forward links, added later once target exists

Leaping Through Time: SkipChains Offline/peer-to-peer cryptographic verification and efficient “time-travel” through all blockchain history Time Backward hash links, embedded in blocks at commit time B3 B2 B1 Level F1 F2 F3 Collectively signed forward links, added later once target exists

Chaniac: Secure Software Updates Critical devices increasingly networked (IoT) ● Keeping their software up-to-date is critical – Otherwise vulnerable to old threats: e.g., WannaCry DEDIS “Chainiac” provides end-to-end secure blockchain-based software distribution & update

Secure Digital Documents Significant interest in digital degrees, awards, land titles, … ● Blockchain can provide a hard-to-forge timestamp But how do you verify a digital document? ● Current blockchains: you must be online DEDIS blockchain: offline-verifiable timestamps

Locality: Beating the Speed of Light Problem: Strong global consensus requires us to pay global speed-of-light latencies – But many interacting users are likely to be near each other in geography, network topology, network latency Can we create many local blockchain shards, such that for any group of interacting users, they use a “nearby” shard offering low latency?

Resilient Local-Area Operation Crux: Locality-Preserving Distributed Systems [preprint]

DEDIS Blockchain Overview Key aspects of DEDIS blockchain architecture: ● Scaling: can we do enough, fast enough? ● Privacy: can we store and process secrets? ● Resilience: what if we’re poorly-connected? ● Stake: how to get equitable decentralization? Industry Impact, Applications, and Conclusion

Membership, Stake, and Influence Any human organization need a way to decide: ● Who holds a stake in decision-making ● How much influence each stakeholder wields ● How decisions are a actually agreed on: consensus Without stake & consensus, organizations fail

Alternative Foundations for Stake Permissioned: prove you’re in a meatspace club Proof-of-Work: prove you’re wasting energy Proof-of-Stake: prove you’re already rich Proof-of-Storage: prove you have a big disk Proof-of-*: prove you have a lot of *’s Proof-of-Personhood: prove you’re a real person

Proof-of-Work as a Basis for Stake Proof-of-Work requires miners to expend energy surmounting an artificial barrier to entry , just in order to prove they did that. Important point: Proof-of-Work servers no purpose other than to erect an artificial barrier to entry and create competition for mining rewards! Have we seen human practices like this before?

Membership by Hazing Ritual Anything that not everyone will do on a whim: entire purpose is to create a barrier to entry May be uncomfortable and/or embarrassing…

Membership by Hazing Ritual Or just plain weird… ● MIT ‘58: using Oliver Smoot to measure bridge

Membership by Hazing Ritual Or difficult, requiring energy and cooperation ● Yap: chisel a giant circular “coin” out of stone available only on another, distant island

Bitcoin’s Hazing Ritual Digitally flip coins. Many coins. Billions of them. By forming new “blocks” and feeding them into a cryptographic hash ● Converts any information to pseudorandom number Repeat endlessly.

Power Distribution in Bitcoin How much influence does each member wield? ● Proportional to member’s rate of coin-flipping: number of “hashes per second”, or hashpower ● More energy, faster chips → more hashpower

JUST…ONE… JUST…ONE… …MORE…BITCOIN …MORE…BITCOIN

Environmental Costs Proof-of-work = “scorched-earth” blockchains ● Bitcoin makes BTC scarce by making miners prove they wasted energy ● Serves no purpose except to prove they did it ●

Bitcoin Energy Consumption Index Bitcoin now wastes more energy than 159 countries use for their people to live on!

Not Even Decentralized Anymore Market incentives drive consolidation of hashrate or “voting power” to a few powerful mining pools ● Over 60% currently in one country (China) ● Any faction >51% can control or veto decisions, censor, etc.

A Problem Not Unique to Bitcoin Most cryptocurrencies aren’t that decentralized

Permissioned Ledgers Just decide administratively who participates; Fixed or manually-changed group of “miners” –  No proof-of-work needed → low energy cost –  More mature consensus protocols applicable –  Higher human organizational costs –  No longer open for “anyone” to participate

The Weakness of Limited Scale Public/permissionless designs in principle have the advantage of security scaling with size ● As more participants arrive, security increases Scalable Weakest-link Strongest-link Strongest-link security security security Closed participation designs limit security scaling!

Alternative: Proof-of-Stake (PoS) ● Proof-of-Stake: assigns consensus shares in proportion to prior capital investment –  Could address energy waste problem Ma Many ny no nontr ntrivia vial des esig ign cha halleng lenges es –  ● Securing proof-of-stake is a nontrivial, interesting, but mostly-solved problem – e.g., Orobouros, Algorand – Also implementable with CoSi + SkipChains + OmniLedger + RandHound

Modular Proof-of-Stake Assume we have a ByzCoin-like consensus group ● Use PBFT to agree on transactions and stake – List of stakeholders, # shares each, their validators ● After epoch, RandHound-sample next group – Old group collectively signs new, forms SkipChain Epoch 1 blocks, transactions Epoch 2 blocks, transactions CoSi Stakeholder Database public ID Stake Validator RandHound ID Stake Validator sampling … … … Consensus Group 1 Consensus Group 2

Is Proof-of-Stake What We Want? A Proof-of-Stake cryptocurrency is essentially an automated analog of a shareholder corporation. ● May help hasten the takeover of automation, but won’t fix the world.

It’s all just “Proof-of-Investment” Proof-of-Work, Proof-of-Stake, Proof-of-* are all Proof-of-Investment , aka investment capitalism. ● The more * you invest, the greater your reward. All prone to re-centralization, aka rich get richer ● Larger stakeholders always in a better position to exploit economies of scale – or just cheat – to further increase their percentage of the pie. Proof-of-stake won’t keep systems decentralized! ● At best they can reduce rate of recentralization

Long-Term Decentralization? Can we build decentralized systems that will reliably stay decentralized over the long haul? ● Inclusive: allow “permissionless” participation by everyone in practice , not just in theory – Including developing world, homeless, refugees ● Sustainable: Ensure future generations will have the same opportunities that we do today – Regardless whether their grandparents were lucky ● Empowering: Provide opportunities for all while limiting vulnerability to abuse of power

Toward People-Centric Blockchains Can we build decentralized technology that will ● Securely stay open and widely decentralized ? ● Offer a fairness metric meaningful to people ? ● Be accountable to users rather than wealth? “We must act to ensure that technology is designed and developed to serve humankind, and not the other way around” - Tim Cook, Oct 24, 2018

Person-Centric Decentralization Proof-of-Personhood [IEEE S&B ‘17] ● Proof-of-Stake but one stake unit per person

Proof-of-Personhood: Approaches ● Legacy Identities (e.g., government-issued) – Require costly ID-checking, not that hard to fake ● Global Biometric Databases (India, UNHCR) – Huge privacy issues, false positives+negatives ● Trust Networks (PGP “Web of Trust” model) – Unusable in practice, doesn’t address Sybil attacks ● Pseudonym Parties [SocialNets ‘08] – Requires in-person participation, physical security – Low-cost: verifies only personhood, not ID or trust

Is Digital Identity, KYC a Solution? Key Advantages: ● Many businesses, governments working on it ● Leverages existing “document-trail” identities Key Disadvantages: ● Identity documents not hard to fake, steal, buy – SSN $1, Fake ID $20, fake passport $1000, … ● Identity authorities are single points of compromise – Attacker needs to break only one to create many Sybils ● Exclusionary: undocumented/unlucky lose out – Migrants, refugees, homeless, stateless, …

Are Biometrics a Solution? Key Advantages: ● Technically scalable, workable in principle – India Aadhaar, UNHCR World Food Program, … Key Disadvantages: ● Requires not just authentication (1-to-1 comparison) but biometric identity (1-to-billions comparison) – 0.01% FAR → 100,000 false positives per user in India ● Privacy: must collect in massive queryable database – Biometrics are passwords you can’t change when leaked ● One compromised device can enroll many Sybils