19
0

Mosaic: Client-driven Account Allocation Framework in Sharded Blockchains

Abstract

Recent account allocation studies in sharded blockchains are typically miner-driven, requiring miners to perform global optimizations for all accounts to enhance system-wide performance. This forces each miner to maintain a complete copy of the entire ledger, resulting in significant storage, communication, and computation overhead.In this work, we explore an alternative research direction by proposing Mosaic, the first client-driven framework for distributed, lightweight local optimization. Rather than relying on miners to allocate all accounts, Mosaic enables clients to independently execute a local algorithm to determine their residing shards. Clients can submit migration requests to a beacon chain when relocation is necessary. Mosaic naturally addresses key limitations of miner-driven approaches, including the lack of miner incentives and the significant overhead. While clients are flexible to adopt any algorithm for shard allocation, we design and implement a reference algorithm, Pilot, to guide them. Clients execute Pilot to maximize their own benefits, such as reduced transaction fees and confirmation latency.On a real-world Ethereum dataset, we implement and evaluate Pilot against state-of-the-art miner-driven global optimization solutions. The results demonstrate that Mosaic significantly enhances computational efficiency, achieving a four-order-of-magnitude reduction in computation time, with the reduced input data size from 1.44 GB to an average of 228.66 bytes per account. Despite these efficiency gains, Pilot introduces only about a 5% increase in the cross-shard ratio and maintains approximately 98% of the system throughput, demonstrating a minimal trade-off in overall effectiveness.

View on arXiv
@article{zhang2025_2504.10846,
  title={ Mosaic: Client-driven Account Allocation Framework in Sharded Blockchains },
  author={ Yuanzhe Zhang and Shirui Pan and Jiangshan Yu },
  journal={arXiv preprint arXiv:2504.10846},
  year={ 2025 }
}
Comments on this paper