📗 verifiable (adj.) SYNONYMS checkable · provable · auditable OFTEN CONFUSED WITH ▶️decentralized — a claim about who's in charge ▶️transparent — you can see it. Seeing and checking are different jobs. ▶️open-source — the code is public, the execution isn't ANTONYM "trust me" USAGE "The result is verifiable" means you can check it yourself, rather than being told.

Explaining how ZK improves Ethereum to that one "But Why?" friend: Ethereum could fit far more into every block than it currently does. 🤔"But why doesn't it?" Because every computer on the network re-runs every transaction in that block. 🤔"But why do they all re-run it?" Because that's the only way each one knows the block is valid. 🤔"But why can't they just believe whoever made it?" Because then you're trusting whoever made it, and not having to trust anyone is the entire reason Ethereum exists. 🤔"But why not raise the limit anyway?" Because a bigger block is more work for every machine that has to redo it. Raise it far enough and running a node needs serious hardware. 🤔"But why does that matter?" Because everyone who can't afford that hardware stops being able to check anything for themselves. Capacity goes up, the network gets narrower. 🤔"But why or how would ZK help with that?" One machine executes the block and produces a proof it did so correctly. Every other machine checks the proof. 🤔"But why is checking a proof any different?" Because it takes roughly the same effort no matter what's inside. Ten transactions or ten thousand, the check barely moves. 🤔"But why does that change the picture?" Because the heavy work happens once on the whole network instead of thousands of times over. Blocks can carry far more, fees hold steadier when things get busy, and verifying gets cheaper rather than harder. 🤔"But why—" Because Ethereum can finally get bigger and easier to check in the same move. Every scaling decision before this had to pick one. 🤯 "I get it now!"

Did you know that zero-knowledge proofs have fascinating applications outside of blockchain? 🤔 Let's go over some: ☢️Imagine two countries sit down to dismantle a nuclear warhead. Each needs to confirm the other is destroying a real one rather than a decoy. Neither will allow an inspection, because the design of the thing is the secret they're protecting. Princeton researchers published a protocol in Nature ( for exactly this. It confirms a warhead matches a known authentic template while revealing nothing whatsoever about what's inside it. And of course, there are many more examples past crypto: 🪪 Government ID Europe's digital identity wallet is rolling out with zero-knowledge techniques built in, so a check can confirm the one fact it needs about you without the verifier collecting everything else printed on the document. 📷 Journalism Confirming a published photograph came from a real camera, and was edited only in ways anyone can check, without the newsroom handing over the original file (that's what Brevis Vera does). 🤖 AI Confirming that the model which answered you is the one you paid for, and that it ran the way it claims. Early, and moving quickly. Underneath all of it sits the same problem. Somebody has to be convinced of one specific thing, and the evidence itself is the part that can't be handed over.

Let's go over what happens when you swap some ETH for USDC today: Your transaction gets picked up and packed into a block alongside a few hundred others. That block goes out to every node on Ethereum, which is thousands of machines scattered across the world. Every one of them executes your swap from scratch, start to finish, exactly as you did. Then they compare answers. Your one swap, run thousands of times over, so that nobody has to trust whoever ran it first. That redundancy is where the security comes from, but It's also the ceiling. The network can never do more work in a block than every single validator is able to redo on its own. Ethereum's roadmap changes this arrangement. Under the L1-zkEVM plan, a block arrives carrying a zero-knowledge proof that it executed correctly, and validators check the proof rather than re-running the contents. ⚙️ today → every node re-runs your swap ⚡ the plan → every node checks one proof Checking costs roughly the same whether the block held ten swaps or ten thousand. One thing had to become true before any of that was realistic. Your swap was confirmed in a single block, and blocks arrive every 12 seconds, so a proof of that block has to be ready inside the same window. The bar for real-time sits under 10 seconds. Pico Prism 2.1 proves 99.9% of Ethereum mainnet blocks in under 10 seconds, averaging 4.87. Learn more 👇

Today let's get into a concept we've never covered here, and almost everything else in ZK is standing on it. 🔁 Determinism: same program, same input, same answer, every single time. A proof is a statement about one specific computation: this program, run on this input, produced this output. If that program could land somewhere else on a second run, there's nothing solid to make a claim about in the first place. Sounds obvious right? Yet ordinary software breaks it constantly: 🕐 A program that checks whether something happened before a deadline. The prover runs it at 11:58 and gets a yes. The same input an hour later is a no. 🎲 A program that picks a random winner. Run it again, different winner. A proof that the winner was 0xabc... settles nothing, because the prover could quietly re-roll until a friendly address came up. 🔢 Two machines averaging the same list of numbers and disagreeing in the fifteenth decimal place. Both answers look right. Only one matches the proof, so the other machine rejects it. Every one of those is fine in normal code and fatal in a proof. It's also why proving AI is properly hard. Getting a model to produce the exact same numbers twice, on the same machine, is its own engineering problem before anyone proves a thing about it. So a zkVM pins execution down to the last detail and leaves nothing to the environment. Everything impressive about a proof is resting on that one unglamorous requirement.

Fun fact, did you know that zero-knowledge proofs started out as a conversation? ☎️ When they were first described in 1985, proving something meant going back and forth in real time. The verifier threw random challenges at the prover, the prover answered each one, and after enough rounds the verifier was satisfied. Both sides had to be online, talking to each other. A beautiful idea, and completely useless for a blockchain. A smart contract can't hold a conversation. It can't send a challenge and wait around for the reply. It receives one transaction, executes it, and that's the end of the interaction. The unlock was making the verifier's random challenges something the prover could no longer game, derived from the proof itself rather than from a live counterparty. The whole exchange folds down into a single file. 💬 1985 → prover and verifier talk it out, round after round 📄 today → one file, checked by anyone, whenever they feel like it That file is what every proof we generate at Brevis actually is. Handed to a contract, checked in milliseconds, nobody on the other end.

We've spent a few evenings here on how small a proof is and how fast it checks. There's a third property worth highlighting. A proof outlives whoever made it. ⏳ The evidence sits inside the proof. In ten years anyone can check it in the same few milliseconds, with the prover long gone and the servers switched off. Every other kind of "verified" is a pointer at someone who has to still be around, and still be honest.

An Ethereum block, a year of someone's on-chain history, an edit made to a photograph, or the answer an AI model gave. Four completely different jobs with the same requirement, and that's what we've built Brevis to handle.

Today let's talk about one of our core technologies, the ZK Coprocessor. The name goes back to 1980. 🧮 Processors back then couldn't do floating-point math at any useful speed, so anything with decimals, square roots or trigonometry in it got worked out slowly in software. Intel's fix was the 8087, a separate chip that did nothing but that kind of math. IBM put a socket for it on the 1981 PC motherboard and left it empty, so you could buy the chip later if your work needed it. The setup was simple. The main processor would hit something expensive, hand it to the chip built for that job, and carry on with the rest, with gains that ran from marginal to more than fivefold depending on the workload. By 1989 the math had been built into the processor itself and the separate chip went away. However, the word stuck around, because the same problem keeps showing up. ⛓️ A smart contract has a harsher version of it. Anything computationally heavy is unaffordable on-chain, so the work has to happen elsewhere, and there's no empty socket two inches away on the same board. That distance is very important. The 8087 sat on the same board, so the processor could just believe whatever came back. A coprocessor running on separate hardware has to send back something that proves the answer. ✅ That's what the Brevis ZK Coprocessor does. It reads years of on-chain history for example, runs whatever computation you need across it, and returns the result with a zero-knowledge proof, so a contract gets an answer it could never have afforded to work out itself, and can check that answer in one cheap step.

Three common misconceptions about zero-knowledge proofs: 1️⃣ "It's all about privacy." Privacy is just one use. The bigger one is verification: proving a computation was done correctly without anyone having to redo it. Most ZK running in production today is there to make results checkable at scale. 2️⃣ "It hides everything." You choose exactly what to reveal and what to hold back. Prove you're over 21 while showing nothing else, or prove a balance covers a loan without ever revealing the number. Selective, down to the detail. 3️⃣ "It's too slow to be real." That was true for years. Today a zero-knowledge proof of an entire Ethereum block finishes in seconds. The engineering finally caught up to math that's been around since the 1980s. We walk through all of this properly, from blockchain basics up to real-time proving, in our From 0 Knowledge to Zero Knowledge series. Start from part 1 👇