Context-Aware Storage

Unlike other open networks that leverage object storage alone to manage state data, MOI uses a hybrid combination of both object storage as well as block storage in order to manage participant state data as well participant file data such as invoices, documents, and so on. This reduces the dependency of managing a secondary storage network such as the InterPlanetary FileSystem (IPFS) ²³ to manage files externally for business-grade application use cases.

While object storage is used to replicate the state data of accounts, block storage is used to store the encrypted files of an application or user account and replicate it among all the nodes in its context.

Unlike other blockchains, MOI nodes need not maintain the complete state information of all the participants. Provenance data, such as Tesseracts, will be available with every node, but the Account state data will be available only with the context nodes of that wallet. Any other node which needs account state information can query it from the network using the crypto-graphical hashes found in the latest tesseract of the respective wallet. This is in turn is facilitated using the Bitswap protocol ²⁴, thereby enabling lesser capable devices such as the Internet of Things (IoT) to also participate in the network. The following figure summarizes the same:

Figure: Context-aware storage in MOI and its role

In reference to the above figure, while user-specific data can be managed by block storage service, provenance data is preliminarily stored in object data service and then permanently persisted by the block storage service, such that, each unit can be queried with a unique cryptographic hash. Finally, the account state data is solely managed by the object data service only by the nodes familiar with the wallet’s context.

By diversifying the role of storage into services, we enable nodes to choose the services dependent on their hardware capabilities or interest.

Each state data as part of Account or Tesseract state is stored locally and referred by its corresponding CID hash in the appropriate fields of the structure.

As part of the MOI node’s storage capability, it hosts a local persistence that works closely with POORNA to advertise that it hosts the data for a given CID. This can be summarized as follows:

Figure: Dissected view of services related to content-addressed

As you can see from the above diagram, the state management services from GUNA will make the appropriate changes to an Account or Tesseract object and creates a new state. This new state data needs to be persisted as a fresh key-value(k-v) entry in the local persistence. This is handled by the persistence management of DHRUVA. Once the k-v entry is successfully written to the local persistence, it is imperative to update the network that the data for a corresponding CID is available in this node. Hence, the DHT.Provide() will be called along with the new CID to make this advertisement through the Bitswap protocol.