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

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

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 Comparison with ours: very different design; ours has faster confirmation time, and more flexible joining, than Praos/Geneses

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

How to Mimic Nakamoto’s Design via Proof of Stake

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

How to Mimic Nakamoto’s Design via Proof of Stake

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 =

NDN0

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

19

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

How to Mimic Nakamoto’s Design via Proof of Stake

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

5000

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)

A

B

C

Θ (Uavg)

BackPackers design

D

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