Building Trust with Zero Knowledge

I’m always fascinated by how often ‘old’ thought leadership, theories and discoveries can find new life in solutions to modern problems, especially in the technology space. For example, the Fourier Transform introduced by mathematician Joseph Fourier in his 1822 book ‘The Analytical Theory of Heat’ was considered abstract by his contemporaries; yet more than a century later, his work was foundational in signal processing, and today we can thank Fourier for digital advancements like compression formats (JPG, MP3, MP4) and medical imaging techniques (MRI and CT scans).

Another more recent example, important for how we build privacy-preserving systems, is zero-knowledge proof, or ZKP. The basic idea behind ZKPs is pretty cool: one person, the prover, can show another person, the verifier, that they know something specific without actually telling them what it is. This way, the prover can prove they have certain knowledge without giving away any extra information to the verifier.

If we extrapolate that out, the prover can attest that they have some attribute, trait or property that meets a requirement the verifier requires to build trust, without actually exchanging the information. Using a ZKP you could prove to a bank that your credit score meets their requirement for a loan without disclosing the actual score itself. You could use a ZKP to prove you’re an adult without having to reveal your actual age and date of birth — thereby preserving your privacy.

Shafi Goldwasser, Silvio Micali, and Charles Rackoff defined zero-knowledge proofs in their 1989 paper “The Knowledge Complexity of Interactive Proof Systems” as proofs that “convey no additional knowledge other than the correctness of the proposition in question.” Their application in privacy-preserving system design is broad. Many predict that ZK systems will encounter a watershed moment in the coming decade, with reports suggesting the ZKP market has the potential to be worth $10 billion by 2030.

ZKPs are cryptography-based, and encompass a veritable zoo of implementations, with interactive (requiring multiple challenge/response cycles) and non-interactive (single exchange) types, and variants with exotic names like zkSNARKS and zkSTARKS — each with their pros and cons.

• zkSNARKs are efficient (fast) and non-interactive but require a trusted setup and are more complex to implement.
• zkSTARKs don’t need a trusted setup, are more scalable, and are quantum resistant, but produce larger proofs and may take longer to verify.

As with everything in engineering — there are always trade-offs. The choice depends on the application’s requirements for security, efficiency, and scalability.

ZKPs provide developers with a powerful tool for using the Privacy by Design approach when building systems, and another level of security and trust through cryptographic proofs. They also highlight the need for individuals to have simple and robust ways to collect, store and share proof generation and verification.

Even tech giants such as Google are jumping on board with recent partnerships addressing the surging demand for ZK technologies. More needs to be done to empower developers before we see such a reality at scale. Developers need rich tooling to simplify the discovery and consent-based collection of these proofs from individuals.

At Affinidi, we are building tools for developers to take advantage of powerful technologies like ZKPs. We’re working to simplify and democratise the use of decentralised technologies such as verifiable credentials, DIDComm messaging, decentralised web nodes (DWNs), and ZKPs, bridging them with familiar technology standards such as OIDC/OAuth — giving developers new ways to do familiar things.