Sharding and Scaling in Blockchain: Overcoming Limitations for Improved Performance
Sharding and scaling play a crucial role in enhancing the performance of blockchain networks. This lecture explores how sharding helps distribute the workload efficiently, enabling better storage, computing, and communication scalability. The concept of randomized node allocations and adaptive adversaries are discussed to address limitations such as identity management, large shard sizes, and adaptive adversaries. Strategies like random assignment and frequent node rotation are proposed to mitigate these challenges and improve the overall efficiency of blockchain systems.
Download Presentation
Please find below an Image/Link to download the presentation.
The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author. Download presentation by click this link. If you encounter any issues during the download, it is possible that the publisher has removed the file from their server.
E N D
Presentation Transcript
Lecture 20: Lecture 20: Sharding Sharding (Part 2) (Part 2) Scaling Storage, Compute and Communication
Scaling Scaling Scaling compute, storage, communication Share burden across all nodes each node s requirement shrinks Ideal situation all resources are pooled together decentralized consensus but as if resources were centralized
Blockchain Design: Replication Blockchain Design: Replication No Scaling throughput does not increase with number of nodes
Randomized Node Allocations Randomized Node Allocations Node-to-shard algo
Scaling Scaling Random assignment of nodes to shards adversaries cannot game the assignment Requirement on nodes each node only maintains blocks within shard light client for other shards Throughput increases linearly with number of shards
Limitations Limitations Limitation 1: Identity management identity of participants needed for node-to-shard allocation public key is identity of nodes not truly permissionless Will address each limitation in this lecture Limitation 2: Large size shards variance in sortition adversary fraction can be over-represented in a shard Limitation 3: Adaptive Adversaries nodes turn rogue after allocation
Shard Size Shard Size Limitation: Large size shards variance in sortition adversary fraction can be over-represented in a shard Shard size enough so that majority of randomly assigned node are honest constant number of nodes (independent of total nodes) log(1/\epsilon)
Adaptive Adversary Adaptive Adversary Limitation: Adaptive Adversaries nodes turn rogue after allocation Idea: rotate nodes to different shards frequently random allocation of nodes to shards Frequency of rotation ideally, every block or even, every transaction but that would mean no gains in storage/compute
Adaptive Adversary: Only Storage Scaling Adaptive Adversary: Only Storage Scaling Limitation: Adaptive Adversaries nodes turn rogue after allocation Idea: all nodes maintain all shards so no storage scaling Random set of nodes validate every transaction set chosen based on public_key, tx content, prev_block chosen nodes validate tx and sign and communicate validation when there are enough signatures
Parallelizing Validation Parallelizing Validation Random set of nodes validate every transaction set chosen based on public_key, tx content, prev_block chosen nodes validate tx and sign and communicate validation when there are enough signatures Ensure same set of nodes validate tx with same source public_key source-dependent hashing
