Coins, Clubs, and Crowds: Scaling and Decentralization in Next-Generation

Prof. Bryan Ford Decentralized and Distributed Systems (DEDIS) School of Information and Communications (IC) [email protected] – dedis.epfl.ch

Vienna BDLT Summer School – September 3, 2019

Where there’s data, there’s risk...

Access, sharing compounds risk

Weakest-Link Security “You can trust us!”

Shared Access

Partner A

Business

Partner B

Partner C “All of us!” A Fundamental Challenge

In today’s IT systems, security is an afterthought ● Designs embody “weakest-link” security

Scaling to bigger systems → weaker security ● Greater chance of any “weak link” breaking

Central Databases = Attractive Targets

One of three credit rating agencies in the US ● Exposed sensitive personal information about 143 million people (44% of US population)

The DEDIS lab at EPFL: Mission

Design, build, and deploy secure privacy-preserving Decentralized and Distributed Systems (DEDIS) • Distributed: spread widely across the Internet & world • Decentralized: independent participants, no central authority, no single points of failure or compromise Overarching theme: building decentralized systems that distribute trust widely with strongest-link security

Strongest-Link Security Weakest-Link Security Turning Around the Security Game

Design IT systems so that making them bigger makes their security increase instead of decrease

Weakest-link Strongest-link Scalable security security Strongest-link security

DEDIS Laboratory Members

Bryan Ford Philipp Jovanovic Associate Professor Postdoctoral Scholar

Lefteris Kokoris-Kogias Kirill Nikitin Cristina Basescu Enis Ceyhun Alp Ph.D. Student Ph.D. Student Ph.D. Student Ph.D. Student

Jeff R. Allen Kelong Cong Gaylor Bosson Noémien Kocher Software Engineer Software Engineer Software Engineer Software Engineer Today’s Hot Decentralized Technology

(credit: Tony Arcieri) (2008)

First successful decentralized

How to track wealth (or anything)? Things Ledgers ● Gold, beads, cash... ● Who owns what?

Precedent: the Rai Stones of Yap

Stone “coins” weighing thousands of kilograms ● Left in place once created (“mined”) ● Ownership transfer by public proclamation

(this comparison shamelessly borrowed from Gün Sirer and others) Distributed Ledgers Problem: we don't want to trust any designated, centralized authority to maintain the ledger

Alice 5 BTC Bob 2 BTC Charlie 3 BTC ... Solution: “everyone” keeps a copy of the ledger! – Everyone checks everyone else's changes to it Alice's copy Bob's copy Charlie's copy Alice 5 BTC Alice 5 BTC Alice 5 BTC Bob 2 BTC Bob 2 BTC Bob 2 BTC Charlie 3 BTC Charlie 3 BTC Charlie 3 BTC

...... Applications of Distributed Ledgers

Can represent a distributed electronic record of: ● Who owns how much currency? (Bitcoin) ● Who owns a name or a digital work of art? ● What are the terms of a contract? () ● When was a document written? (notaries) ● What is the provenance of a part? (supply chain) ● Who are you? (self-sovereign identity) ● Who used data for what purpose? (access logs) ● … Distributed Trust is Old News

Many algorithms allow us to distribute trust among multiple (preferably independent) parties Work correctly despite any one (or several) participants being compromised, maliciously colluding Example algorithms: ● Byzantine consensus ● Threshold

(signing, encryption, …) Distributed Trust is Old News

Many algorithms allow us to distribute trust among multiple (preferably independent) parties Work correctly despite any one (or several) participants being compromised, maliciously colluding Example algorithms: ● Byzantine consensus ● Threshold cryptography

(signing, encryption, …) How Bitcoin was Groundbreaking

Byzantine consensus (BFT) wasn’t remotely new, but Bitcoin solved it in an interesting new way ● Permissionless: “anyone” can participate – If you’re willing to waste energy continuously ● Scalable to thousands of consensus nodes – BFT was typically tested among 4, ~10s of nodes ● No long-lived leaders, supernodes, committees – Unspecialized nodes resist rapidly-adaptive attacks

Properly-Designed Blockchains Eliminate Single Points of Compromise

Weakest-link Strongest-link Collective Security: Security: Security: T = 1 T = 2-10 T = 100s,1000s

T: threshold of compromised parties to break security

Launched Global Wave of Interest in Decentralized Systems

Limitations of Today’s Blockchains

Public/permissionless (e.g., Bitcoin, Ethereum) ● Slow, weak consistency, low total throughput ● Limited privacy: leaky, can’t keep secrets ● User devices must be online, well-connected ● Mining is inefficient, insecure, re-centralizing

Private/permissioned (e.g., HyperLedger, Corda) ● Weak security – single points of compromise

Beware the Lemon Market

George A. Akerlof won Nobel Prize in economics for observing: If buyers have less information than sellers about product quality, incentives lead to reduced quality The cybersecurity market is a lemon market…

The Lemon Market

Today’s blockchain market is too.  Economically-leading “first-to-market” designs completely compromise decentralized security ● One-click “Blockchain-as-a-Service” on cloud ● Non-Byzantine consensus in deployment ● Centralized PKI in permissioned blockchains

DEDIS Blockchain Research

Working to make tomorrow’s blockchains: ● Fast: responsive in seconds, not minutes/hours ● Scalable: support high transaction volumes ● Private: keeping confidential data secure ● Available: blockchain records usable offline ● Equitable: people-centric decentralization

DEDIS next-generation blockchain infrastructure already available, in use by multiple partners 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

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

Drawbacks of Nakamoto Consensus

● Transaction delay – Any transaction takes ~10 mins minimum in Bitcoin ● Weak consistency: – You’re not really certain your transaction is committed until you wait ~1 hour or more ● Low throughput: – Bitcoin: ~7 transactions/second ● Proof-of-work mining: – Wastes huge amount of energy Scaling Blockchains is Not Easy

Many Approaches to Scaling

Scalable BFT Sidechains

share window of size w Microblocks Keyblocks

keyblock (co-signed) L microblock (co-signed) share Miners miner (co-signer)

L leader

Horizontal Sharding Payment Networks

Transactions

Shard 3 Shard 1 Shard 2

ByzCoin: Marrying PBFT with PoW Use PoW to pick PBFT groups [USENIX Security ‘16] ● Permanent transaction commitment in seconds ● 700+ TPS demonstrated (100x Bitcoin, ~PayPal) Closely-related: Hybrid Consensus by Pass/Shi

1 2 3

... 1 2 3 4 5 6

Key-Block 5-10 sec Micro-Block Miner Witnesses Co-Signature Bitcoin Cothority depends on Why PBFT Doesn’t Readily Scale

Three phase: pre-prepare, prepare, commit In prepare & commit, leader must get at least two-thirds of all participants to “sign-off”

● Nodes sign-off via broadcast: O(N2)

PBFT with Collective Signing (CoSi)

Builds on CoSi, presented in [IEEE S&P ‘16] ByzCoin runs collective signing (CoSi) rounds to implement PBFT prepare, commit phases ● Efficient tree-structured communication ● Sign-offs compressed into 1 signature Reduce round cost from O(N2) to ~O(N)

Announce Commit Challenge Response

Horizontal Scaling via Sharding

OmniLedger: A Secure Scale-Out Ledger [S&P 18]

● Break large collective into small random subgroups

● Builds on scalable bias-resistant randomness protocol (IEEE S&P 2017)

● Commit transactions cross-shard w/ 2-phase protocol

Transactions

Shard 3 Shard 1 Shard 2

OmniLedger: Key Intuition

At any time a (possibly slow) consensus process maintains large (~1000s) list of miners/validators ● Use public randomness to pick smaller (10s, 100s) representative subgroups or shards – Subgroup size is security/performance tradeoff – Periodically refresh/re-form shards to handle churn ● Each shard manages subset of state (accounts) ● Transactions processed by one or a few shards – Typically one shard per account transaction affects – Cross-shard commit protocol ensures consistency OmniLedger Throughput

Wide range of performance/security settings

Problem: Secure Public Randomness

Vietnam War Lotteries (1969)

RandHound/RandHerd

“Scalable Bias-Resistant Distributed Randomness” [IEEE Security & Privacy ‘17] TSS group 0 ● Standard t-of-n threshold model ● Efficient, scales to collective randomness thousands of parties (c,r0) CL (c,r) ● Compatible with GL (c,r1) (c,r2) 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 Storage function units Function Unit Function (EVM, WASM, ...) Unit

Special Purpose Function Unit Secret (Public Randomness, Private Verifiable Shuffle, …) Storage 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

Secret!X

Secret Sharing: Illustration

Then draw three parallel reference lines…

Secret!X

Secret Sharing: Illustration

…and another line intersecting all four…

Secret!X

Secret Sharing: Illustration

The intersection points are the secret shares...

Secret!X Secret X Shares XX

Secret Sharing: Illustration

You give one of these shares to each henchman

Secret!X Secret X Shares XX

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

Secret!X X ???

Secret Sharing: Illustration

…but any two working together can!

Secret!X X X

On-Chain Secrets

“CALYPSO: Auditable Sharing of Private Data” Encrypt(*) secrets care-of the blockchain itself, under a specific access policy or

● Threshold of trustees (1.1) Store secret and mediate all accesses access policy for idRon

● Wanda ad Access-control cothority lo et Enforce policies, wn cr o se ) D d (1.2) Log (2.3) Log .1 te 2 p secret access Ron’s identity ( ry st access recording nc e t e qu re skipchain (idRon) e ec ) R s .2 to (2 s es Blockchain ● cc Ensure data both a

hidden and disclosed (3.1) Request when policy requires secret re-encryption (3.2) Deliver re-encrypted secret Secret-management cothority ● Ron Can revoke access if (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 DP1, …, DPn WHERE age in [40:50] AND ethnicity = Caucasian • Allow queriers to query a set of 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…BITCOINMORE…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 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

Weakest-link Strongest-link Scalable security security Strongest-link 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 –  Many nontrivial design challenges ● 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 Are Trust Networks a Solution?

PGP-style social trust has never proven to be usable ● Even most hard-core geeks don’t participate PGP-style social trust solves the wrong problem ● Even if all key-signing trust relationships are genuine, they don’t actually prevent Sybil attacks – Attacker can forge multiple real relationships under one name in one group, more under another name in a different group, … – There are enough non-intersecting small groups in the world for Sybil attacker to create thousands/millions of Sybils over time ● Little chance of getting caught, plausible deniability if they do ● Exclusionary: people who don’t know people or have social status lose out (migrants, refugees, homeless, …)

Are Graph Algorithms a Solution?

Examples: SybilLimit [Yu et al], SumUp [Tran et al], … ● Assume trust net divided into honest and Sybil regions ● Assume hard for attacker create edges between them

Are Graph Algorithms a Solution?

Examples: SybilLimit [Yu et al], SumUp [Tran et al], … ● Assume trust net divided into honest and Sybil regions ● Assume hard for attacker create edges between the two Clever, interesting, important algorithms, but: ● Works only against large-scale attacks, not small-scale – Vulnerable if many rational participants cheat “just a bit” ● Today’s usable social networks aren’t trust networks – Many Facebook etc users promiscuous → many attack edges ● Excludes genuine but poorly-connected communities – Migrants, refugees, homeless, stateless, again…

Proof-of-Personhood: Intuition

Local communities organize periodic PoP parties ● Interested participants come to given time/place – e.g., once per month, once per quarter ● After critical moment, people can only leave – Obtain one “PoP token” per person on the way out One body → one token per person per event ● Anonymous, can wear masks as in Carnival ● Local organizers only collectively trusted

● Multiple groups can coordinate, federate Pseudonym Parties: Summary

Locally-organized regular physical meetings ● Anyone can enter a space until a set deadline ● Then can only exit, each getting one credential No need for IDs, biometrics, PGP key-signing, etc ● Just bodies: can be in only one place at a time 1. 2.

Pseudonym Pseudonym Party Room Party Room

Proof-of-Personhood: Tradeoffs

Key Advantages: ● Much simpler for attendees than PGP parties – Just show up, get a QR code scanned Key Challenges: ● Takes some real, physical-world effort: reward? ● Not “one-time” → must regularly attend events – Tokens have limited life, expire, must be renewed – Otherwise users could still build up Sybils over time

● Synchronization, scaling across groups, … Scaling Pseudonym Parties

Many local communities host pseudonym parties independently but with synchronized deadlines ● One person, one credential, across all parties Local communities federate, monitor each other to build large-scale trust network of communities ● e.g., each party must host RandHound-chosen group of observers from other communities Easier than securing trust networks of individuals ● Organizers can be expected to have geek skills; ordinary participants just need to show up Why Would Anyone Show Up?

PoP parties cost some (a bit) of physical effort ● Not just once but regularly

Is there precedent for people being willing to endure real-world ceremonies like this? ● Well…

Precedent: “Landsgemeinde”

People debate and vote in person in town square

Political Events, Rallies, Protests

People [sometimes] show up to make a statement ● Even when no one’s counting (precisely)

Parties, Festivals

Religious Traditions

Once a week, or even several times per day ● Often for no tangible rewards in “here-and-now”

What if showing up served a tangible purpose? Example Uses of PoP Tokens

Get anonymous “verified user” accounts on sites ● Wikis, discussion or deliberative forums ● Services can effectively block if abused Privately extend in-person meetings online ● Accessible only to the people who were there Reputation systems that count only real users ● Only real people get to vote, one per person Cryptocurrencies with equal stake per person ● Rewards act as a permissionless basic income Towards Privacy with Accountability

A more powerful tool: anonymous reputation Early prototype: AnonRep [NSDI ‘16] ● Users post information fully anonymously, perform peer review (e.g., upvotes/downvotes) ● System encrypts reputation balances ● Posters reveal only reputation buckets (e.g., “>1000”) , zkLedger tools may help A Crypto Universal Basic Income?

Available on “opt-in” basis to everyone, not just in particular jurisdictions

Towards Secure Digital Personhood

Does the digital world need a new social contract? Cost: you must regularly invest effort to show up Reward: rights and protections in the digital world ● Right to privacy, anonymity, including protection from anonymous abuse via blocking/filtering ● Right to freedom of speech, in equal share: protection from unfair amplification by others ● Right to economic opportunity in equal measure: permissionless universal basic income

● Right to inclusion, protect long-term decentralized Summary: Approaches to Stake

Any decentralized system needs to define who its members are and how much power each has ● Proof-of-Work: a disaster that can & must die ● Permissioned: a reasonable, efficient approach for federations that are closed anyway ● Proof-of-Stake: a useful step with interesting technical challenges, but not the final answer – Same with all “Proof-of-Investment” foundations ● Proof-of-Personhood: a democratic foundation

for decentralization on basis of real people 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? Conclusion

DEDIS Blockchain Industry Impact

Supporting partners collaborating with DEDIS

IOST

Other companies building on DEDIS research Conclusion

DEDIS builds next-gen decentralized systems ● Strongest-link security: no single failure points ● Scalable security: strengthens with growth Making blockchains/ledgers truly usable ● Scalability: scale-out to Visa/MC throughputs ● Privacy: on-chain secrets with enforced policies ● Resilience: offline verification, local operation ● Stake: towards equitable decentralization