At Frontier Forum during DevConnect 2025 in Buenos Aires, I spoke about something that has shaped my entire career in zero-knowledge proofs: honesty. For decades I’ve worked on zero-knowledge proofs; tools that make participants in a protocol compliant by construction — tools that let us replace trust with mathematical guarantees. But in this talk, I want to explore whether honesty is more complicated than I used to think and not the same as the compliance we can enforce with zero-knowledge proofs.
I began with what I called a set of “not-so-hot takes.” I genuinely like cryptocurrency, and I believe it can outperform fiat systems. I believe web3 and DeFi can outperform traditional financial rails. My one borderline controversial view is that I’m not particularly fond of stablecoins — they keep us tethered to fiat systems rather than pushing toward more native forms of digital money. None of this is especially provocative. What is clear, however, is that crypto still has a long way to go before it lives up to its own promises.
At Nexus, we’re trying to push the ecosystem forward by making finance — and ideally, everything — verifiable. Proof of solvency, proof-based identity and KYC, proof that transactions executed correctly: these are all building blocks of what we call verifiable finance.
But our ambition extends beyond finance. We talk often about “verifiability at internet scale,” because we believe verifiability will become a foundational property of the entire digital world.
Still, as a cryptographer, I have to confront the limitations of the tools I helped create.
Zero-knowledge proofs can enforce compliant behavior, but only when compliance is demonstrable. They are excellent at proving that a participant followed the rules; they cannot prove that someone didn’t withhold information. They cannot prevent a participant from leaking a secret.
Reasoning about security is essential, we cannot create secure blockchains without a theoretical foundation. So if zero-knowledge proofs cannot guarantee that a participant behaves honestly in every respect, we need to look closer at how we model participants and reason about blockchain systems with many participants. The natural place to look for a foundation and a framework for reasoning about security is cryptography. However, I find the way cryptographers traditionally model participants problematic.
We talk about “honest” and “corrupt” parties as if they were moral classifications. In reality, compliance is what we’re measuring — not virtue. And when we apply these black-and-white categories to real blockchain systems, they often fall apart.
Let me give an example of what I mean. An early influential security model of Bitcoin, defined a notion called “chain quality.” The definition of chain quality divides the participants into honest and corrupt parties, and asks that the honest parties should produce blocks in proportion to their mining power. But what does “honest” actually mean? It was not explicitly stated, but we may assume the reason chain quality matters and it is good to have “honest” block makers on a regular basis is that imbue a blockchain with desirable qualities.
For instance, if “honest” block makers include a wide set of user transactions in their blocks, the blockchain may be censorship resistant. My concern here is that “honest” is a fuzzy term with regard to what we actually expect from the participant and the classification of participants into honest and corrupt is not clear cut.
In the context of chain quality, what really matters is which alliances of nodes are aligned with which users and incentives. Users don’t care about moral labels; they care about whether a block producer is friendly enough to include their transaction. And often “friendship” is bought at a reasonable fee.
I find we should strive for precision in our definitions, and block makers are not absolutely honest or corrupt, one user may find a set of blockmakers friendly, while another user may be supported by a different set of blockmakers. So the core intent of the definition is really that an alliance has influence that is proportional to its mining power.
Returning to zero-knowledge proofs. I have sometimes said that zero-knowledge can keep participants honest by requiring that they prove their actions are according to spec. But in hindsight this feels imprecise, you can strengthen blockchains by making them verifiable but zero-knowledge proofs cannot stand on their own.
Suppose you have a maximally verifiable blockchain. Perhaps even with proof of correctness since genesis, an idea pioneered by Mina, and efficiently verifiable proofs such that the validator set can be very broad. But no proof can show you that there isn’t a yet-to-be-seen block withheld by a participant. And if two valid branches exist, you can prove the correctness of both, even though the network ought to have only one. ZK proves consistency of a chain, not liveness or uniqueness.
This means we need to supplement verifiability with other types of security reasoning, e.g., game theoretic analysis of the economic incentives of participants. And here I worry that standard reasoning in cryptography and distributed systems, which labels participants as honest or corrupt (I’m not being entirely fair here, there is a lot of nuance with regard to corruption in the literature), is leaving something on the table.
Let me give an example of such a loss. A classic result says in a proof-of-stake system you can reach consensus if more than ⅔ of the stake is acting honestly (in the context of safety, honest means not supporting distinct branches, so it is well defined). However, Budish, Lewis-Pye and Roughgarden 2024 showed that instead of completely ruling out safety violations (forks) by requiring ⅔ of the stake to be honest, you can disincentivize safety violations even if only ⅓ of the stake is honest. Sometimes, by modeling the world more realistically, we can actually achieve stronger analyses that justifies use where black and white models do not.
This is why I said in the talk that crypto is not just cryptography.
Crypto is a real-world system populated by organizations, individuals, software stacks, and machines — all with their own incentives and failure modes. Cryptographic models of attackers such as seeing participants as only being one of two types: honest or corrupt may not be the most realistic.
Moreover, the standard “one adversary controlling all corrupt parties (which has good uses in some cryptographic settings),” also seems imprecise in blockchain. Blockchains work in practice, and they seem to be based on economic incentives where multiple self-interested alliances balance each other out. Going back to the result of Budish et al., their model still assumes that at least a third of participants behave compliantly. Why should we assume that? What guarantees that baseline?
There are many other reasons to desire more nuance with regard to the machines and parties running blockchains. We often talk about a node in a blockchain as if each represents a single unitary actor. In practice, a node may be running buggy software — not malicious, just faulty. Or a node may be operated by an organization with dozens of employees and shifting internal responsibilities meaning the risk that it is corruptible varies over time. These entities don’t fit neatly into “honest” and “corrupt.” And yet our security models often force them into those buckets.
I've argued in this talk that honesty of participants and the computation they provide is nuanced. This is an area where we can use more research, and for this reason I want to applaud the host of this talk, SpaceComputer, for looking for novel ways to make computers tamper-proof, including putting them in space.
Daniel McGlynn
