How do you verify that a service is running the code it publishes?
Vitalik Buterin’s article “The importance of full-stack openness and verifiability” is a great piece on something we desperately need: ways to verify that the systems around us behave as intended. He discusses formal verification of software, open source software, and inspecting chips with techniques like IRIS and X-ray scanning. He also discusses cryptographic approaches such as ZK-SNARKs, so the vision goes well beyond publishing code. What the article doesn’t walk through is a practical source-to-runtime workflow for a remote service: independently rebuild the published source, then match the result to hardware attestation from the live system. That’s the gap I want to focus on here.
Elon Musk proposed a related idea: open source the code for Twitter (X), then invite experts to verify “what is running”.
“Trust through total transparency” is what we should strive for. But most people, even leading engineers, still underestimate how far software verifiability can go. The practical question left unanswered here is how to prove that a live system is running the published code. That’s where verifiable compute comes in.
You can open source your code, review it, scan it and formally verify it. Then, typically, it gets deployed into a black box with no way to reliably prove what made it into the server.
Hardware enclaves, or trusted execution environments (TEEs), help close that gap by isolating software from the surrounding host. Remote attestation provides signed evidence of what software that protected environment contains, expressed as hashes. There’s a trap here, though. An attested hash is one thing. Independently tying it back to the source code requires reproducible builds.
(Yes, I know about TEE.fail. We wrote about it in TEE.fail does not make confidential computing security theatre. Just because someone can show up at your house with a socket wrench and demand your password doesn’t mean you should stop using passwords.)
Many companies claim they’re “verifiable” when in reality their code is open, or their software runs inside confidential compute. Neither alone gives you the reliable connection from source code to running software. People want to use the term because it represents an extremely powerful concept. But the connection has to be there or it’s simply hand waving.
Publishing source or attesting a runtime leaves a gap on its own. Reproducible builds let an independent verifier derive the expected measurements from the published source and compare them with verified attestation evidence.
“Wait, you’re saying we’re not doing this today?” Yes, most services today are black boxes - it’s not possible to reliably verify what’s inside. “Trust me bro” is how the internet operates today.
“But but monitoring…” Monitoring can help detect attacks, but it doesn’t give an outside user independent proof of what’s running. It’s a software “camera” pointed at a system, and the camera itself raises the same question: how do you verify the software doing the monitoring? Major attacks such as SolarWinds happened despite monitoring. Observation alone is not an integrity guarantee.
Think about it this way: Elon opens up the source code and experts review it. Then a system admin, a compromised build pipeline or an attacker with stolen credentials changes what ends up on the servers. Even if deployment goes as planned, the code could still be modified afterward. Reviewing the source doesn’t rule out any of this.
True verifiability means getting cryptographic proof tying the current runtime to the desired code, not just opening code and hoping that’s what’s running on a server.
This requires reproducible builds, something you would intuitively expect: same source, same build inputs, same bits - but this is not how the vast majority of software today works. Our definition goes further: we build everything from source, including the toolchain. No precompiled binaries get a free pass.
If you want to make your software reproducible and your systems verifiable, come talk to us. We’ve built software to make this easy.
