Mosaic: Client-driven Account Allocation Framework in Sharded Blockchains

TL;DR

Mosaic introduces a client-driven framework for account allocation in sharded blockchains, replacing miner-centric global optimization with local, per-client shard decisions coordinated via a beacon chain. The Pilot algorithm provides a practical, low-overhead guide that fuses historical interaction patterns with expected future activity and shard workload to minimize cross-shard transactions and latency. Empirical results on a real Ethereum dataset show Mosaic achieves four-order-of-magnitude reductions in computation time and dramatically smaller input data per account, while preserving around 98% of system throughput and incurring only modest cross-shard increases. This client-centric approach reduces storage and communication burdens for miners and offers flexibility, new-account allocation, and potential privacy trade-offs, making it a promising direction for scalable sharding in permissionless 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.

Figures (2)

• Figure 1: Mosaic presents a trade-off between efficiency and effectiveness compared to the baselines.
• Figure 2: An illustration of the Mosaic architecture with $k = 2$ shards and $\tau = 2$ blocks serves as a toy example. The red and blue colours represent shard 1 and shard 2, respectively. During the propose phase, a client in shard 2 can propose three types of transactions: migration requests, intra-shard transactions, and inter-shard transactions. In the commit phase, miners in the corresponding shards or the beacon chain collect and package these transactions into a block, which is then added to the chain. Every two blocks ($\tau = 2$), the epoch reconfiguration takes place, during which miners are reshuffled across shards and account migration occurs simultaneously. In this figure, a miner is reshuffled from shard 2 to shard 1 during this phase. The miner first synchronizes with the beacon chain to update its locally stored allocation mapping, $\phi$. Then, it synchronizes with the relevant shards based on $\phi$ to obtain the state of the accounts in the newly assigned shard 1.

Theorems & Definitions (1)

• Definition 1: Account-shard Mapping $\phi$