How to Mimic Nakamoto’s Design - Stanford University · How to Mimic Nakamoto’s Design via...

transcript

How to Mimic Nakamoto’s Design via Proof-of-Stake

Hong-Sheng ZhouVirginia Commonwealth University

Fractal Platform

Jonathan Katz University of Maryland

Fractal Platform

Joint work with

Lei Fan Shanghai Jiaotong University

Fractal Platform

FRACTAL

Outline • Why mimic Nakamoto’s design

• How to mimic

• Decoupling consensus & data distribution

Why Mimic Nakamoto’s Design

H( context, payload, solution ) < Tcontext = pointer to the last block in the longest chain

payload = valid TXs from users/networksolution = nonce

Nakamoto’s designConsensus via “Competition”

Proof of work puzzle

Nakamoto’s design

From Garay et al, Eurocrypt 2015

1. Large-scale

• low communication complexity

• local computing; non-interactive

2. Open: Easy to join/leave

3. Strong security

• adaptive security without assuming secure erasure

• next-block generator unpredictable

4. no fancy crypto tools used; core-chain using only standard hash

Nakamoto’s design

• Consensus via “Competition” Nakamoto’s design; known since 2008 >10,000 nodes; very inclusive and trustworthy

• Consensus via “Discussions” Byzantine Fault Tolerance (BFT); known since 1980s< hundreds of nodes; not inclusive

• Large scale BFT-like protocols have never been stress-tested in real world, unlike Bitcoin, Ethereum

Why Mimic Nakamoto’s design

Why Mimic Nakamoto’s Designvia Proof of Stake

very secure ==> issues

1. Large-scale + 2. Open—> (ideally) very difficult to control the majority of the mining power==> small numbers of BIG miners dominate the system

Nakamoto’s design facing issues

issue #1: mining centralization Bitcoin original vision: based on commodity machines, one CPU one vote

Today:Big mining pools dominate the system 80% mining power is in China

not very trustworthy

very secure ==> issues

1. Large-scale + 2. Open—> (ideally) very difficult to control the majority of the miners==> small numbers of BIG miners dominate the system ==> huge waste of computing resources including electricity & hardware; small number of players dominate the system

Nakamoto’s design facing issues

issue #2: energy consumption

https://digiconomist.net/bitcoin-energy-consumption

Is energy consumption a necessary? NO!!!

Hardware manufacturers have BIG voices

Not inclusive

issue #3: dedicated hardware

How to Mimic Nakamoto’s Design via Proof of Stake

via trusted hardware / beacon

• single point of failure;

Conventional MPC/BFT like protocols

• high communication complexity; small size network; e.g., TenderMint, Ouroboros, DPoS

Bitcoin like efforts (based on hash inequality)

• NXT, SnowWhite: new players cannot join the system securely; not adaptively secure

• The closest work: Ouroboros Praos/Geneses Praos (concurrent work): new players cannot join the system securely; their follow-up Ouroboros Geneses: fixed this issue

Hybrid (hash inequality + BFT)

• Algorand: non local computing; more complex; historically no known such protocols have been stress-tested in the real world

… it is a non-trivial task

• The closest work: Ouroboros Praos/Geneses Praos (concurrent work): new players cannot join the system securely; their follow-up Ouroboros Geneses: fixed this issue

• The closest work: Ouroboros Praos/Geneses Praos (concurrent work): new players cannot join the system securely; their follow-up Ouroboros Geneses: fixed this issue Comparison with ours: very different design; ours has faster confirmation time, and more flexible joining, than Praos/Geneses

Step 1 defending against restricted adversaries

• Proof-of-work core-chain (without payload) H( context, solution ) < T context = the pointer to the latest block in the longest chain solution = nonce solution without “structure”

• Proof-of-stake core-chain (without payload) H( context, round, solution ) < T context = the pointer to the latest block in the longest chain solution = <PK, σ> σ = Sign(SK, context, round) solution with “structure”

Step 1

search version vs decision version

key modifications: round is used; unique signature is used.

Proof of stake core-chain, basic version

Step 1

Unique signaturePublic info

Step 1

Proof of stake core-chain, basic version

This basic version is already nice in the sense that if the adversary is restricted to extend only one position, then the blockchain is secure

Step 2 defending against general adversaries

Step 2In the basic version:

• Honest players extend one position (i.e., the latest block of the longest chain)

• The adversary is restricted, extending one position

In the reality

• The adversary extends multiple positions —> this is equivalent to amplifying the adversary’s stake —> known as “nothing at stake” attacks

Step 2

The mining power can be amplified if players make attempts to extend multiple positions

• Folklore: amplification ratio >1

• Our main discovery: for carefully designed protocol, e.g., the basic version, amplification ratio is upper bounded !

Step 2• main discovery:

amplification ratio is upper bounded !

• amplification ratio < e (i.e., 2.718)

• amplification ratio for 2-greedy is 2.1 We will define 2-greedy very soon

Step 2• main discovery:

amplification ratio is upper bounded !

• amplification ratio < e (i.e., 2.718)

• amplification ratio for 2-greedy is 2.1

• another discovery:using “nothing at stake” to defend against “nothing at stake” attacks

generalgeneral

basicbasicbasic

2-greedy

Greedy strategies

1-greedy

1. identify the longest chain 2. distance to the longest chain 3. length

De�nition 4.3 (Distance-greedy strategy). Consider a blockchain protocol execution. Let P be a player of theprotocol execution, and T be a tree which consists of chains with the same genesis block, in player P’s local view.Let Cbest be the longest chain at round r, where ` = len(Cbest). Consider parameters D and F. De�ne a chain setCbest as

Cbest = {C : distance(C ! Cbest) D, len(C) � `� F}

We say the player is (D, F)-distance-greedy if, for all r, the player makes a�empts to extend all chains C 2 Cbest.Remark 4.4. For simplicity, in the remaining of this section, we set F := D + 1, and call the above strategy,D-distance-greedy strategy for short. In Figure 6 and 7, pictorial illustration for 1-distance-greedy and 2-distance-greedy strategies can be found respectively.

Figure 6: 1-distance-greedy Figure 7: 2-distance-greedy

Adversarial strategies: full-greedy and general-greedy Nowwe turn to consider the adversarial strate-gies. An adversary may consider di�erent strategies to break the security of the blockchain system. For ex-ample, a restricted adversary may follow the full-greedy strategy to extend the all chain; here the full-greedystrategy is essentially the `-distance-greedy where ` is the length of the longest chain.

A more powerful adversarial strategy is called general-greedy strategy: instead of playing the full-greedystrategy to extend all chains, the adversary may treat the chains di�erently. �e adversary may extend thechains in an arbitrary manner; for example, the adversary may not extend the relatively longer chains, butthe shorter ones. We note that, a protocol secure against the full-greedy adversary may not be secure in thepresence of a general-greedy adversary. More discussions can be found in Appendix C.

Stake ampli�cation ratio As mentioned, when a player follows a distance-greedy strategy, he may extendthe chains faster. Next, we introduce ampli�cation ratio.De�nition 4.5 (Ampli�cation ratio). Consider a PoS blockchain protocol. LetN0 be the average increased lengthof the longest chain that extended by a group of players P, follow the 0-distance-greedy strategy. Let ND be theaverage increased length of the longest chain that extended by the same group of players P, follow the D-distance-greedy strategy. We de�ne the ampli�cation ratio for following the D-distance-greedy strategy as A�D =

4.2 �e modi�ed core-chain protocol ⇧core�

Next, we present a new core-chain protocol ⇧core� with the goal of defending against adversaries who playgeneral-greedy strategies. �is new protocol is based on the core-chain protocol ⇧core in Section 3 but nowthe players follow the D-distance-greedy strategy. Details can be found in Figure 8.

We note that, the subroutine BestCore in the previous protocol, has also been modi�ed into subroutineD-BestCore�; now the modi�ed subroutine D-BestCore�, instead of returning the single longest chain, will

Greedy strategies

1-greedy 2-greedy

Step 2

Proof of stake core-chain, 2-greedy version

We can prove that if the honest players control more than 57% stake, then the 2-greedy version is secure

We can prove that if the honest players control more than 73% stake, then the basic version is secure

Next steps

New joining strategy: enabling new players to join the system securely

From core-chain to blockchain:adding the transactions back

More…

Next steps

1. non-flat model

2. adaptive difficulty adjustment

3. incentives

4. light clients

5. post quantum security

6. …

More considerations

Earlier draft available at https://eprint.iacr.org/2017/656 latest version available from the authors

This proof-of-stake serves as the “engine” of the Fractal Platformhttps://www.fractalblock.com/

Implementation

FRACTAL

Implementation#node 1000

the length of round 1sdifficulty 0.00004#rounds 1000

network delay 1s~5sgreedy 4

average width 10

Outline • Why mimic Nakamoto’s design

• How to mimic

• Decoupling consensus & data distribution

H( context, payload, solution ) < Tcontext = pointer to the last block in the longest chain

payload = valid TXs from users/networksolution = nonce

Nakamoto’s design

TXs broadcast twice

TX broadcast is the bottleneck >90% bandwidth

Previous: consensus Now: consensus & block distribution

Network physical limit

BackPackers design

A. Bounded-length Routing o Reduce bandwidth consumption o Remove broadcast bottleneck

B. Adaptive rate control+ Lightweight Network Coding o Optimize throughput across nodes o Maximize bandwidth utilization o Always transmit New information

C. Unsolicited flooding of Meta-block: o 10x reduction in block propagation time

Soft transaction sharding o Prevent packers from packing duplicated txs

Provably Near-optimal throughput

Throughput =

Near-optimal Block Propagation Time (propagate along shortest paths)

Θ (Uavg)

BackPackers design

Implementation

Thanks

Question?

• Lei Fan, Jonathan Katz, Hong-Sheng Zhou, A Scalable Proof-of-Stake Blockchain in the Open Setting (or, How to Mimic Nakamoto’s Design via Proof-of-Stake). Early version at https://eprint.iacr.org/2017/656

• Jonathan Katz, Hong-Sheng Zhou, A Proof-of-Stake Protocol with Post-Quantum Security.

• Thang Dinh, Lei Fan, Phuc Thai, Hong-Sheng Zhou, BackPackers: Fast and Secure Block Distribution for High-throughput Blockchain.

Credits

How to Mimic Nakamoto’s Design - Stanford University · How to Mimic Nakamoto’s Design via...

Documents