Bitcoin Nodes Now One Step Closer to Instant Sync
Bitcoin Nodes Transformed: ZeroSync’s Lightning Revolution!
Bitcoin light clients are now able to sync to the tip of the blockchain nearly instantly, thanks to a new development enabled by bitcoin startup ZeroSync and their work in zero-knowledge (ZK) proofs. Ultimately, ZeroSync seeks to enable full nodes to do the same.
ZK proofs allow a prover to generate a short mathematical statement that proves to a verifier that a given computation is correct without revealing any details about such computation. Constructing this proof can be computationally expensive, but the statement it provides is always very compact, regardless of how large the data served as an input to the proof calculation,– enabling blazing-fast verification of the correctness of that data with mathematical certainty. In Bitcoin, this math trick can be very useful to nodes and clients.
Bitcoin full nodes are notoriously required to download and verify every single piece of data that makes up the blockchain, from its inception in January 2009 to the present day. Due to the difficulty in scaling such a comprehensive setup, Satoshi Nakamoto envisioned in the Bitcoin white paper a different type of client that would be able to verify their incoming payments without running a full node.
Bitcoin light clients leverage a simplified payment verification (SPV) mechanism. Upon receiving a payment, the client queries network nodes to get the headers of the longest chain. Then, it is able to find the block to which the incoming transaction was added –– which shows network nodes have accepted it as valid. As more blocks get added to the chain after that one, the more confirmations the light client gets that the payment was valid and accepted by the network into a block.
Without any need for a consensus change to Bitcoin, ZK proofs improve this setup by compressing the headers into a single proof.
Similarly to how each bitcoin block effectively compresses its transactions’ data into a Merkle tree and includes the root of that tree in its header, ZeroSync’s work takes every bitcoin block header and batches them into another Merkle tree. This process allows for the chain of headers to be synthesized into a short and lightweight piece of data –– the proof.
The header chain proof is able to quickly prove whether a given block header is included in the chain. A block header can then be leveraged to attest whether a specific transaction was included in that block. This process is very similar to the SPV method described previously but more efficient. Instead of having to keep a full copy of every header in the blockchain for SPV, with ZK proofs the light client only needs to store that small header chain proof, being able to sync to the latest state of the chain in seconds.
Ultimately, what the header chain proof is able to prove is that each block in the chain met the difficulty requirement at the time it was mined. In other words, verifying the header chain proof allows the user or client to be sure that each Bitcoin block up to that given height was mined correctly and met the mining difficulty criteria at the time.
Releasing the first complete header chain ZK proof was ZeroSync’s first milestone. To achieve their bigger vision ––
provide a full verification of the historical blockchain to full nodes without requiring users to download and process it –– the team needs to tick two more checkboxes. The second would take the header chain proof up a notch and enable a node to sync similarly to the Assume Valid function of Bitcoin Core. The third and final one would provide the complete Bitcoin blockchain sync envisioned.
Assume Valid is an option in Bitcoin Core, enabled by default, that assumes that all scripts up to a given block height are valid. This means that new full nodes syncing the blockchain with initial block download (IBD) get to skip the verification of scripts from the Genesis block until the block height is established by the Bitcoin Core client at a given release.
These scripts are the Witness data part of the transactions ––
mostly the signatures resolving the locking scripts and unlocking the funds to be spent, as well as timelocks and other programmed spending conditions. Users do have the option to set `assumevalid=0` and force their client to perform full verification of all scripts, in addition to the verification of the other block contents. However, the general and fairly safe assumption behind enabling Assume Valid by default is that enough proof of work has been shown up to that given block height that makes it fair to believe the scripts preceding it are valid.
ZeroSync’s middle ground offering, when complete, will let Bitcoin users sync their nodes similarly to a default Bitcoin Core IBD. The node downloads all data from Bitcoin’s inception to the present day, but only verifies witness data after the assumevalid height. The UTXO set is also a necessary part of the equation. To solve for that, ZeroSync leverages Utreexo, a project that also seeks to increase efficiency in syncing Bitcoin nodes.
Utreexo provides the latest UTXO set at a given block, and ZeroSync is able to add that into its ZK proofs-based setup. The result is a much shorter header chain proof and a more compact and efficient UTXO set, which clients can leverage to satisfy their payment verification needs.
The team’s top-tier offering will take things a step further and allow nodes to synchronize to Bitcoin’s latest state without assuming any script is valid. Using ZK proofs, full nodes would be able to achieve a much faster initial sync with perhaps even greater security assurances than Bitcoin Core’s default setting, which uses assume valid.
It is important to note that even if Bitcoin Core users disable assume valid ––
verifying all scripts and achieving similar security assumptions to ZeroSync’s top-tier offering ––
the latter’s greater value proposition is still the substantial gain in efficiency and speed for verifying all this information. While the bitcoin blockchain currently holds 510GB of data, ZeroSync’s approach will, when complete, enable a much quicker process given the production of a short and lightweight proof of slightly over 1MB ––
An improvement in the performance of several orders of magnitude over a standard IBD using Bitcoin Core while ensuring that the exact same consensus rules are followed.
Gains in efficiency will only become more important as the Bitcoin blockchain keeps growing block after block. Eventually, downloading and verifying the entire chain could become prohibitive in terms of bandwidth and storage –– especially in parts of the world where access to high-speed internet and bigger hard drives is limited or expensive.
