Federate Up
How our federated ledger moved data storage to the next level
I’ve been reading a lot recently about how the federated ledger model should provide the next generation of distributed ledger technology. It’s been an interesting read because, to be completely honest, it hadn’t fully dawned on me that we’ve already built one. It was during a conversation with one of our partners, a household name in international finance, that the term was first heard - by me at least. We were explaining how our DotLedger allowed organisations to store data within their chosen jurisdiction while still retaining connectivity with nodes in other jurisdictions.
“Ah, so what you’re describing is a federated ledger.”
“Yes precisely” (is it? must look that up later.)
“And it’s fully operational?”
“Yes, we’ve been running it for three years now.” (Why are you looking impressed/surprised?)
In fairness to our tech geniuses - the guys who invented and patented our ledger - their response to my bewilderment was “Of course it’s a federated ledger, I thought you knew”. But as it was news to me, it might be worth explaining a little more to you.
Blockchain uses a distributed model, that is, data is stored across a large network of computers. It derives much of its security and resistance to hacking from the extended nature of this network and, generally speaking, the larger the network, the more secure the data. However, every node holds a copy of all the data, and this poses problems where privacy regulations dictate that information must be stored in a stipulated jurisdiction. Some organisations also have concerns about the privacy of shared data. This has given rise to private blockchains, where an institution stores its information on its own segregated chain. This causes two new issues:
Smaller blockchains are inherently less secure than global networks, a condition known as localisation.
Data can’t be shared externally except by copying to off-chain storage, leading to transparency and privacy becoming mutually antagonistic.
Our DotLedger uses a different technology, which achieves beyond-blockchain security from as few as two nodes, so an organisation can operate a private ledger without the compromises of localisation. Jurisdiction requirements are thus easily met.
But this model isn’t complete, because the problem of data sharing remains. This is where federation becomes the central issue. Every node of a CertiQi DotLedger is completely private, but it can share data seamlessly, and under full management, with any other node. The data itself remains in-region but the controlling company, subject to its standard obligations under local privacy laws, can reveal relevant items to other parties, regardless of their location.
It’s worth mentioning that this structure allows us to add another layer of security. As described elsewhere, the integrity of every data block in DotLedger is interlocked with every other, preventing tampering. Similarly, each node can exchange interlocks with every other. This doesn’t reveal any data, it simply signifies that no unauthorised changes have taken place. This means that a would-be hacker needs to penetrate every regionalised node (which, as DotLedger is technology-agnostic, may be using different platforms or operating systems) within the same fraction of a second.
It was a surprise - to me at least - to learn that our ledger technology was already using a concept that’s still under discussion among the world’s technology leaders.
To us, it just seemed like common sense.