Using zero-knowledge proofs, ZeroSync seeks to radically reduce the computational cost of bootstrapping a fully validated Bitcoin client.
This is an opinion editorial by Shinobi, a self-taught educator in the Bitcoin space and host of a tech-oriented Bitcoin podcast.
Zero-knowledge proof (ZKP) is something that has been discussed here for over a decade. Even Satoshi Nakamoto himself knew they were primitives that could be used, and the idea of applying them to Bitcoin was discussed in early 2010 when it was still active.
In my mind, they are definitely one of the “long-term” features of Bitcoin that never have a solid concrete implementation, but they can be done and create a lot of value and utility for the work they do. those people. Who would not think that cryptographically proving that some statement is true, or that you have some information without revealing it, is very important? Especially when you can do something so complicated with relatively little evidence?
A complex and large smart contract/script to lock down bitcoins will eventually need to proportionally insert witness data into the blockchain in order to spend the coins. That can be a huge amount of data, or it can be data that is expensive to quantify and verify. This is a conventionally held blockchain tradeoff: The more complex conditions you want to require for your coins, the more expensive it is to verify or the more data you need to spend.
ZKPs are always held as a way to change, so that a very complex script situation can be proven with a small or constant amount of data that, when verified, shows with certainty that the situation is met. This is due to the fundamental asymmetry between proof and verification using ZKP.
To give a concrete example that is as simple as possible, the signature ring is a very basic form of ZKP. The idea is to provide a signature that can be done with one key in a large group of keys without having to unlock which one. By defining the signature algorithm correctly, a single signature can be generated that can be verified against all sets of public keys and shown to have been produced by one of them but not clearly.
That, at a very high level, is how ZKP works. You build a protocol to prove something, which includes a way for the person asserting the fact to provide evidence and the same person asserting to verify. In the case of ring signature, it is a signature algorithm that validates against a set of public keys without specifying which one. It’s a key point: You prove something without actually revealing the information that would conventionally prove it (in this case, the signature of one public key).
Introducing ZeroSync
After years of discussing the possibility, progress is finally being made to bring ZKP to Bitcoin in the form of the ZeroSync project. The interesting part though is that it has nothing to do with locking or throwing coins. There is no ZKP OP code coming, or any way to lock the coins in the chain using it. This is intended to help full nodes complete the initial synchronization faster.
This is a huge undertaking and not something that will happen all at once. As I said above in describing the signature ring, ZKP requires a protocol designed for each specific thing that you are trying to prove. There is no “zero-knowledge proof” that can prove anything arbitrarily, because everyone needs their own unique proof protocol to adequately validate a particular type of computation or statement about some type of data.
ZeroSync is working on building three proofs that will, when completed, provide complete verification of historical blocks without requiring users to download and process them. The great part about this is that absolutely no consensus changes to the Bitcoin protocol are required to accomplish this. Everything happens only at the application level, that is, in the software you run. It still validates and implements the same consensus rules as conventional Bitcoin nodes. Once done, anyone can choose to use that ZeroSync node and verify that the downloaded set of UTXOs is valid. Or you can just keep running Bitcoin Core and validate everything the conventional way.
Evidence Header Block
The first proof that the ZeroSync team did, which should now be released, involves the validity of block headers. It proves that each block in the chain actually meets the difficulty requirement in time, and tracks each difficulty change to ensure that each block meets the appropriate target. It will also introduce huge benefits to the Simple Payment Verification (SPV) wallet architecture in the process.
Each Bitcoin block is essentially a Merkle tree of each transaction in the block, plus a header that contains some other data and the root of that Merkle tree. ZeroSync’s proof of block header will, in the construction process, also implement the Merkle tree each individual block header in the chain. So, in the same way that every transaction with a Merkle tree, which leads to a single hash, every block in the blockchain will be committed to a single hash using the Merkle tree. This will allow for a more compact SPV proof. Now, to implement SPV, the user must keep a complete copy of each block header in the block and, when the transaction and the Merkle tree path from it to the block header are available, it can be used to verify that it has actually been committed. blocking.
With proof of block headers, users do not need to have a copy of the block header to verify that a transaction has taken place on the blockchain. They simply add the Merkle path of the block header that the transaction is in the root hash of the current Merkle blockchain tree and provide the same security guarantee combined with ZKP of the block header proof validity.
Block Content Verification
The second proof focuses on the actual validity of the content of the block, but like the Assume Valid function of Bitcoin Core, it does not prove the validity of the witness data. It will check and verify transaction size limits, coin inflation rules, etc., but does not provide proof that signatures, hash keys and other witness data are correct. However, this proof will integrate Utreexo in order to integrate the set of UTXOs at each block height into the overall ZKP protocol for the chain.
The first proof will only show that the block header is correct, but it doesn’t say anything about the supply of coins or UTXO sets. This second proof will allow the UTXO set to be sent to the user with ZKP proving that all the block headers leading to the UTXO set are valid, including the commitment for each UTXO set and all the changes proving that each transition from one to the next is also valid. This will allow full synchronization up to the standard Bitcoin Core Assumption of high Validity by simply setting the UTXO at the height of the block and a small proof, all with the same trust model as downloading it all and verifying the full block directly.
Verify Every Piece of Witness Data
Finally, the final proof will incorporate ZKP for block headers and build on top of ZKP for Assume Valid to include proof of the validity of each piece of witness data in the history chain. After this stage, technically, nodes using the final ZeroSync proof system will be able to bootstrap with a single proof and a set of UTXOs with a stronger verification model than Bitcoin Core by default.
Normally, Bitcoin Core uses the default Assume Valid block height to bypass witness validation for any previous block (although users can omit assumevalid=0 and validate the witness for each block), but ZeroSync nodes will have a valid proof for each block. witness data.
The only problem with this last proof is that the actual computational complexity of constructing it is higher than the previous two. Proof verification is simple and fast, it only requires ZKP and a verifier, but building it requires taking complete, raw data that will be conventional evidence (in this case, the entire historical blockchain) and actually processing it to build ZKP. for that. Adding witness data to evidence is now very expensive. To achieve the goals of this roadmap, many optimizations are required. But, let’s just say it’s not possible. This project will still provide a massive amount of value in allowing users to “zero sink” until the standard Assume Valid block height and then conventional verification of the rest of the chain from there to tip.
Reducing Bitcoin Computing Costs
If its roadmap is successful, this project can have a massive effect in reducing the computing costs for Bitcoin users to bootstrap Bitcoin clients with validation. Since the current block size is almost 500 GB, there is a limiting fee that prevents many users from running a validating client. You need to have bandwidth available to download, and in many parts of the world, bandwidth is still very expensive. You also need a device that is powerful enough to process the data, and in many parts of the world, people have nothing but their smartphones in terms of digital devices that can connect to the internet.
ZeroSync can bring costs down to a few gigabytes for UTXO sets and ZKP proofs so small that they can fit on a 1.44 MB floppy disk. And it doesn’t require any consensus changes or forks to do so.
Now, to wrap things up, I’d like to make a silly point: ZeroSync is built using the Cairo language developed by Starkware, a Turing-complete language that can be used to build zero-knowledge systems for arbitrary computations. Starkware is a ZKP development company for the Ethereum ecosystem, specifically developing a zero knowledge rollup as a second layer solution. ZeroSync builds a ZKP-verified sync client for Bitcoin that may be the first time real material development from an altcoin actually results in valuable improvements that re-engage into the Bitcoin ecosystem.
ZKPs can be a very powerful tool for Bitcoin even if they are not integrated into the consensus layer, or used as a way to lock and spend bitcoins. Hopefully, ZeroSync can achieve its roadmap goals and produce a fast sync client that the team is working on. After all, there are other things you can do to spread ZKP in the Bitcoin ecosystem besides bootstrapping nodes.
This is a guest post by Shinobi. Opinions expressed are entirely their own and do not necessarily reflect those of BTC Inc or Bitcoin Magazine.