The bitcoin network we know and use today brings to the table a lot of unique properties you won’t find in other payment networks. It is the first and only decentralised network that is fully verifiable with very little computing power needed to do so, but with that comes a trade-off.
Bitcoin can only process a limited number of transactions per block, and about six transactions per second are as good as they will get on the base chain. There have been upgrades to help improve data storage on the network, such as SegWit and Taproot, while options like UTreeXOs have been proposed as a method of improving the use of block space.
Another method of improving bitcoin scaling comes from a type of rollup known as ZK proofs or zero-knowledge proofs, a variation of optimistic rollups.
What are zero-knowledge proofs?
A zero-knowledge proof is a verification method that takes place between a prover and a verifier. In a zero-knowledge proof system, the prover can prove to the verifier that they have knowledge of a particular piece of information (such as the solution to a mathematical equation) without revealing the information itself hence the name. These proof systems can be used by modern cryptographers to provide increased levels of privacy, security and, of course, reduce the data footprint.
Where do zero-knowledge proofs come from?
The concept of a zero-knowledge proof was first described in a 1985 MIT paper published by Shafi Goldwasser and Silvio Micali. They demonstrated that it was possible to prove some properties of a number without disclosing the number or any additional information about it.
This paper also introduced the mathematically significant finding that interactions between a prover and a verifier could reduce the amount of information required to prove a given theorem.
How does a zero-knowledge proof work?
Zero-knowledge proof or protocol is a way for a “prover” to convince a “verifier” that a statement about some secret information is true without revealing the secret itself.
Example
A verifier presents a prover with a hash H and would like the prover to prove that it has the secret data that hashes to H. The prover produces a zero-knowledge proof that convinces the verifier that it has the data that hashes to H without revealing the data itself to the verifier.
What are the different types of zero-knowledge proofs?
There are two main types of zero-knowledge proofs:
- Interactive zero-knowledge proofs: In this type of ZKPs, the prover and the verifier interact several times. The verifier challenges the prover, who provides replies to these challenges until the verifier is convinced
- Non-interactive zero-knowledge proofs: In this type of ZKPs, proof delivered by the prover can be verified by the verifier only once at any time. This type of ZKPs requires more computational power than interactive ZKPs. Non-interactive proofs are most preferred due to the ease of user experience.
What are the challenges of zero-knowledge proofs?
- No 100% guarantee:Â Even if the probability of verification by the verifier while the prover is lying can be significantly low, ZKPs don’t guarantee that the claim is valid 100%. As demonstrated above, the probability of a prover lying decreases in each iteration of the ball-picking process, but it can never reach zero. Thus, zero-knowledge proofs aren’t actual proofs in a mathematical sense.
- Computation intensity: Algorithms used are computationally intense as they require many interactions between the verifier and the prover (in interactive ZKPs), or require a lot of computational capabilities (in non-interactive ZKPs). This makes ZKPs unsuitable for slow or mobile devices
- Limited: The protocols for ZKPs usually rely on mathematical equations and numerical answers. Any other method requires a translation
- Requires large computing power: There are around 2000 computations per ZKP transaction that each require a certain amount of time to process
- Restricted: If the originator of a transaction forgets their information, all the data associated with it is lost
Where zero-knowledge proofs fit into bitcoin
Protocols based on ZK-proofs require the blockchain to be the verifier; the verifier is a function that takes a zero-knowledge proof and returns true/false based on its correctness.
Instead of an OP_STARK operator in L1, in this case, the bitcoin base chain, one could think of compiling the OP_STARK as the function f in the protocol above, such as second layer solutions.
Since bitcoin does have a limited scripting language on the base layer, ZK proof would rely on the ability to create covenants on the base layer. A covenant with a bounded “recursion depth” would be sufficient to express OP_STARK, which implies the ability to express arbitrary functions within contracts using the challenge protocol.
One advantage of this approach is that no new cryptographic assumptions are added to bitcoin’s layer one even if OP_STARK does require it; moreover, if a different or better OP_STARK2 is discovered, the innovation can reach layer two contracts without any change needed in layer 1.
Note: Covenants are already available on the Liquid side chain, so creating a ZK environment tethered to this side chain is also possible.
Do your own research
If you want to learn more about optimistic rollups on bitcoin, use this article as a jumping-off point and don’t trust what we say as the final say. Take the time to research and check out the resources below.
