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

Coins, Clubs, and Crowds: Scaling and Decentralization in Next-Generation Blockchains 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) dedis@epfl.ch – dedis.epfl.ch

Vienna BDLT Summer School – September 3, 2019

• Prof. Bryan Ford

Decentralized and Distributed Systems (DEDIS) School of Information and Communications (IC) dedis@epfl.ch – dedis.epfl.ch

Vienna BDLT Summer School – September 3, 2019

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

Access, sharing compounds risk

Business Partner A Shared Access Partner B Partner C “All of us!” “All of us!” “You can trust us!” Weakest-Link Security

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 partjcipants, no central authority,

no single points of failure or compromise Overarching theme: building decentralized systems that distribute trust widely with strongest-link security

Weakest-Link Security Strongest-Link Security

Turning Around the Security Game

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

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

DEDIS Laboratory Members

Bryan Ford Associate Professor Philipp Jovanovic Postdoctoral Scholar Lefteris Kokoris-Kogias Ph.D. Student Kirill Nikitin Ph.D. Student Cristina Basescu Ph.D. Student Enis Ceyhun Alp Ph.D. Student Jeff R. Allen Software Engineer Kelong Cong Software Engineer Gaylor Bosson Software Engineer Noémien Kocher Software Engineer

Today’s Hot Decentralized Technology

(credit: Tony Arcieri)

Bitcoin (2008)

First successful decentralized cryptocurrency…

How to track wealth (or anything)?

Things

• Gold, beads, cash...

Ledgers

• 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)

Alice 5 BTC Bob 2 BTC Charlie 3 BTC ...

Distributed Ledgers

Problem: we don't want to trust any designated, centralized authority to maintain the ledger Solution: “everyone” keeps a copy of the ledger!

– Everyone checks everyone else's changes to it

Alice 5 BTC Bob 2 BTC Charlie 3 BTC ... Alice's copy Alice 5 BTC Bob 2 BTC Charlie 3 BTC ... Bob's copy Alice 5 BTC Bob 2 BTC Charlie 3 BTC ... Charlie's copy

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 Security: T = 1 Strongest-link Security: T = 2-10 Collective Security: 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 Horizontal Sharding Sidechains Payment Networks

L

share window of size w L

Keyblocks Microblocks Miners

Transactions Shard 1 Shard 2 Shard 3

ByzCoin: Marrying PBFT with PoW

Use PoW to pick PBFT groups [USENIX Security ‘16]

• Permanent transactjon commitment in seconds
• 700+ TPS demonstrated (100x Bitcoin, ~PayPal)

Closely-related: Hybrid Consensus by Pass/Shi

1 2 3

1 2 3 4 5

...

5-1 0 sec Bitcoin Cothority

Miner Witnesses

Key-Block Micro-Block depends on

6

Co-Signature

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 1 Shard 2 Shard 3

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]

• Standard t-of-n

threshold model

• Efficient, scales to

thousands of parties

• Compatible with

ByzCoin, OmniLedger blockchains

(c,r) collective randomness

CL CL

TSS group 1 TSS group 2 TSS group 0

GL GL GL GL

(c,r0) (c,r1) (c,r2)

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 function units

Public Storage Function Unit Secret Storage Function Unit Public Computation Function Unit (EVM, WASM, ...) Private Computation Function Unit (SMPC, FHE, ...) Special Purpose Function Unit (Public Randomness, Verifiable Shuffle, …)

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 Blockchains strengthen Integrity and Availability, while by default weakening confidentiality! Integrity Availability 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!

X XX

Secret Shares

Secret Sharing: Illustration

You give one of these shares to each henchman

X

Secret!

X XX

Secret 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

mediate all accesses

• Enforce policies,

access recording

• Ensure data both

hidden and disclosed when policy requires

• Can revoke access if

policy/ACLs change

Access-control cothority Wanda Ron (1.1) Store secret and access policy for idRon Blockchain (2.1) Download encrypted secret (3.1) Request secret re-encryption Secret-management cothority (1.2) Log secret (2.3) Log access (4) Decrypt secret (2.2) Request access to secret (3.2) Deliver re-encrypted secret Ron’s identity skipchain (idRon)

(*) 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:

• Allow queriers to query a set of

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

SELECT AVG(cholesterol_rate) FROM DP1, …, DPn WHERE age in [40:50] AND ethnicity = Caucasian GROUP BY gender

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 Many copies mean availability, right? Well… Integrity Availability Confidentiality

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

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

Time

Backward hash links, embedded in blocks at commit time

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 Collectively signed forward links, added later once target exists B3 B2 B1 F1 F2 F3

Level

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

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

Membership, Stake, and Influence

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

• ther 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

• r “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

Closed participation designs limit security scaling!

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

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 Consensus Group 1 Epoch 2 blocks, transactions Consensus Group 2 ID Stakeholder Database Stake Validator ID Stake Validator … … … CoSi public RandHound sampling

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

• ne 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

Pseudonym Party Room

1. 2.

Pseudonym 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;
• rdinary 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 Other companies building on DEDIS research

IOST

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