Embed Size (px)
Citation preview
Fractal: Key Innovation
F R A C T A L P L A T F O R M I N C .
Outline
❑Background: Proof-of-work (PoW) blockchainso E.g., Bitcoin/Ethereum
o Some drawbacks…
❑ iChing: A novel proof-of-stake (PoS) blockchaino PoS vs. PoW
o Challenges and existing proposals
o High-level overview of iChing
❑BackPackers: A high-performance network-layer mechanismo Physical limits on blockchain performance
o Achieving near-optimal performance
❑Experiments and benchmarks
Improvement along three axes…
❑ More sustainable: low energy consumption
❑ More scalable: near-optimal performance
❑ More secure: o PoS vs. PoW
o Reduced network resources for participants More decentralization
Sust
ain
ab
le
Secure
Bitcoin design
(high level)
Nakamoto consensus
❑Users
o Transactions generated and broadcast (via gossiping)
❑Miners
o P2P network
o Proof-of-work
o Miner who finds a valid solution canpublish a new block (containing transactions)
o Miners work on the longest chain
o Block interval of 10 minutes (on average)
𝑯 ( 𝒄𝒐𝒏𝒕𝒆𝒙𝒕, 𝒑𝒂𝒚𝒍𝒐𝒂𝒅, 𝒏𝒐𝒏𝒄𝒆) < 𝑻
Blockchain issues
❑Wasteful energy consumption o Current Bitcoin electricity consumption
on par with Austria
❑Low throughput:o Bitcoin ~ 7 txs/s
o Ethereum ~ 15 txs/s
o …
o VISA ~ 10,000 txs/s
❑High latency (i.e., confirmation time): o Bitcoin/Ethereum ~ 1 hour
o VISA ~ 7 seconds
iChing: Mimicking Bitcoin via proof-of-stake
Sust
ain
ab
le
Secure
Proof-of-stake vs. proof-of-work
❑ Proof-of-worko Mining based on hash power
o Miner with -fraction of hash power extends the chain with probability
❑ Proof-of-stakeo Mining based on stake (e.g., coins) owned
o Miner with -fraction of stake extends the chain with probability
Proof-of-stake challenges
❑Grinding attacks o Try to extend the chain by varying parameters “for free”
❑ “Nothing at stake” attackso Miners can (try to) extend multiple forks “for free”
❑ Long-range attackso Miners can try to fork chain many blocks in the past
Existing proposals
❑BFT-like proposals (less decentralized and/or permissioned)o Algorand / Ouroboros / Dfinity
o Libra
❑Bitcoin-like proposals o NXT/Snow White (not adaptively secure)
o Ouroboros Praos/Genesis (concurrent work)
Our construction – step 1
❑Registration
o Each unit of stake is associated with (PKi, SKi) for a unique signature scheme
❑Proof-of-stake:
o H(context, <PK, σ>) < T
o context includes hash value of last block and current round number
❑Can prove secure against a restricted adversary, who extends a single
branch, if 51% honest
o What about a general adversary?
Security?
❑ If the adversary is NOT restricted …. o Adversary can extend the blockchain at multiple branches “for free”
o I.e., adversary’s stake can be “amplified”
❑ Folklore: amplification ratio might be arbitrarily large!
❑ Main result: for the basic protocol, the amplification ratio is at most e (= 2.718…) !o We can use this insight to design a better protocol!
Our construction – step 2
❑ Construction as before, except honest players also extend the blockchain on multiple brancheso New way to solve the nothing-at-stake attack!
❑ More-complex honest strategies lead to increased amplification ratio for the honest partieso Approaches amplification ratio for the adversary
Addressing nothing at stake
❑ D-greedy strategy: extend the D-best set of chains o Identify longest chain Cbest
o D-best set = all blocks whose distance to Cbest is at most D
1-greedy strategy:
Addressing nothing at stake
❑ D-greedy strategy: extend the D-best set of chains o Identify longest chain Cbest
o D-best set = all blocks whose distance to Cbest is at most D
1-greedy strategy: 2-greedy strategy:
Security?
❑ We show: the 6-greedy strategy has amplification ratio >2.07
❑ This yields the following security thresholds:
Honest strategy Adversarial behavior Honest threshold needed
for security
basic restricted 51%
basic general 73%
2-greedy general 63%
6-greedy general 57%
Secure joining
❑ We require parties to register K blocks in advance of mining
❑ This prevents malicious players from registering multiple public keys in an attempt to find a key that extends the current set
Secure joining – handling forks
❑ If a fork appears…o When divergent chains both have K blocks, the one that generated the next K
blocks first is better (ties broken arbitrarily)
K blocksCompare round numbers in these two blocks;
if round < round, top chain is best;
if round > round, bottom chain is best;
Secure joining – handling forks
❑ If a fork appears…o If one (or both) of the divergent chains has fewer than K blocks, the longer one is
better
Advantages of our protocol
❑ Permissionless proof-of-stake
❑ Scales to 10,000+ nodes
❑ Secure joining
❑ Adaptive securityo Adversary cannot predict next block producer due to signature scheme
Questions?
BackPackers: Layer-0 Scaling for
Optimal Throughput and Latency
Secure
Security/performance trade-off
❑Larger blocks improved throughput longer propagation time
If block interval (i.e., latency) is the same… more forks worse security
❑Challenges in selecting “best” parameterso Optimal block size/block interval?
❑What are the fundamental limits?
Confirmation
time
Adversarial
toleranceThroughput
Block
intervalBlock
size
Change in same direction
Change in opposite direction
Propagation
time
Blockchain as a peer-to-peer network
o Node 𝑖:• Upload bandwidth: 𝑈𝑖• Download bandwidth: 𝐷𝑖
𝑖
𝑗
𝑠
Blockchain Peer-to-Peer Network
Block producer Source node
New block B to broadcast File B to replicate
Throughput Throughput
Block propagation time Distribution time
Network limit on throughput
❑ The network characteristics impose limits on throughputo E.g., 20 Mbps nodes ≤ 5000 tps
❑ Theorem [Kumar-Ross ‘06]:Throughput ≤ min{𝑫𝒎𝒊𝒏, 𝑼𝒔, 𝑼𝒂𝒗𝒈}o 𝐷𝑚𝑖𝑛: Min. download bandwidth*
o 𝑈𝑠: Source upload bandwidth
o 𝑈𝑎𝑣𝑔 =1
𝑁𝑈1 + 𝑈2 +⋯+𝑈𝑁
Average upload bandwidth
𝑖
𝑗
𝑠
Source bottleneck
(can be solved via parallelism)
Major bottleneck!
Network limit on propagation time
❑For security, need block-propagation time << block interval
❑But block-propagation time ≥ max {latency of the shortest paths}o Achieved when:
• Block size small
• Blocks travel along shortest paths
𝑖
𝑗
𝑠
Proposals for performance improvement
❑Bitcoin compact (BIP 152)
❑Bitcoin-NG protocol
❑DAG-based protocolso SPECTRE, Phantom, Conflux, Prism
❑Other ideaso Layer-2 scaling, e.g., off-chain transactions
o Sharding
The “best” approach?
❑ How to fairly compare different approaches? o Different implementations with various levels of optimization
o Different network environments
o Different parameter settings
o Different proposals can work in tandem
❑ How to identify the performance bottlenecks?
Our blockchain simulator
❑Large-scale (>20,000 nodes) and lightweight
❑Various choices for parameterso Topology: Kademilia, Pastry, random, etc.
o Latency: Geodesic coordinate-based, uniform, etc.
o Bandwidth: Power-law, uniform, etc.
❑Supports powerful statistical analysis: o Throughput, block propagation time,
consensus delay, confirmation time, etc.
❑Event-driven and modular design to support rapid prototyping of protocols
Comparing existing proposals
❑Simulation settings:o 1000 nodes, globally deployed, randomly connected to 32 nodes
o Node bandwidth: 20 Mbps; link latency ~ geographic distance
o Block interval: 10 s; max block size: 2MB
Bitcoin compact performs better than more complicated approaches!!!
Protocol Throughput
(tps)
Bandwidth
utilization
Block propagation
time (s)
Bitcoin 197 1.9% 8.9
Bitcoin compact 423 4.0% 3.5
Bitcoin-NG 331 3.2% 5.3
Ethereum 205 2.0% 8.9
Conflux 340 3.2% 9.5
Prism 382 3.6% 10.9
Very low bandwidth utilization!!!
Performance bottlenecks
❑Main culprit: tx broadcasting: o Huge overhead to gossip a tx
• A node receives 3 messages (invite-request-get, 250B) from each of its neighbors
o The overhead is up to 90% of the total bandwidth (if avg. degree is 32)• Caps bandwidth utilization at 10%
❑Other bottlenecks:o Bottleneck at source: if block producer has low upload bandwidth
o Intermittent transmission: unbalanced load among nodes
BackPackers = data first, ordering later
Consensus = agreement on tx order
𝑡𝑥𝑖−1 𝑡𝑥𝑖 𝑡𝑥𝑖+1… …𝑡𝑥𝑖−1 𝑡𝑥𝑖 𝑡𝑥𝑖+1… …
Agreement on
set of txs
Agreement on
ordering of txs+
Optimize throughput Optimize block-propagation time
Design overview
❑ Introduce new entities called packerso Receive transactions from users
o Intermittently create pseudoblocks with signed sets of transactions
o Can be incentivized to participate (outside the scope of this talk)
❑Packers broadcast pseudoblocks to miners (and other packers)o Lower overhead; invite-request-get per pseudoblock, rather than per tx!
❑Miners solve puzzles on blocks as beforeo Blocks include pseudoblocks rather than txs
❑After solving a puzzle, broadcast meta-block rather the blocko Meta-block identifies which pseudoblocks are included, and their order
o Important that pseudoblocks have been propagated already
Packers and pseudoblocks
❑New node role: Packero Collect txs from users and pack
(thousands of) txs into signed pseudoblocks• Every τ𝑖 rounds (e.g. 0.5s).
• pki is known to all
• txs are routed to packers without broadcasting
o Users still can broadcast txs as special pseudoblocks• Discouraged due to higher relay fee than submitting via packers
Packer
(𝑝𝑘𝑖 , 𝑠𝑘𝑖) 𝑇𝑋𝑠
𝑠, 𝑟, 𝜎
…
…
…
…
transactions pseudoblocks
seq. #
round/timestamp
signature
every 0.5s
Soft Spatial Sharding (S3)❑Goals:
o Avoid packing same tx in multiple pseudoblocks
o Handle offline/overloaded/malicious packers
❑Packers prioritize closer txso Distance of packer to tx = H(pki, tx)
o i = ranked distance function
❑Pack all unpacked tx’s with
𝑟𝑖 𝑡𝑥 −𝑎𝑔𝑒(𝑡𝑥)
Δ≤ 0
o 2nd closest, 3rd closest,… packers will pack txas time pass by (if still unpacked)
a2z3uhj3l3
a2z3uhj3l3
uhe9hef
z8t9hav
ki7gh2
tx
Assign each tx to
its closest packer
…then 2nd closest, 3rd closest, etc.
if still unpacked
Meta-blocks
❑Created & broadcast by block producer
miner𝑇𝑋𝑠
a2fe
𝑇𝑋𝑠
c0e1
𝑇𝑋𝑠
dz7h
pseudoblocks
meta-block
𝐿𝑝
…,
sol
puzzle solution
block
producerVerify sol
Forward
miner
𝐿𝑝 =a2fe|c0e1|dz7h|…
Ordered list of pseudoblock ids
Lightweight: ~3-4KB
pseudoblocks
Linearize pseudoblocks
in 𝐿𝑝 → (full) block
+
Validate the (full) block
Intentional packing delay
❑Only -old pseudo-blocks are selected for a meta-blocko Ensures meta-blocks arrive after all their referenced pseudoblocks
❑(Can be enforced using verifiable delay function)
Performance improvement
❑Bandwidth efficiency:o Multiple sources transmitting in parallel
o Reduces broadcast overhead• #broadcasted_messages reduced by 1000
o Increase average upload bandwidth
❑Latency:o Small meta-blocks ⇒ much faster block propagation
o Removes delays due to tx verification
❑Networking-as-a-service:o Distribute pseudoblocks to receive a portion of tx fees
o Incentives for packers
Eliminates source bottleneck
Solves major bottleneck
Reaches network physical limit
Near-optimal throughput
𝑄12(𝑡)
❑ Optimize rate 𝜇𝑢𝑣 𝑡 on links via queue optimization:
❑ Decentralized control
Theorem 1: Throughput = (1 − 𝜖) network limit*
*Maximum throughput given the network topology and nodes’ bandwidth
*Assuming a constant fraction of duplicate/conflict txs in pseudoblocks
𝑄𝑢 𝑡 : missing pseudoblocks at 𝑢𝑄𝑢𝑣 𝑡 : requested pseudoblocks from 𝑣Load balancing:
𝑣 places a request to neighbor 𝑢 with min |𝑄𝑢𝑣(𝑡)|𝑢 serves a request from neighbor with max |𝑄𝑣𝑢(𝑡)|
Theorem 2: latency = O(min. latency)
Near-optimal latency
❑Unsolicited flooding of meta-blockso No invite-request-get (saves 1.5 round-trip time per hop)
o Meta-blocks travel along shortest paths
miner
meta-block
𝐿𝑝
…,
solblock
producerVerify sol
Forward
miner
Linearize & validate (full-)block
Almost instant-verification
Lightweight: ~3-4KB
Effect on security?
❑Consistency of blockchain unaffected even if all packers are malicious
❑Liveness of blockchain retained even if all packers are malicious
Related work
❑Fast Internet Bitcoin Relay Engine (FIBRE): requires trust assumptions
❑Falcon: No block validation ⇒ may forward duplicate or invalid blocks
❑bloXroute: Forward encrypted blocks ⇒ can be exploited in DoS
BackPackers
Multiple parties/companies
Proven security properties
Incentivity via fee
FIBRE, Falcon, bloXroute
Provided by a single party/company
Not proven to be secure
N/A
Experiments and benchmarks
❑Protocols:o Bitcoin: Original protocol
o Bitcoin-c: Original protocol + Compact Block (BIP 152)
o Bitcoin-NG
o Conflux
o BackPackers
❑1000 nodes, randomly deployed across the globe
❑Latency ~ scaled geodic distance [2s to travel around the world]
❑Average bandwidth: 20Mbps
❑Block interval: 10s; block size: 2MB; intentional packing delay: 3s
Metrics
❑Throughput: o Transactions per second (tps)
❑Block-propagation time: o Time for 95% of nodes to receive a (full) block
❑Confirmation time: o Pr[reversing a transaction] <0.01% for adversary with 20% mining power
Results
Nodes’ bandwidth: 20 Mbps Nodes’ bandwidth: 200 Mbps
Throughput:
✓ More than 10x higher than the others
✓ Achieve up to 70% optimality
✓ ~Visa-scale (40k tps) for good network
Protocol Throughput
(tps)
Bandwidth
utilization
Propagation
time (s)
Bitcoin 197 1.9% 8.9
Bitcoin-c 423 4.0% 3.5
Bitcoin-NG 331 3.2% 5.3
Conflux 340 3.2% 9.5
Prism 382
Fractal 7542 71.9% 1.2Block-propagation time:
✓ <1.5s
✓ Optimal propagation time
✓ Independent of throughput/load.
Protocol Throughput
(tps)
Bandwidth
utilization
Propagation
time (s)
Bitcoin 712 1.9% 18.4
Bitcoin-c 1142 4.0% 8.3
Bitcoin-NG 1754 3.2% 8.7
Conflux 953 3.2% 14.2
Fractal 38,010 72.5% 1.2
Confirmation time
Can confirm txs in under
a minute (45 seconds)!
Real-world benchmark
❑20,000 nodes o Globally deployed in Asia, America, and Europe
o Amazon Web Service + Alibaba Cloud
❑Sustains 3,000–5,000 tps
Summary
❑Sustainability: proof-of-stake iChing protocol
❑Scalability: BackPackerso First decentralized & secure backbone (layer-0) design
o Near-optimal throughput (up to 70% bandwidth utilization)
o Near-optimal block-propagation time
❑Security:o Proof-of-stake vs. proof-of-work
o Lower fork rates (faster propagation time)
o Better decentralization
❑Public testnet available
Sust
ain
ab
le
Secure
Thank you!
