System Architecture

Different from the mainstream distributed system architecture, DeOSS has achieved high integration with the CESS blockchain at the bottom, forming a unique open and decentralized distributed object storage system. As shown in Figure 1, the system architecture is divided into four layers, namely, the application layer, the service interface layer, the blockchain layer, and the storage service layer. The application layer provides users with friendly interactive file object management services. As the middleware of the application layer and the blockchain layer, the service interface layer enables DeOSS to provide object storage services for various self-defined applications and realizes the opening of service functions.
Figure 1 DeOSS system architecture

Blockchain Layer

The blockchain layer, as the core element of the DeOSS architecture, connects schedulers, storage miners, and user applications, to provide important functions such as file metadata management, user storage space management, scheduling, and storage miner account management. The blockchain layer is based on the CESS chain and adopts the self-developed efficient consensus algorithm R²S. The chain nodes are divided into light nodes and full nodes. The light node provides the message channel for the upper layer to communicate with the blockchain network. The full node is responsible for the block collection and packaging, participating in consensus, and maintaining the off-chain worker that implements time-limited challenges and other functions. DeOSS has flexible storage expansion capability. Any qualified account can apply to become a scheduling node or storage miner to provide services for DeOSS and receive rewards.
After pledging a certain amount of deposit, the user can download the scheduler program and become a scheduling node, which is responsible for scheduling the file storage blocks. The CESS chain will reward the scheduling node according to its workload. Cheating will result in an irredeemable balance. The storage miner receives and stores scattered file blocks from the scheduling node, and also needs to submit a storage certificate within a specified time limit based on random challenges initiated on the chain.

Service Interface Layer

The DeOSS service interface layer implements the modular encapsulation of common code libraries, so the application layer only needs to implement a few APIs to provide the complete object storage service. The DeOSS application layer service architecture is shown in Figure 2. DeOSS provides two application modes at the moment: the command line-based Go client mode and the Gin framework-based server mode. Both modes can be configured simply and started quickly. Users can also add a self-defined functional module interface flexibly without worrying about internal code implementation details.
Figure 2 DeOSS Application Layer Service Architecture

Application Layer

DeOSS application service has a three-layer architecture.
  • The network connection layer provides the upper layer with basic services such as user interaction, data object transmission, and on-chain function call.
  • The internal service layer handles user data files from the interaction layer. It provides pre-processing utilities such as data authentication, file slicing, replication, file declaration, etc., and submits the processed content to the scheduler. On the other hand, it is also responsible for processing the data from the chain node and the storage miner node.
  • The interaction layer is responsible for the interaction between users and DeOSS to form a complete service loop.
In addition, DeOSS also provides data encryption and decryption, system logging, and other additional service support.