Our decentralized storage system for organizing and transferring data is currently based on IPFS, an open-source suite of protocols and a decentralized network for data storage. Data is always stored encrypted (”at rest”) and off-chain, ensuring privacy.

​
Why Decentralized Storage?

Today, the majority of online user data is stored on centralized server networks on the cloud.

In contrast, decentralized storage leverages a distributed network which reduces the reliance on any single server or data center, makes user data more resistant to hacks and outages, and gives users more control over their data.

  • Verifiability: the integrity of all data is verified with cryptographic hashing, so you can trust that you always get the data you’re looking for.
  • Resilience: data is retrievable regardless of its location or even if some nodes go offline.
  • Efficient Retrieval: allows chunks of data to be retrieved from multiple sources simultaneously, improving download speeds.

Decentralized storage represents a significant shift towards a more decentralized and secure internet, providing a robust alternative to traditional centralized web infrastructures. By adopting IPFS, we contribute to a more resilient and open web, fostering innovation and protecting against centralized control.

​
How Decentralized Storage works

​
Representing and Addressing Data

Data is addressed by its contents (content addressing), rather than a location, such as a URL or IP address (location addressing). Data is atomized into 256 KB chunks, each of which are assigned a unique cryptographic hash called a Content Identifier (CID).

InterPlanetary Linked Data (IPLD) is then used to link the related chunks together in a Directed Acyclic Graph (DAG) called a Merkle DAG.

​
Persisting Data

Data chunks are saved on IPFS nodes in the network and pinned. Pinning ensures that data persists on the network and remains available for retrieval. In other words, data is exempt from routine garbage collection.

​
Retrieving Data

To retrieve data, we use the relevant CID to fetch the chunks and construct the Merkle DAG.

  • Content routing: We first need to identify which network nodes can provide the CIDs we need. A node cannot simply find data in the network with a CID alone; it requires information about the IP addresses and ports of its peers on the network. Thus, this is done either by the Kademlia Distributed Hash Table (DHT) to find peers, or asking already-connected peers by using Bitswap.
  • Block fetching: the IPFS node fetches the chunks of the Merkle DAG
  • Verification: the IPFS node verifies the chunks fetched by hashing them to validate the hash result.
  • Local access: once all chunks are obtained, the Merkle DAG can be constructed, making the data accessible.

​
Regional Node Clusters

For compliance reasons, there may be use cases where we need to store data in specific jurisdictions / regions (e.g. KSA). Terminal 3 provides the option to deploy private IPFS node clusters within a certain region to ensure that user data that needs to reside within a jurisdiction can do so.

Data SchemaEncrypted Data Warehouse