GlacierDB
Last updated
Last updated
Glacier provided the data-centric network to handle datasets seamlessly and effortlessly with NoSQL GlacierDB on top of Arweave, Filecoin, and BNB Greenfield.
GlacierDB technical stack mainly consists of the following layers:
Web3 DApps, which are accessing the Glacier decentralized protocol through Glacier Dev SDK.
Glacier decentralized protocol, which is the main part of GlacierDB and consists of the following segments:
Glacier Dev SDK
Glacier NoSQL Access Protocol
Database Engine Shards
Database Transaction Rollup (Data Transactions Rollup)
Data Permanent Availability Network
L1 (Layer 1) Settlement
Indexer Network
The permanent storage layer of the Glacier database.
The DB Engine is the core unit of the Glacier Network, and the entire network is composed of many DB Shards (which will be discussed in detail in the following sections). The DB Engine is responsible for processing data within each Shard.
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.
DB sequencer processes transactions, produces DB blocks, and submits proofs to the Layer1 chain and submits data blocks to data availability layer. To prevent negative effects such as transaction censorship and downtime caused by centralized sequencer, the DB Shard and DB Meta Registry use a validation network consisting of a single leader and multiple validators to ensure the reliability of the sequencer.
A sequencer validation network consists of multiple sequencer nodes, each of which is independent and has the same copy of data. Among them, the sequencer node (leader) is responsible for receiving transaction traffic, and other sequencer nodes (validator) are responsible for data validation and replicas. If a new sequencer node needs to participate in the validation network, it needs to stake a certain amount of $GLS. If the leader is down due to certain circumstances or there is a problem with the block generation, the leader will be punished, and the entire validation network will reselect a new leader to resume work.
