Using zero-knowledge proofs, ZeroSync seeks to radically reduce the computational costs of booting up a fully-validated Bitcoin client.
This is an opinion editorial from Shinobi, a self-taught educator in the Bitcoin space and tech-oriented Bitcoin podcast host.
Zero knowledge proofs (ZKP) are something that has been discussed in this space for over a decade. Even Satoshi Nakamoto himself was aware of them as a primitive that could be used, and the idea of applying them to Bitcoin was discussed as early as 2010 when they were still active.
In my opinion, they’ve always been one of the potential “long-term” features of Bitcoin that never really had a solid, concrete implementation, but could end up working and creating a tremendous amount of value and utility for the work done on it. implementation. them. Who wouldn’t think that cryptographically proving that some claim is true, or that you possess some information without revealing it, is highly valuable? Especially when you can do it for very complicated things with relatively small tests?
Complicated and large smart contracts/scripts to lock up bitcoin ultimately require putting proportionally large token data into the blockchain to spend those coins. That can be literally huge amounts of data, or it can also be data that is expensive to calculate and verify. This is a conventional blockchain trade-off: the more complicated the condition you want to enforce to spend coins, the more expensive to verify or the more data is required to spend them.
ZKPs have always been presented as a way to change that, allowing highly complicated script conditions to be tested with a small or constant amount of data that, when verified, definitively shows that those conditions were met. This is due to the fundamental asymmetry between testing and verifying using ZKP.
To give a concrete example that is as simple as possible, ring signatures are a very basic form of ZKP. The idea is to provide a signature likely made by one key within a large group of keys without revealing exactly which one. By correctly defining a signature algorithm, a single signature can be produced that can be verified against the full set of public keys and shown to have been produced by one of them, but obscuring which one.
This is how ZKPs work at a very high level. You build a protocol to prove something, including a way for the person stating a fact to provide proof and for the person to whom the statement is made to verify it. In the case of ring signatures, it is a signature algorithm that validates against a set of public keys without specifying which one. That’s the key point: prove something without revealing the information that would conventionally prove it (in this case, a signature of a single public key).
Introducing ZeroSync
After years of discussing the possibilities, progress is finally being made to bring ZKP to Bitcoin in the form of ZeroSync Project. Although the interesting part is it has nothing to do with blocking or spending coins. There is no ZKP OP code coming, nor any kind of way to block coins on chain using them. It is being applied to help full nodes achieve a much faster initial sync.
However, this is a big undertaking and it is not something that is going to happen all at once. As I said earlier when describing ring signatures, a ZKP requires a protocol to be designed for each specific thing it’s trying to test. There is no “zero-knowledge proof” that can arbitrarily prove anything, because each needs its own unique proof protocol to sufficiently validate a specific type of calculation or claim about some type of data.
zero synchronization is working on iteratively building three tests that, when completed, will provide full verification of the historical blockchain without requiring the user to download and process it. The great part about this is that absolutely no consensus changes to the Bitcoin protocol are required to accomplish this. It all happens simply at the application level, that is, in the software it runs. It still validates and implements the exact same consensus rules as a conventional Bitcoin node. When complete, anyone can simply choose to use such a ZeroSync node and ensure that the UTXO set you download is valid. Or you can just keep running Bitcoin Core and fully validate everything in the conventional way.
Block header tests
The first test the ZeroSync team is working on, which should be published right now, covers the validity of block headers. It proves that each block in the chain has successfully met the difficulty requirement at that time, and keeps track of each difficulty change to ensure that each block meets the appropriate target. This will also introduce a huge benefit to the simplified payment verification (SPV) wallet architecture in the process.
Each Bitcoin block is essentially a Merkle tree of each transaction in the block, plus the header that contains some other data, and the root of that Merkle tree. ZeroSync’s block header test, in the build process, will also apply such a Merkle tree to each individual block header in the chain. So, in the same way that each transaction is committed to a Merkle tree, leading to a single hash, each block on the blockchain will be committed to a single hash using a Merkle tree. This will allow much more compact SPV tests. Currently, to implement SPV, a user must maintain a full copy of each block header on the blockchain and, when given a transaction and the Merkle tree path to the block header, can use that to verify that really engaged in a block.
With block header proofs, users would not even need to have a copy of the block headers to verify that a transaction is committed within the blockchain. They simply add a Merkle path from the head of the block the transaction is in to the root hash of the current blockchain Merkle tree and provide the same security guarantees combined with a block head proof validity ZKP.
Verification of the content of the block
The second test focuses on the actual validity of the block contents, however, like the assume valid function of Bitcoin Core, it does not test the validity of the token data. It will check and verify transaction size limit, coin inflation rules, etc., but does not provide proof that signatures, hash locks, and other token data are correct. This test, however, will incorporate utreexo to integrate the set of UTXOs at each block height into the global ZKP protocol of the chain.
The first test would simply show you that the block headers are valid, but that says nothing about the coin supply or the UTXO pool. This second test would allow a UTXO set to be delivered to a user with a ZKP proving that all block headers leading to that UTXO set are valid, as well as including a commit to each UTXO set and all changes proving that each transition from one to the other is also valid. This would allow full sync up to Bitcoin Core’s default Valid Assume height with just the UTXO set to that block height and a little test, all with the exact same trust model as downloading all of that and checking full blocks directly.
Verification of each piece of witness data
Lastly, the final proof will incorporate the ZKP for the block headers and build on the ZKP for Assume Valid to include proof of the validity of each witness data in the historical chain. After this stage, technically speaking, a node using the final ZeroSync test system will be able to boot with a single test and UTXO array with a stronger verification model than Bitcoin Core by default.
Normally, Bitcoin Core uses the default Assume valid block height to skip token validation for any previous blocks (although the user can override with assume valid = 0 and validate tokens for each block), but a ZeroSync node would have proof of correctness for each block. witness data.
The only problem with this last proof is that the computational complexity to build it is much higher than the previous two. Verifying a proof is simple and fast, requiring only the ZKP and the verifier, but actually building it requires taking the entire raw data that would constitute a conventional proof (in this case, the entire historical blockchain) and processing it to build a ZKP . for it. Adding eyewitness data to evidence is currently very expensive. To achieve this roadmap goal, a lot of optimization will be required. But, let’s say that it is intractable to do so. This project would still provide a lot of value by allowing users to “zero sync” up to the height of the default Assume Valid block and then conventionally check the rest of the chain from there to the tip.
Reduced Bitcoin Computational Costs
If its roadmap is successful, this project could have a massive effect in reducing computational costs for Bitcoin users to start a fully validated Bitcoin client. Since the blockchain is currently almost 500 GB in size, there is a very restrictive cost that prevents a large number of users from running a validation client. You must have the available bandwidth to download it, and in many parts of the world, bandwidth is still prohibitively expensive. You also need a device powerful enough to process that data, and in many parts of the world, people have nothing more than a smartphone in terms of digital devices that can connect to the Internet.
ZeroSync could bring that cost down to a few gigabytes for the UTXO suite and a ZKP test so small it could fit on a 1.44MB floppy disk. And it doesn’t require consensus changes or forks to do so..
Now, in closing, I want to make a kind of cheeky point: ZeroSync is built using the Starkware-developed Cairo language, a Turing-complete language that can be used to build zero-knowledge systems for arbitrary computations. Starkware is a company that develops ZKP for the Ethereum ecosystem, specifically developing zero knowledge stacks as a second layer solution. ZeroSync, which builds a ZKP-verified sync client for Bitcoin, could end up being the first time that an actual material development of an altcoin actually yields a valuable enhancement that folds into the Bitcoin ecosystem.
ZKPs can end up being a very powerful tool for Bitcoin, even without building them into the consensus layer, or using them as a way to lock up and spend Bitcoin. Hopefully, ZeroSync will be able to achieve its roadmap goals and produce the quick sync client your team is working on. Afterwards, there is even more than could be done to implement ZKP in the Bitcoin ecosystem in addition to starting a node.
This is a Shinobi guest post. Opinions expressed are entirely their own and do not necessarily reflect those of BTC Inc or Bitcoin Magazine.
