As blockchain adoption grows, its scalability problem will become more apparent. Thankfully, ZK proofs are well positioned to provide key parts of the architecture to the industry's solution.
While ZK proofs were introduced in the 80s, they lend themselves to crypto very well because they have the ability to verify correctness and faithfulness of a system while maintaining privacy and efficiency. Blockchains and apps that run on blockchains require higher degrees of efficiency because the system is decentralized, ie, multiple parties need to agree before a consensus is reached.
Being a public resource, blockchains also need to address demand for privacy as not every user of the infrastructure wants their information to be public. ZK proofs are a technology that addresses both privacy and scalability, but there are many ways to skin a cat. You may hear the terms Groth16, PLONK and STARK being used more frequently. In this article, we focus on a proof protocol called Groth16 and how we built our own Groth16 verifier to run on Bitcoin.
Groth16 was created in 2016 by Jens Groth, a famous cryptographer, and saw early adoption in Zcash. It was designed to optimize the efficiency and practicality of ZK proofs, particularly in resource-constrained environments like blockchains. It remains one of the most commonly used zk-SNARK protocols today due to its balance of small proof size, fast verification, and its wide adoption in privacy-focused and scalability-driven applications.
In particular, Groth16 is known for:
- Succinctness: The proof size is very small, around 100-200 bytes, regardless of the complexity of the computation being proven. The proofs consist of only a few elliptic curve points (which are small in size, and we’ll explain this below), yet they represent complex computations. The verifier can check these small proofs efficiently using pairings, ensuring scalability in applications like blockchains.
- Non-interactivity: Once a proof is generated, the verifier can check it without any further interaction from the prover. The proof is only generated once by the prover, and there is no need for additional back-and-forth communication. This means fewer transactions onchain. Groth16 addresses this for Bitcoin in particular since blockspace is scarce, and Tapscript is inefficient for more complex processes. It also enables all nodes to independently verify the proof without the need to engage with the prover. This makes the system scalable, as multiple verifications can happen simultaneously.
- Efficiency: Verification is computationally lightweight, requiring only a few points of confirmation, making it faster to verify and therefore scalable. No matter how large or complex the computation being proven, the verifier only needs to check a few pairing equations. This is crucial in systems like blockchain, where nodes need to verify thousands of proofs in real-time.
Groth16 and Elliptic Curve Cryptography - follow the Secret Path
In order to generate said proof, you first need to construct some kind of cryptographic answer sheet - something that generates random and private parameters that you can check proofs against.
Groth16 proof verification relies on elliptic curve cryptography (ECC). Put very simply, think of an elliptic curve on a coordinate system as a path. Each point on that path is satisfied by combining some mathematical variables into an elliptic function. These points and the relationship between these points form a kind of map for how we can trace back validity. For the encryption we also need to come up with some secrets, data that is used to find the right points on the path but that are not known publicly.
These secrets are numbers that are used to manipulate the points on the path, creating a secret new mapped path. They are called scalars, a fancy math word for quantities that only have magnitude. This is a crucial part because these scalars need to remain an absolute secret for the proof system to maintain its integrity.
ECC is also built on something called Elliptic Curve Discrete Logarithm Problem (ECDLP) - think of this as a very difficult problem to solve, even with significant computing power, preventing bad actors from back engineering the system and deriving the scalars.
For Groth16, the environment in which you set these original scalars need to be absolutely secure. This is why it is said that Groth16 needs a trusted setup. Typically this setup is done in an MPC environment, where each participant only has part of the scalar set. Afterward the set of numbers are destroyed and what you are left with is a public parameter, called a common reference string (CRS), which is used to verify the proof. We won’t go into the mathematics of this verification in this post, but by checking the relationship between a small set of points on the elliptical curve the verifier can see if the correct scalars have been used.
Groth16 is Everywhere in Crypto
There are many use cases for Groth16 in crypto. It has been widely used in privacy preserving transactions (Zcash was an early adopter), where sender, recipient and amount are completely hidden from the public blockchain.
It has also been used for ZK rollups - bundling multiple transactions offchain and drastically reducing the data storage/transaction cost onchain. We also see it in verifiable computations both on and off chain (ex. decentralized oracles) or zk-SNARK based smart contracts - proving that certain computations like fetching external data/complex transactions have been done correctly - without revealing sensitive information.
Bridging is another use case. In cross chain systems, Groth16 can be used to prove that an asset has been locked on one chain before it is released on another, all without sharing sensitive transaction data. This provides security and privacy to bridging that Bitcoin sorely lacks, where third party trusted bridges have been the go to solutions to move assets to/from L2s.
What about other ZK Proof Regimes?
There are other ZK proof regimes besides Groth16.
You may have heard of PLONK which is another non-interactive zk-SNARK. PLONK has a similar trusted set up to Groth16, but it is universal; where Groth16 needs a trusted set up for each specific application, PLONK can be used across different applications. However, Groth16 is typically faster in verification due to fewer pairing checks, and PLONK requires larger proof sizes (800-900 bytes). PLONK is increasingly popular with applications where flexibility across different proofs is needed, but for our purposes, Groth16 is favoured for fast/small-sized proof verification.
ZK-STARKs are another class of ZK proofs that are non-interactive. They also do not require a trusted set up, and possess better resistance against quantum computers. The trade-off is that zk-STARKs produce larger proofs (tens of kilobytes) and have higher verification costs compared to Groth16. STARK’s larger proof size makes it less suitable for environments where bandwidth and on chain data storage are concerns - like on Bitcoin.
Why is Groth16 so important to BitcoinOS?
We are trying to solve the problem of running complex transactions on Bitcoin. Given the limitations in Tapscript (the language you use to instruct Bitcoin), running more complex instructions requires many more steps than would be required in a higher level language. With this constraint, we need to build a system where complex transactions can be written back to Bitcoin, because they can't be run efficiently on Bitcoin itself.
This is what BitSNARK - our custom Groth16 verifier - allows us to do. It allows complex transactions that would be too inefficient to run on Bitcoin to be validated by Bitcoin nodes in the form of ZK proofs. This way we can have the best of both worlds: efficient complex transactions but validated by the most secure system, which is Bitcoin.
Groth16 is the proof regime most suitable for this in today’s world. Once you can verify complex transactions with Bitcoin security, you can start building bridges and vaults on the world's most valuable blockchain, today worth over USD $1.3 trillion.
While Groth16 is a relatively standardized proof paradigm, much work had to be done to adapt it to Bitcoin and trustless bridging. We made the decision to build our own Groth16 verifier from scratch. This was heavy lifting, but it allows for optimizations specifically for Bitcoin and for our intended applications.
BitcoinOS is the first team to fully verify a ZK proof on Bitcoin mainnet. Having cracked this problem, we can now see a path to building the first trustless bridge secured by Bitcoin. We’ve named this bridge Grail, symbolizing the elusive holy grail of crypto - a seamless path from Bitcoin to more scalable ecosystems that preserves Bitcoin's unmatched security, all without altering its core protocol.
Once Grail bridge is live, we will have created a new bridge security paradigm for BTC holders, to access a myriad of applications and ecosystems. It is going to unlock TVL from permaholders, trust maxis and new large institutional players who require the highest level of security - a bridge secured by the Bitcoin network itself.
This is why our vision is to unleash Bitcoin's $1.3 trillion into the wider ecosystem, and underpin the highest TVL ecosystem in crypto. Once we’ve done that, the sky is the limit.
For more information please visit our website, and follow BitcoinOS on X.
.png)
