The Unigrid network and it's design creates a foundation that other blockchain products can run on and utilize. Rather than implementing their own blockchain solutions, other blockchains can simply be hosted on top of the future Unigrid network due to its low-level design and segmentation. On the implementation level, these projects would only have to store their data directly, not having to be concerned about the implementation or the fact that their data is stored in a blockchain.

When data is stored on the Unigrid network it is sharded and divided up into separate small blockchains, allowing the system to scale indefinitely with next to no degradation.

Thanks to the low-level design, a blockchain network such as Bitcoin would be able to store its data on top of the Unigrid network. If Bitcoin was simply deployed on top of Unigrid, just tweaking the way the initial blockchain is downloaded, it would allow nodes to synchronize fully in a matter of hours or minutes rather than days or weeks. Furthermore, if the protocol was tweaked to handle a larger block size, it would easily be able to scale and handle many more transactions per second while still retaining the same security and flexibility as the the original blockchain.

Speeding up block synchronization

Rather than having to download and checksum each block individually, what if the data could be stored in a continuous data blob that could be directly downloaded? If the blockchain and the database was stored on the Unigrid network, the trust and the role of keeping the data consistent would move and become the responsibility of the Unigrid network. Individual checks of each block would no longer be needed, because the whole chain would be hashed and stored on the Unigrid network.

Nodes no longer have to store data locally

Because services, logic and data to verify the chain can actually reside directly on the Unigrid network itself, Bitcoin nodes would no longer have to rely on storing block and transaction data locally. This task would be taken over by the gridnodes on the Unigrid network. The node would then run the logic needed, directly from the Unigrid network itself. Consequently, the memory consumption requirements, storage requirements and complexity would drastically decrease and the total storage needed for the Bitcoin network would decrease by several factors compared to today.

Let's visualize a representation of a Bitcoin network as it exists today and imagine we have a network with just 10 nodes:

An example representation of a small Bitcoin network. Each node has to be a full computer able to handle individual handling and storage of the blockchain. The current size of the Bitcoin blockchain is roughly 330GB (May 2021), meaning the required storage is roughly 3TB. On the real network, there are roughly 80 000 full nodes currently running. This translates to roughly 26 000 terabytes of storage space needed to host the Bitcoin network - a significant number.

Migrating this to the Unigrid network would significantly decrease the required storage space, mainly because not only can the data be stored on the network, but the logic to handle the storage of that data also resides on the Unigrid network. Here is a visual representation of how this would look:

An example of a Bitcoin network running on top of Unigrid. Several benefits can be seen. The block verification and storage responsibility moves from the Bitcoin nodes over to the Unigrid network and its gridnodes. This greatly reduces the requirements for storing and computing data - meaning that full Bitcoin nodes can easily run on mobile devices and slimmer computers and hardware in general. Furthermore, rather than storing the data on each node, the data is stored in a sharded configuration on the Unigrid network - reducing the total storage space required.

The data on the Unigrid network resides in shard groups and is stored in multiple pieces. The logic code stored on the network knows how to find these pieces and where they are stored. When load on the shard groups increases the network rebalances, either creating more shard groups or growing the existing ones with more nodes. This allows the network to continuously adapt to increasing traffic and load, while at the same time, wasting less resources than the traditional blockchain solution.

Execution logic is fetched from the Unigrid network with data saved and accessed in shard groups on the network. The data is stored with parity blocks, allowing the network to rebalance, creating a solution that can scale according to the network load it is experiencing.


With the design of the Unigrid network, other projects can store their blockchain in a more optimized manner, requiring less resources. This results in less storage space being needed to accomplish the same thing, creating a greener solution requiring less hard drives and less processing power. The low level design brings down complexity and allows third party blockchains to run on the Unigrid network without any understanding of the underlying implementation.

You’ve successfully subscribed to Decentralized Internet
Welcome back! You’ve successfully signed in.
Great! You’ve successfully signed up.
Your link has expired
Success! Check your email for magic link to sign-in.