Bitcoin
Bitcoin (BTC)
$64,258.00 1.5918
Bitcoin price
Ethereum
Ethereum (ETH)
$3,081.16 0.7665
Ethereum price
BNB
BNB (BNB)
$560.59 2.33264
BNB price
Solana
Solana (SOL)
$145.42 4.06386
Solana price
XRP
XRP (XRP)
$0.5052730 0.80352
XRP price
Shiba Inu
Shiba Inu (SHIB)
$0.0000228 1.00479
Shiba Inu price
Pepe
Pepe (PEPE)
$0.0000052 1.79823
Pepe price
Bonk
Bonk (BONK)
$0.0000151 2.79244
Bonk price
Bitcoin
Bitcoin (BTC)
$64,258.00 1.5918
Bitcoin price
Ethereum
Ethereum (ETH)
$3,081.16 0.7665
Ethereum price
BNB
BNB (BNB)
$560.59 2.33264
BNB price
Solana
Solana (SOL)
$145.42 4.06386
Solana price
XRP
XRP (XRP)
$0.5052730 0.80352
XRP price
Shiba Inu
Shiba Inu (SHIB)
$0.0000228 1.00479
Shiba Inu price
Pepe
Pepe (PEPE)
$0.0000052 1.79823
Pepe price
Bonk
Bonk (BONK)
$0.0000151 2.79244
Bonk price
Bitcoin
Bitcoin (BTC)
$64,258.00 1.5918
Bitcoin price
Ethereum
Ethereum (ETH)
$3,081.16 0.7665
Ethereum price
BNB
BNB (BNB)
$560.59 2.33264
BNB price
Solana
Solana (SOL)
$145.42 4.06386
Solana price
XRP
XRP (XRP)
$0.5052730 0.80352
XRP price
Shiba Inu
Shiba Inu (SHIB)
$0.0000228 1.00479
Shiba Inu price
Pepe
Pepe (PEPE)
$0.0000052 1.79823
Pepe price
Bonk
Bonk (BONK)
$0.0000151 2.79244
Bonk price
Bitcoin
Bitcoin (BTC)
$64,258.00 1.5918
Bitcoin price
Ethereum
Ethereum (ETH)
$3,081.16 0.7665
Ethereum price
BNB
BNB (BNB)
$560.59 2.33264
BNB price
Solana
Solana (SOL)
$145.42 4.06386
Solana price
XRP
XRP (XRP)
$0.5052730 0.80352
XRP price
Shiba Inu
Shiba Inu (SHIB)
$0.0000228 1.00479
Shiba Inu price
Pepe
Pepe (PEPE)
$0.0000052 1.79823
Pepe price
Bonk
Bonk (BONK)
$0.0000151 2.79244
Bonk price
SirWin
SirWin
SirWin

Syncing Bitcoin Nodes Instantly with Zero-Knowledge SNARKs

Syncing Bitcoin Nodes Instantly with Zero-Knowledge SNARKs

A new Bitcoin scaling solution, which leverages succinct blockchains and zero-knowledge cryptography, has been proposed by a developer earlier this month.  

The scaling proposal incorporates aspects developed and implemented in cryptocurrency projects Coda as well as zk-proofs, resulting in an implementation which supports an innovative type of Bitcoin client. The clients, which run this implementation, will be able to theoretically sync and validate the entirety of the chain in real time and with constant data size, regardless of the number of transactions, with full-validation security at nearly instant speeds.   

Additionally, the new proposal can be implemented without requiring any changes to the existing Bitcoin software and, if successful, would eliminate many, if not most, of the scaling concerns currently prevalent in the Bitcoin community.

A Quick Primer

The Bitcoin scaling debate has been a long-winded and seemingly never-ending issue. There is evidence to support that scaling concerns were brought up before Nakamoto even launched the Bitcoin network.

In 2008, when Satoshi first announced his project to the cryptography mailing list, a Canadian cypherpunk called James Donald was the first to comment and express his concerns that the system proposed by Nakamoto did not seem to scale. The entirety of the comment by Donald is:

“We very, very much need such a system, but the way I understand your proposal, it does not seem to scale to the required size. […] To detect and reject a double spending event in a timely manner, one must have most past transactions of the coins in the transaction, which, naively implemented, requires each peer to have most past transactions, or most past transactions that occurred recently. If hundreds of millions of people are doing transactions, that is a lot of bandwidth – each must know all, or a substantial part thereof.”

In a nutshell, this is the major premise of the scaling debate to this day. How can the Bitcoin network effectively support a large number of users without compromising security, as well as the ideologies which inform the network? At the time, Satoshi responded to Donald saying: “Long before the network gets anywhere near as large as that, it would be safe for users to use Simplified Payment Verification to check for double-spending, which only requires having the chain of block headers, or about 12kB per day.”

Nakamoto’s response is widely referenced as proof that he believes that on-chain scaling would be a viable solution for the network.

However, despite Nakmoto’s supposed endorsement of the on-chain mode of scaling, the community has been unable to reach a consensus regarding the issue. This state of affairs is one of the major reasons for the hard fork that led to the creation of the altcoin, Bitcoin Cash.

Off-chain scaling solutions require delegated trust while on-chain solutions require an inordinate, and perhaps an unsustainable amount of space. However, what if there was an alternative to this argument which could effectively scale the Bitcoin network without any changes to the underlying code as it currently exists?

What if there was a way to make the process of fully validating the state of the chain more efficient than delegating trust?

The Coda Connection

To fully understand the proposal, it is essential to first reference the Coda project. Coda is a cryptocurrency project aiming to provide a blockchain which remains at a constant size regardless of the number of transactions processed or the number of users on the network.

Coda prioritizes both decentralization and scalability. Due to the small and constant state of its blockchain, a wide array of clients are supported and can run a validation node on the Coda blockchain. This also applies to mobile clients which typically have very small storage capacities.

The Coda protocol claims to “compresses the entire blockchain into a tiny snapshot the size of a few tweets.” The protocol achieves this by utilizing recursive zk-proofs.

A zero-knowledge proof is a privacy-supporting cryptographic tool that generates an output and a proof from an input. This is similar to other cryptographic functions. However, in contrast to their counterparts, in zk-proofs, the proof, as well as the output generated from the function, is enough to verify that the function was honestly executed.

Zero-knowledge proofs are referred to in this manner because a verifier must not have access to the input to quantify that the function was executed. Moreover, a verifier does not need to confer any trust to the person running the function as the proof is held in the function itself. This privacy-enhancing aspect of zk-proofs has made them very valuable in the cryptocurrency sector, especially for privacy-centric projects.   

An interesting quality of zk-proofs is that they can implement any function. This includes the validation of other zk functions, or even themselves. A zk circuit that validates proofs from itself is called a recursive zk-proof.

Thus, using recursive zk-proofs, the Coda blockchain is able to achieve a succinct blockchain. A succinct blockchain is one that is able to maintain the same size regardless of any factors. In the Coda protocol, a node which syncs the blockchain also downloads and validates the entirety of the blockchain.

Instant Sync Full-Validation Bitcoin Nodes

The proposal published by Tyler Smith borrows heavily from the Coda protocol. However, Smith suggests building an overlay protocol, which runs on top of the actual Bitcoin blockchain and incorporates zk circuits.

Building a second layer preserves the security of the battle-tested Bitcoin network but allows for the people to “produce and publish proofs by processing mined blocks with a ZK circuit that implements Bitcoin’s transition rules.” Simply, the second network would utilize already authenticated blocks that have achieved final state on the Bitcoin network as a basis for further consensus.

Smith explains this as “Clients connect to this network, download and validate the most worked state hash, and are now fully synced and have an ‘authenticated state’ hash with its integrity verified. Clients that want a piece of the state could request it from state-holding nodes on the network.” In this way, the process works similarly to standard full node syncing. However, in the second layer, the state calculated in the network would be authenticated by the recursive Zk proofs.

Through this implementation, clients are able to fully validate the entirety of the chain state because, as discussed earlier, syncing in this regard refers to downloading and authenticating the entire chain. Additionally, recursive Zk proofs are fast and thus nodes have the entire state in a few seconds. To best understand the proposal, one can think of it as a proof-of-proof-of work.

The proposal is in an early, ideation stage. However, if the developer is able to produce a viable proof-of-concept, which prioritizes both decentralization and security, may finally be here.