💿 DB Sharding

In order to horizontally expand the storage and computing capabilities of the entire Glacier Network, we do sharding for the Glacier Network, which consists of a large number of DB Shards. Each GID Storage belongs to one of the available DB Shards. Glacier has a global DB Sharding Registry that records the DB Shard to which each GID Storage belongs, along with the ID and address of each DB Shard.

Before accessing Glacier, the Glacier SDK will first query the DB Sharding Registry to which the current GID belongs, find the location of the corresponding DB Shard from the Registry, and finally initiate an access request to the DB Shard.

Each DB shard generates data proof and data block periodically, and the data block is publicly submitted to the Data Availability Network and archived into decentralized storage like Arweave. The data proof is submitted to the Settlement Layer Contract. Using L1 as the settlement layer for DB shards will result in linear growth of data proof writing pressure with the increase in the number of data shards, which will seriously limit the scalability of the Glacier Network, especially in low throughput and expensive L1 networks like Ethereum.

To ensure scalability and avoid limitations on the number of DB shards in the Glacier Network, a DB Meta Rollup has been introduced to provide settlement services for data rollups. The DB Meta Rollup serves as a Layer 2 solution for the Glacier Network, while the numerous data shards are built on top of it as a Layer 3 data network. This layered rollup structure enables almost unlimited expansion of the number of data shards.