Thread

Running Bitcoin ZK Knots, baby! We've successfully run a POC verifying a STARK proof of Bitcoin's mainnet block #1 inside a modified Bitcoin Knots client. The proof validates critical consensus rules: - Timestamp - Chain difficulty - Block difficulty - Proof of Work Here’s the technical flow: - A Cairo program defines the block header consensus rules & generates the execution trace:
GitHub
raito/packages/assumevalid/src/lib.cairo at 1cca29f0435ef74b34c8cca29f76393c7079b898 · starkware-bitcoin/raito
Bitcoin ZK client written in Cairo. Contribute to starkware-bitcoin/raito development by creating an account on GitHub.
 - The STWO prover generates the STARK proof from the trace:
GitHub
GitHub - starkware-libs/stwo-cairo: Prove Cairo programs with the blazing-fast S-two prover, powered by the cryptographic breakthrough of Circle STARKs.
Prove Cairo programs with the blazing-fast S-two prover, powered by the cryptographic breakthrough of Circle STARKs. - starkware-libs/stwo-cairo
 - A modified ProcessNewBlockHeaders function in Bitcoin Knots performs the proof verification:
GitHub
bitcoin/src/validation.cpp at c2505b4c9a3a420634de651220f76285e0b7ee64 · starkware-bitcoin/bitcoin
Bitcoin Knots enhanced Bitcoin node/wallet software - starkware-bitcoin/bitcoin
 The main purpose of this POC was to test the integration of our Rust-based proving stack into the C++ codebase. The ultimate vision? To improve Initial Block Download (IBD) dramatically by allowing the entire chain's validity to be verified with a single recursive proof. Once Raito is fully equipped with recursive proving and strong performance, we'll be back to implement a full, real-world IBD with ZK verification enabled. Stay tuned! Follow our StarkWare Bitcoin Github for updates:
GitHub
StarkWare Bitcoin
StarkWare Bitcoin Exploration Team. StarkWare Bitcoin has 21 repositories available. Follow their code on GitHub.
image image image

Replies (6)

↩ replying to Gunnar Stødle
Depends what you call a decent time window. It’s still a challenge today mostly because of sha256 which is horrible to prove and of course we have a prove an insane amount of sha256 hashes. We will likely have at some point to built a sha256 built in to speed things up drastically. Right now the proof is only the block header not the full block, we need to remove the sha256 bottleneck to be able to do this efficiently for the full block.
↩ replying to A₿del fgu
Btw being able to generate the proof on a normal desktop is not really required in the sense that as the node what you need to do is to verify the proofs and this is very efficient and fast in a small device. For the proof generation it’s still better to delegate it to bigger machines and have them aggregate the proofs and do the recursion to amortize the cost. It remains trustless anyway. But still we want to lower as much as we can the requirements to be able to generate the proofs