In our last blog, we looked into the pillar of our infrastructure, DefraDB, our peer-to-peer, decentralized, NoSQL database layer. Now let’s explore SourceHub, the trust layer that complements DefraDB and employs crypto-economic incentives to enhance the integrity and privacy of the data it manages.

What’s the relationship between DefraDB and SourceHub?

Good question! The SourceHub’s primary purpose is to provide a platform for a globally replicated and strongly consistent access-control policy enforcement framework to and from the data in DefraDB and beyond. If DefraDB is the lock to managing data, SourceHub is the key.

What is SourceHub?

SourceHub is an application-specific blockchain built on the Cosmos SDK and CometBFT Consensus engine; its design's genuine purpose is to augment our ecosystem with trust, instead of functioning as a general-purpose chain. SourceHub uses the security and decentralized resilience of blockchain technology to fulfill our ecosystem’s goal of democratizing access to data and making it more efficient for developers to manage as they build and deploy the next generation of applications. SourceHub achieves this goal by providing our network with several utilities and functions in a trustless and decentralized manner.

SourceHub has four primary goals and subsequent features:

🛡️ Access Control & Policy Enforcement

SourceHub grants, or revokes, permissions to a DID (Distributed Identifier) based on a powerful policy engine. This engine is based on Google Zanzibar’s paper for a global access control service, which defines a policy framework and language which we extended to include a verifiable access control state. This extension enables developers to define the conditions to which a given identity, or group of identities, can access data. Although developers write these policies, they’re centered around the user, authorizing trustless access policies defined via strict conditions across complex environments (multi-tenant, distributed, and large organizations).

In these environments, DIDs, policies, and authorization proofs work together to enable complex relations and access to everything stored on our database. When the permission engine executes a transaction that requests read and/or write actions, the engines generate a receipt that indicates if it's allowed under an existing policy — and saves the proof to the chain (i.e., SourceHub).

Users can create presentations of these proofs to a DefraDB node and determine if a given action is permitted. It’s kind of like the process of traveling on an international flight, where we have to pass a few lines of defense (check in, security, boarding, customs) to make it to our destination.

🕵️ Identity Management

So remember those DIDs we talked about above? Well, they’re the key to powering the identity system of SourceHub. The Distributed Identifier protocol allows data access permissions to connect to a tamper-proof and censorship-free self-sovereign identity system that exists separately from other permission and authentication systems; it can be easily composed to create a standalone and powerful trustless platform. Across these trustless platforms, permissions can be represented by people, groups, departments, companies, and even federated alliances or DAOs — without one person needing to control them.

Alongside the policy engine mentioned above, DIDs work with the SourceHub Secrets Management Engine (more on that below) to power a truly unique data access and ownership infrastructure, where creators can share access and transfer ownership with collaborators.

🤫 Secrets Management Engine (SME)

While we're sorry to report that this feature isn't a reference to one of the snazzy gadgets you might find in a spy film or adventure series, SourceHub Secrets Management is just as awe-inspiring in its approach to enabling a fast and efficient user experience for sharing sensitive information using cryptography. While in regular Public Key-centric cryptography, an immense amount of responsibility is placed on users to manage address books with their friend's public keys, the SME allows us to circumvent these challenges through Threshold and Proxy Encryption.

In simple-ish terms, this means that the SME (which works with our Policy Enforcement Engine) allows users to create policy documents, citing who and how they wish to share secrets, which can be any kind of data. This integration is just one example of the kinds of secrets the SME can manage, which in this case, would be leveraged to share document encryption keys with collaborators for private data within DefraDB. By combining this with the Policy Engine, this system becomes future-proof, meaning any future update to a policy document regarding a specific secret will automatically handle necessary re-encryption. This process eliminates the arduous steps users must take to ensure that newly added collaborators can (or cannot) access their most sensitive information.

There are quite a few more technicalities to this process (threshold encryption, proxy encryption, zero-knowledge key management systems, and cryptoeconomic incentives) — but we'll save that for a future deeper dive.

✅ Auditing

Last but not least, everyone's favorite: auditing. Thankfully this has nothing to do with our taxes or the IRS but our trust layer's ability to provide insights to people who might want to track the history, access requests, or permission changes of a given document. Auditing offers developers and users transparency into when people authenticate themselves against specific permission policies, which can grant them access to a document (these actions are recorded on a log alongside any permission policy changes).

What's advantageous about this historical permissions logging is that when someone creates a new document in DefraDB, a genesis transaction automatically anchors the document to SourceHub. This process provides unequivocal proof that the document was created, when that event occurred, and that it was initially verified with our trust layer. Through the power of SourceHub's auditing process, developers and users can opt-in to make additional requests to changes of documents stored in our database, which are structured as a graph.

From there, auditing allows us to track a document's origins and changes, and permission requests across a given time, allowing multiple parties to agree on the particular lifespan of a document. Overall, auditing brings more confidence and transparency into the journey of data.

More Power (and Trust) Over Your Data

Like every aspect of our work and mission at Source Network, SouceHub gives us all power over storing, managing, accessing, sharing, and protecting our data. Through leveraging some of the most resilient and secure aspects of blockchain technology, SourceHub is another example of how we’re reimagining the relationships that developers and users can have with their data and how they can make it work for them. Find out more on the SourceHub.