We’re in the midst of an epochal shift in computing patterns from being single-player to multi-player, Enterprise data included. While there has been plenty of hype about the migration to Web3, the heart of the movement is about leveraging verifiable computing patterns that shift mindsets from “won’t do evil” to “can’t do evil”. Though most of the media coverage focuses on rebuilding entire public and permissionless Web3 solutions like Ethereum, these solutions lack GDPR/HIPAA compliance, and aren’t practical for a majority of the world’s data flows.
Private Web3 solutions are rapidly emerging that will help Enterprise customers easily and securely: 1) add Verifiability to their data, 2) establish Immutability guarantees, and 3) enable them to benefit from the power of Trust Networks. I’ll describe each of these features and how they’re functionally achieved in detail. Then I’ll talk about how they apply to a specific use case: the evolution of financial systems to use chains of verifiable, trusted data. Then I’ll wrap up with a few notes on the broader outlook market of an evolution that will be as pervasive as the migration of websites from HTTP to HTTPS.
The upgrade from HTTP to HTTPS is relevant here both because of the historical precedent for a widespread security upgrade, and because its goal was to ensure safe communications between trusted parties. HTTPS communication has 2 goals:
- Ensure that counterparties are who they say they are,
- Establish a secure tunnel so that communications can’t be tampered with.
I’ll focus here on the first step, where counterparty validation is done using a pattern that has been generalized and ratified as a formal W3C standard as the Verifiable Credentials. It’s easiest to describe this pattern with the analogy of a Driver’s License. There are 3 parties involved in this flow,
- Issuers like the DMV have the authority to issue Driver’s License to…
- Holders are the people with licenses who present them to…
- Verifiers who validate that the license was issued by the DMV.
The same thing happens with an HTTPS flow, but instead of a Driver’s License, almost all websites now host a certificate on their websites that lets end users validate that this isn’t a fake website or phishing attempt. These are public key certificates, leveraging public key cryptography and digital signatures from certificate authorities like LetsEncrypt.
We’re seeing the same pattern moving from websites to sign all data flows, and it’s particularly important in multi-player data scenarios like financial ecosystems. There has been a recent uproar over what appears to be fraud committed by the cryptocurrency exchange FTX who misappropriately transferred customer assets. Now, many financial entities are being asked to provide a Proof of Reserves or other attestation that all assets are being held appropriately.
The problem is that validating financial portfolios involves reconciling a complex ledger of positions that are held across a variety of different locations and providers. It’s a complex game of telephone trying to validate that stewards of capital actually have what they claim.
Financial institutions can start issuing positions that are signed to use Verifiable Credential patterns to solve this challenge the same way that websites did. Instead of custodians like Goldman Sachs or Coinbase just issuing CSV files with positions, they can sign that data and put out a public key that others can use to validate that it comes from an authentic source. This allows auditors like PwC and fund administrators like MG Stover to verify activity more accurately and easily than legacy systems of PDFs in Dropbox folders and tracking Emails they’re cc’d on.
One of the key features of Web3 solutions is the ability to cryptographically guarantee that history hasn’t been tampered with. The details here are beyond the scope of this article, but I encourage you to read this Intro to Web3 to learn more about the power of consensus networks. And though public Web3 solutions like Ethereum don’t have the GDPR or HIPAA compliance that are required for enterprise data flows, solutions like Weavechain use Blockchain Anchors to give data immutability properties in a compliant way.
The key concept is that while you can’t put sensitive data on many blockchains, hashes and zero-knowledge proofs (ZKP) contain no sensitive information and can be used to prove that data hasn’t been tampered with. The original data holder creates a hash or ZKP using the data, and it would be infeasible for anybody who didn’t have the original data to recreate the same thing. That hash or ZKP can be put on any distributed ledger technology; this is the blockchain anchor. Finally, in the future trusted parties with a copy of the original data can validate that it matches the anchor from the past.
In our financial use case this gives us the ability to take broad spanning calculations like net portfolios and show that they haven’t been tampered with. Combined with the Verifiable, signed data from brokers, this is how you build privacy preserving systems where users can enforce ‘Don’t trust, Verify’.
The final piece of the puzzle is enabling the establishment of Trust Networks, where data can be shared openly, so that attestations can be made by groups instead of individuals. Financial Systems already leverage partial trust networks, where the moral hazard of entities reporting on themselves is managed by having 3rd party auditors create reports instead.
As noted above, today most financial data exchange happens with haphazard systems of CSV files, FTP and Dropbox servers, PDFs, and shared access. Even if the data used Verifiable Credentials, and had immutability guarantees, it would still need to be ingested into the databases of auditors in a bespoke process that leaves room for error.
Blockchains are sometimes referred to as a Distributed Ledger Technology (DLT), and the key concept is that it is a database that is always synchronized across all of its participants. We’ve talked about how Public Web3 isn’t appropriate for many enterprise data sharing scenarios, and how Blockchain Anchors are a superior approach. But that doesn’t mean DLTs can’t support entities that are permissioned to share raw data.
In our financial use case, we’re seeing the emergence of distributed ledger technologies being used to synchronize position data between stewards of capital and their auditors, and even sometimes brokers. Using a common DLT enables the issuance of stronger attestations, for example a ‘Proof of Accounts’ attestation that is signed by both a steward and its auditor that includes Merkle Trees for depositor validation and various other position data. When raw access is appropriate, DLTs are superior to bespoke data transfer mechanisms.
The beautiful thing about these trust networks is that hacks can be identified quickly, and the trust network has copies of data in case the data needs to be reverted to a previous state. I refer to this method as a ‘Distributed Defense’, and the technique is powerful enough that in 2021 the White House issued an Executive Order asking for its security logs to be protected with DLT.
Add Verifiability to Your Data Stack
The next era of the internet is rooted in adding a trust layer that will make the fraud of the past look barbaric. I’m excited to be working on technology to facilitate this evolution at Weavechain, and you’re welcome to reach out to email@example.com if you’d like to chat further about how Verifiable Data can help your organization.