Video wird geladen...
Video konnte nicht geladen werden
✨Introducing ZKLean, formal verification for interconnected software✨ Frontier AIs keep finding critical bugs everywhere. Formal verification is the obvious cure, but what if your software has dependencies like npm packages or API endpoints? ZKLean is the solution👇
11,060 Aufrufe • vor 17 Tagen •via X (Twitter)
14 Kommentare

Today, formally verifying software that depends on external packages or API endpoints is impractical. Even if you used Lean to model an API you're using, the API's team could abruptly change its behavior and break your assumptions. Your proofs would break without notification.

What if the API you're using is also formally verified, and they release their Lean proofs? Checking the Lean proofs on every release is expensive. They can easily be 10k-100k lines for production software.

ZKLean uses succinct (356 bytes) zero-knowledge proofs that make verifying a formal spec take ~250ms. Instead of giving a proof of the spec, ZKLean proves that *some* proof exists for the spec. 1000x efficiency🫡

This means you can: - Cheaply check formal specs released by your dependencies - Ensure your formal proofs don't break on every release - Cheaply prove to someone your software is formally verified Repo:

I also made a library called HTTPV (HTTP-Verified) HTTPV lets your server serve ZKLean certificates for each API endpoint, and lets your clients verify those certificates cheaply. Drop-in replacement for Bun.serve() Repo:

Are you considering trying to get funding from @thedaofund in the ETHSecurity Initiatives Round?

If you build from scratch with bend 2 you don't need to rebuild to prove in lean

Even bend apps could have dependencies tho

can this also hide the definition of a computable function, that you prove some properties about, in zk?

right now it's not using the hiding feature since it's utilizing the succinct verification of computation part, but I don't see why not

Ken Thompson's "Reflections on Trusting Trust" from 1984, made literal. He showed that a compiler can insert a backdoor into the programs it builds, and into future copies of itself, with no trace in any source code. His conclusion was "you can't trust code that you did not totally create yourself." Then he pointed out that nobody creates the whole stack themselves.

interconnected software verification is the missing puzzle piece. stellar work

this is next level innovation broo

HTTPV's trust model says the certificate covers the Lean model; clients still trust the live handler to match it. I'd expose that boundary in the API result, so 'verified' isn't read as proof of this particular response.

