Coins, Clubs, and Crowds: Scaling and Decentralization in Next-Generation Blockchains
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) Bitcoin (2008)
First successful decentralized cryptocurrency…
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? (Ethereum) ● 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 cryptography
(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 Blockchain 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 smart contract
● 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 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
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”) Zcash, 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