prateek saxena computer scienceblockchain/pdfs/saxena.pdf · • in anonymous, permissionless setup...

Better Consensus In The Bitcoin ModelPrateekSaxena

ComputerScience

Blockchains:Origin&Today

2008 2019

ANewModelofTrust• BasisForTrustInPriorSystems:– BlindFaith/Assumption– Reputation– Incentives– Regulation

• ANewModel:Self-regulation– Anyonecanaudittheoperations– (Extremely)HighAvailability– Nopermissionneeded,nocentralizedcoordinator

Alice Bob

Mary

TX-1:Bob->MaryTX-2:Alice->Mary

TX-1:Alice->BobTX-2:Bob->Mary

TX-1:Alice->BobTX-2:Alice->Mary

Double-spending

Application:Self-regulatingCurrency

TheBlockchainConsensusProblem

TheProblem

Transaction1 Transaction2

ConfirmedTransactionBlocks

KeyChallenge:AgreementoverTransactionOrdering

Transaction1 Transaction2

TX-1:Alice->Bob TX-1:Alice->Mary

TX-1:Alice->BobTX-2:Alice->Mary

TX-1:Alice->MaryTX-2:Alice->Bob

OrderingTransactions issufficienttopreventdouble-spends!

WhyTotalOrder?• ReplicatedStateMachines[Lamport84,Schnieder90]– Usefulforbackups,snapshots,distributedlocks,…– Asequenceofcommandstransitionfromstatetostate

…….

ConsensusProtocol

T1 T2 T3 T4 T5 T6 T7 T8

T1 T4Slot1 Slot2 Slot3 Slot4 Slot5 Slot6

T5 T8 T2 T6 T7 T3Slot7 Slot8

ReplicatedLog DeterministicStateMachine

EnablesGeneral-PurposeComputing

Over5millionsmartcontracts!

TheBitcoinSecurityModel• Assumptions:– Atrusted“genesis”block– Nopre-establishedidentities,joiningispermissionless– Afraction“f”(<½)ofthecomputationalpowerismalicious– Networkissynchronous(Blockstransmittedwithinsomedelay)

• SecurityProperties:– Safety:Nothingbadhappens• Stability:Ablockonceconfirmedcan’tbechanged• Agreement: Allminersorderblockssameway

– Liveness: Honestblocksareacceptedeventually– Fairness:Yourconfirmedblocksareproportionaltoyourcomputationalpower

Bitcoin’sSolution:NakamotoConsensus

NakamotoConsensusProtocol• Minerskeepalocalcopyoftheblockchain• MinerssolveacomputationalProof-of-Workpuzzle:

• Successfulminers(usuallyone)broadcastsolution• Minerscheckthereceivedsolutions,andifvalid:– Extendtheirchain’slastblockwiththatblock

• Confirmblockonthelongestchain afteritisk-deep• Bitcoinproposesk=6

• H(s ||last_block_hash ||new_block)<d

NakamotoConsensus:Overview

P6

P5

P4

P3

P2

P1

TX-1:Alice->BobTX-2:Bob->Mary

Solution: X

PoWsolver(blockfounder)isaleader.Everyoneacceptshissolution,ifvalid.- Wedidn’tknowhowmanycomputersconnected,yetweelectedoneblock!- Minersonlyselectvalid blocksperround

ProblemswithNakamotoConsensus:PoorThroughput

• 2-4Kilobytes/second• 6-12TXspersecond• 3-60minuteslatency

• Supportlimitedcomputations• OutagesandUnavailability• AcryptoKittiesappcloggedthe

entirenetwork

DemandfromPractice:1,200- 50,000TXs/s

PoorDecentralization• Inanonymous,permissionlesssetup– Miningconcentrationreflects“real”wealthdistribution

• Goalofdecentralization:Maximizeblockminers/sec• OptimalDecentralizationis𝛩(𝛽),where𝛽 isbandwidth

DecentralizationinBitcoinandEthereumNetworks– Gencer et.al.

ProblemswithNakamotoConsensus:ResilienceReduceswithDecentralization

ABetterMethodtoAnalyzeBlockchainConsistency”– KRS’18.(AlsoseeGK’15,GKL’17,PSS’17)

Unsafe

Safe

• ForNakamotoconsensus,– Resilience (f)is“near-optimal”atblk.interval>3Δ

CanWeDoBetter?

• ByzantineAgreementProblem(Lamport etal.82):– Asetofparties{P1,P2,….Pn}haveinputs– Afractionf outofn aremalicious,i.e.,Byzantine– Goals:• Ensurethatallhonestpartiesagreeonthesamevalue• Theagreedvalueisvalid,i.e.inputofsomehonestnode

ClassicalByzantineAgreement(BA)

ByzantineAgreement

• Yes,repeatedroundsofBA• Agreeon1blockperround• Honestminerssignthatblockwithroundid.

• Challenge:Participantsmustbeknowna-priori– Chicken-n-egg:Agreeingonparticipantsisitself…

…….

InputTransactions

RepurposingBAProtocols?

TheConcept:BlockchainSharding

BlockI1 BlockI2 BlockI3 BlockI4 BlockI5 BlockI6

MorecomputationPower,MoreBlocks

Elastico– CCS’16

Proof-of-work

ClassicalBA

HowtodoitSecurely?

Elastico– CCS’16 (AlsoseeOmniledger – Oakland’18,RapidChain-CCS’18)

H(Coin||PK) = 0𝑥0000………………

Shard1 Shard2 Shard3

Theidentity“PK”isassignedtocorrespondingshard

#.#. >

31

ForsafetyoftheclassicBA

Themean#ofPKspershard:

Forf<1/5is~600Forf<1/4is~1800

Sharding:AStraw-manSolution

Commonrandomcoin

Aknownlistofnodesjoiningsimultaneously

Assumptions

H(Coin||PK)

RunBFTProtocols

Broadcastallblocks BlockI1 BlockI2 BlockI3

ImprovementsovertheBasicSolution

Generatingasharedcommoncoineachround,withoutexcessivebias

O(N2)->O(NC)messagestobroadcasthashvalues,usingadedicatedshardthatrunsBA

O(C2)messagesforBFTprotocols,whichcanbeoptimizedwith

signature aggregation

AdditionalConsiderations

BlockI1 BlockI2 BlockI3

H(Coin||PK)

RunBFTProtocols

Broadcastallblocks

Elastico– CCS’16 (Some improvements intheZilliqawhitepaper)

MinimizethesizeofbroadcastdatatopipelineBAandblockverification

ZILLIQA.COM@ZILLIQA

CommercializedastheZilliqapublicblockchainplatform

ZILLIQA.COM@ZILLIQA

Opentopublicmining(Feb2019)

Securityvs.Performance:State-of-the-art

Approach Resilience Throughput Decentralization Latency

Nakamotowithreducedblockintervals

𝑓 < 13

Low Medium Good

Nakamotowithlargeblocks

𝑓 < 12

High Low Medium

AlgoRand (withBA)[SOSP’17]

𝑓 < 15

High Low Good

Sharding(withBA)[CCS’16,S&P’18,CCS’18]

𝐟 < 𝟏𝟑

High Medium Good

OHIE- ParallelChains[S&P’20]

𝐟 < 𝟏𝟐

High Good Medium~1-3proposerspersec ~30sec.

But,ResilienceandDecentralizationarenotoptimal!

OHIE:APrincipledApproachToScaleNakamoto

JointworkwithHaifengYu,IvicaNikolic,andRuomu Hou(IEEES&P2020)

StartingFromProvenFoundations

ABetterMethodtoAnalyzeBlockchainConsistency”– KRS’18.(AlsoseeGK’15,GKL’17,PSS’17)

Safeunderallstrategies

• ThereisasafewaytorunNakamotoconsensus– Resilience (f)is“near-optimal”atblk.interval>3Δ

InvalidAttackAttemps

KeyObservations

• IndependenceofDesignParameters– Blockintervaldependsonly ondesiredfandΔ– Confirmationlatencydependsonly onblockinterval– Throughputdependsonly onavailablebandwidth(𝛽)– Decentralizationdependsonly onnumberofblocks/sec.

• ExperimentalObservations:– Blockpropagationdelay(Δ)proportionaltographdiameter(1-2seconds)

– Parallelbroadcastsdon’timpactlatency(Δ)

OHIE:Blockchainscalingmadesimple – Yu,Nikolic,Saxena,Hu (ToAppearatOakland’20)

TheOHIEProtocol:Run“k”parallelchains!

.

.

.

Chain0

Chain1

Chaink(=999)

PoW

0000000000

000000001

1111111111

Lastblockofallchains

RH(R,new_block,nonce)<D

MerkleTree

KeyPoints:- Adversarycannotbiasits

computationalpower.- Eachblockextendsaunique

previousblockonauniquechain.- Rcryptographicallycommitstoall

“k”blocksthattheminersees.


TheOHIEProtocol

• Constructionissimpleandmodular• SafetyandLivenessProof:– Bitcoinbackbone(Nakamoto)securityreducestoOHIE– Intuition:• ProbabilisticprocessoneachchainisidenticaltoBitcoin• Eachblockextendsasinglepriorblock• Thestatethattheblockextendscan’tbeforged

– Takes𝛩(logk)moreconfirmationblocks(unionbound)


TotalOrderingAcrossChains?

.

.

.

Chain0

Chain1

Chaink(=999)

ATotallyOrdered(Global)Chain

But,…workswellwhenchainsareofroughlyequallength

Naïvescheme

OHIE


0,10,1

TotalOrderingSchemeInOHIE


0,1

0,1

0,1

1,2 2,3 3,4 4,5

5,6 6,71,50,1

7,8 8,9

9,101,9

5,73,4 4,50,1

0,1

1,2 2,3 3,4 4,5

1,50,1

1,9

5,73,4 5,73,4 4,5

6,7

4,54,5

6,7

8,9

MacroExperiments:LinearScalingwithAvailableBandwidth

• 50,000miners,20Mbps,resilience(f)~0.43

Num.ofchains(k)=0.5 ⋅ 3Δ ⋅ 9:;<=>?@AB

OHIE:Blockchainscalingmadesimple – Yu,Nikolic,Saxena,Hou

MacroExperiments:Decentralization

• 50,000miners,20Mbps,f~0.43• Decentralization:Scaleslinearlywithbandwidth– k>60blockspersecond(20xhigherthanallpriorwork)


MacroExperiments:ConfirmationDelay

• 50,000miners,f~0.43• ConfirmationDelay– Under10minutes(3Δ𝑇)– Independentofthroughput!(oncewefix“k”)

• Conf.Blks (𝑇)=15- 30– 𝑇DEF + 𝛩(logk)


Securityvs.Performance:State-of-the-art

Approach Resilience Throughput Decentralization Latency

Nakamotowithreducedblockintervals

𝑓 < 13

Low Medium Good

Nakamotowithlargeblocks

𝑓 < 12

High Low Medium

AlgoRand (withBA)[SOSP’17]

𝑓 < 15

High Low Good

Sharding(withBA)[CCS’16,S&P’18,CCS’18]

𝐟 < 𝟏𝟑

High Medium Good

OHIE- ParallelChains[S&P’20]

𝐟 < 𝟏𝟐

High High Medium

10mins30secs.60proposerspersec

Takeaways

• DecentralizedSystemsproposeexcitingalgorithmicproblems– Buildbettercrypto,distributedalgorithms,verificationtools,…

• IsthereanOptimalConsensusProtocol?– Latency𝛩(Δ),Throughput𝛩(𝛽),Decentralization𝛩(𝛽),Res.f~0.5– Simplicity– Improvetheconstants

• Needfornewmodelsanddrawingnewconnections:– Consistency&Isolationpropertiesofferedbyblockchains– Sybilresistancemechanisms:Proof-of-Stakevs.Proof-of-Work– Incentivemechanismdesign:Fairness,Variance,…– TrustingOff-chaincomputations

Thankyou!

Collaborators:• Loi Luu (PhD,NUS&CEO– Kyber Network)• Haifeng Yu(Prof,NUS)• IvicaNikolic(Postdoc,NUS)• SethGilbert(Prof.,NUS)• Hrishi Olickel (UG,Yale-NUS)• Roumu Hou(UG,NUS)

PriorScalingEfforts

ExtendingNakamoto:WithLargeBlocks

• Increaseblocksize(e.g Bitcoin-NG)– Mayachievenear-optimalthroughput,latency,resilience• Needsacarefulimplementation

– Poordecentralization:• AsingleblockproposerbroadcaststensofthousandsofTXs• Numberofminersparticipatingisnot𝛩(𝛽)

ExtendingNakamotoWithSmallerBlockInterval

TheGHOSTprotocol

0

16

6 7 0

055

2 1 2 1

0 0 000

“Heaviest”ratherthanlongestchain

𝐴I

𝐴J

𝐵I

𝐵J

…Roundr

8blocks

10blocks

Roundr+1

𝐴L 𝐴M 𝐴N

Honest“Aminers”WillextendA

Honest“Bminers”WillextendB

Roundr+2

ActiveBalancingAttackonGHOST

SecureHigh-RateTransactionProcessing inBitcoin– SZ13

AttackEffectivenessonGHOST


prateek saxena computer scienceblockchain/pdfs/saxena.pdf · • in anonymous, permissionless setup...

Documents