Scaling distributed ledgers: Achieving arbitrary throughput and sub-second latency
summary
This work claims sharded ledgers can reach arbitrary throughput and sub-second latency by two concrete systems. For cross-shard safety it introduces per-object sequence numbers and dummy output objects plus a transaction manager (Java fork of Chainspace using BFT-Smart) — Biscuit fixes replay/double-spend attacks and demonstrates near-linear throughput with client-perceived latency under one second at 1,000 tps. For low-latency retail payments it builds FastPay (Rust, Dalek) using Bracha-style consistent broadcast and shows ~150k tps per authority and ~200 ms confirmation from distant clients.
AI-written summary · about
chapters (24)
- 0:00Intro
- 1:00A set of nodes
- 1:18Byzantine Fault Tolerance
- 1:55The best example
- 2:42Hight Latency
- 3:18Low Throughput
- 4:00Main Takeaways
- 4:44What is not covered
- 5:39Scaling blockchains
- 6:48State Sharding
- 17:38Atomix
- 18:07Cross-Shard Consensus How does it achieve linear scalability?
- 19:35Attack against S-BAC Double-spend X1
- 25:35Attacks against S-BAC
- 26:08What causes these issues?
- 26:47Easy Fix?
- 33:37Conclusion Part 1 - Increasing Throughput
- 42:03Centralized systems
- 42:17Slow Finality
- 42:27Little capacity
- 43:33Overview
- 44:18Difference with blockchains
- 55:25Worst-case efficiency
- 58:29Cross-Shard Consensus Tricky to implement right
related talks
28mBlink – Scalability with Sub-second Latency
28mReplay Attacks and Defenses Against Cross-shard Consensus in Sharded Distributed Ledgers
01h 00mDistributed transactions implementation trade-offs
52mScaling Bitcoin to Physical Limits
31mSharded & Distributed Are Not the Same:
16mDispersedLedger: High-Throughput Byzantine Consensus on Variable Bandwidth Networks
22mOff the Chain: Scaling Blockchain in Go
23mScaling Wars: The Race to Speed Up On-Chain Infrastructure