Beyond proofs: Zero-knowledge as a design philosophy

Waku team

Jun 10, 2025 • 5 min read

The term “zero-knowledge” commonly refers to cryptographic proofs, but its underlying principles can be expanded to encompass far more — it can inform a design philosophy and approach to creating digital architecture that is rooted in privacy and digital sovereignty.

We can imagine systems built according to this philosophy to exhibit "zero-knowledge properties" if they do not expose any information beyond the proof or data requested, preserving user privacy by default.

To explore this idea of a zero-knowledge approach to architecture and protocol design, we must first understand the concept of ephemerality as it relates to sovereignty.

The word "ephemeral" derives from the Greek "ephemeros", lasting only a day. In our digital context, it describes information that exists only briefly before disappearing, mimicking the natural impermanence of spoken conversation. This is, however, not the norm when it comes to digital communications, where the default state of data is permanence, not transience.

Every online interaction typically leaves persistent records distributed across devices, servers, and backups, staying long after their utility to the user has ended. This unnatural permanence creates privacy and sovereignty problems:

Data that persists indefinitely creates expanding attack surfaces
Users lose control over the lifecycle of their information
Service providers become custodians (and potential exploiters) of user data

This aligns with Vitalik Buterin's concept of "control as liability", where he argues that service providers who maintain custody of user data not only diminish user sovereignty but also take on significant legal, security, and ethical burdens.

As Buterin noted in a blog post published in 2019, “The more control you have, the more you become a target for powerful groups that want to influence you to use that control in their favour.”

Designing for ephemerality reverses these dynamics, aligning digital communications more closely with human expectations. Information exists precisely as long as needed, then vanishes completely, returning sovereignty to the participants rather than platforms.

This philosophy leads us naturally toward zero-knowledge systems.

Zero-knowledge: architecture vs cryptography

The term "zero-knowledge" is commonly used when referring to cryptographic proofs and succinct arguments which leverage them, such as zk-SNARKs.

Zero-Knowledge Succinct Non-Interactive Arguments of Knowledge (zk-SNARKs) are cryptographic methods that allow one party to prove to another that a statement is true without revealing any information beyond the validity of the statement itself.

They're implementations of zero-knowledge proofs, which can be seen as one tool among many for achieving zero-knowledge properties.

Many developers assume implementing zero-knowledge requires incorporating these specific proof systems. However, zero-knowledge can be seen as fundamentally an architectural property that can be achieved through various design decisions, sometimes without any explicit cryptographic proofs at all.

The concept of zero-knowledge architecture refers to a system design approach where service providers cannot access user data or derive meaningful insights from the transactions they facilitate.

Buterin frames this architectural approach as "minimising unnecessary custody"—designing systems that structurally limit what service providers can know or control, thereby benefiting both users (through enhanced privacy) and providers (through reduced liability).

This perspective shifts our understanding of zero-knowledge from merely a technical implementation of cryptographic methods to a fundamental design philosophy.

Architectural choices for implicit zero-knowledge

The architectural approaches described below exemplify what Vitalik describes as "paths to reduced custody" in his analysis of control as liability.

Rather than simply applying cryptographic techniques to existing centralised models, these designs fundamentally restructure who knows what within a system, minimising unnecessary data exposure at the protocol level.

Decentralised communication layers

Consider the fundamental difference between these two approaches:

Traditional Web2 architecture: Messages are routed through centralised servers where the service provider has complete access to content, metadata, and user relationships.
Waku protocol architecture: A decentralised pub-sub protocol designed for privacy, where messages are routed through a peer-to-peer network with built-in mechanisms to prevent metadata leakage.

Using Waku intrinsically establishes zero-knowledge properties at the communication layer. The network is designed so no single operator can observe content and metadata or link messages to specific users.

This achieves zero-knowledge not through mathematical proofs, but through fundamental design choices about how messages propagate.

Client-side encryption

When content is encrypted on the client device before transmission, using keys never shared with the service provider, we create another zero-knowledge boundary.

The provider handles data they fundamentally cannot read or analyse — they have "zero knowledge" of its contents despite facilitating its movement.

This principle applies equally to:

Message content in communication systems
File contents in storage systems
Personal data in identity systems

Metadata minimisation

Even when processing encrypted content, service providers often collect extensive metadata: who is communicating with whom, when, how often, for how long, etc.

True zero-knowledge architecture minimises or obfuscates this information as well. Techniques include:

Using protocols with minimal required addressing information
Implementing routing that obscures sender/receiver relationships
Creating interaction patterns that normalise timing and message sizes
Decoupling authentication from communication

Storage architecture

Where and how data is stored fundamentally impacts knowledge distribution. Consider these approaches:

Centralised Database: Data is stored with a single service provider, which maintains comprehensive knowledge of all data relationships.
Distributed Hash Table (DHT): Content-addressed storage where no single node has knowledge of the entire data universe.
Local-Only Storage: Data exists exclusively on user devices, with synchronisation happening directly between them.

Choosing architectures that intrinsically limit what any provider can know creates zero-knowledge properties without necessarily employing explicit ZK-proofs.

Exploring ways to enhance zero-knowledge architecture

While architectural choices can establish baseline zero-knowledge properties, specific cryptographic techniques can further strengthen these systems. Future topics worth exploring include:

Zero-knowledge circuits

Specialised computational circuits that can prove the execution of operations without revealing the inputs. These enable verification of computations while maintaining privacy of the underlying data—this is particularly valuable for:

Identity verification without revealing credentials
Financial transactions proving solvency without revealing balances
Access control verifying permissions without exposing authorization data

Rate-Limiting Nullifiers (RLN)

A cryptographic construction that leverages zero-knowledge circuits to allow systems to limit user actions without identifying users. These circuits generate a Groth16 proof that demonstrates a user is behaving in accordance with the rules.

This enables:

Spam prevention without tracking user identities
Fair resource allocation while preserving anonymity
Sybil resistance without compromising privacy

Advanced zero-knowledge protocols

These cryptographic techniques complement zero-knowledge architecture, but implementing them effectively requires building on solid architectural foundations:

Recursive proofs for scalable verification
Private information retrieval for query privacy
Homomorphic encryption for computation on encrypted data
Anonymous credentials for privacy-preserving authentication

Designing systems for privacy and sovereignty

Privacy and data sovereignty must be fundamental design considerations rather than afterthoughts. "We should be moving toward a world where services retain less control, not more."

By minimising what service providers need to know from the outset, we create systems that are not only more respectful of user privacy but also more resilient and less vulnerable to coercion, attacks, and regulatory pressures. This approach represents a win-win for both users and service providers.

This process typically follows the natural progression below:

Architectural Foundations: Select communication protocols, storage mechanisms, and interaction patterns that intrinsically limit knowledge distribution.
Engineering Practices: Implement client-side encryption, metadata minimisation, and ephemeral storage to further constrain what providers can know.
Cryptographic Enhancements: Introduce specific zero-knowledge proof systems to address remaining privacy challenges where architectural approaches alone are insufficient.

When building systems for ephemeral communication, begin by asking what knowledge distribution is truly necessary for the system to function. Every piece of data exposed to third parties, including service providers, represents a privacy risk and a reduction in sovereignty.

Zk-SNARKs and similar technologies are powerful tools, but they are most effective when deployed within architectures already designed with zero-knowledge principles in mind.

The most robust privacy doesn't come from applying cryptographic band-aids to fundamentally exposed systems, but from designing systems that distribute knowledge only where absolutely necessary from the outset.

The essence of zero-knowledge architecture is not just about what you can mathematically prove, but about what you never needed to know in the first place.