📌Lightec Litepaper
An Introduction
opZKP is a project that uses Zero Knowledge Proof (ZKP) technology to allow Bitcoin to verify arbitrary computations before allowing any UTXO spending. This will be accomplished by generating zero-knowledge proof of such computation off the chain and then verifying the proof on the chain by introducing a new opcode to the Bitcoin Script programming language.
We proposed the OP_ZKP opcode upgrade as a soft fork to the Bitcoin community in April 2023, and we have also been building zkBTC since then, a flagship application based on the proposed opcode.
The zkBTC project builds a ZKP-based bridge between the two most important cryptocurrencies, allowing Bitcoin holders to safely enjoy Ethereum's already flourishing crypto ecosystem while the community builds a native ecosystem in Bitcoin over time. The zkBTC project will also set up a foundation to fund the Bitcoin community to build this ecosystem.
The Limitation of Bitcoin Ecosystem
Bitcoin introduced consensus networks and secure digital currency into human society. Starting with Bitcoin, people can collaborate in a decentralized way. Many applications that do not require a central or authoritative entity have been developed and deployed. However, many of these applications are outside the Bitcoin ecosystem.
Before diving into why this happened, let us explain how one party could pay Bitcoin to another. You may already know that Bitcoin adopts an Unspent Transaction Output accounting model, or UTXO. A UTXO is much like a physical coin but could carry any amount. UTXOs could be passed around in the Bitcoin network, from one owner to another, and could be split or merged. To spend some UTXOs, people must provide a piece of code in the Script language. Bitcoin nodes will evaluate the code to determine if spending is allowed for the selected UTXOs.
The limitation is that Script was intentionally designed as Turing incomplete, thus lacking some crucial programming capabilities to support most applications. The design choice was based on security considerations. Simply put, a Turing complete program might run into an infinite loop, and then Bitcoin nodes won't be able to finish validating any transaction that includes such programs. Should that happen, the Bitcoin network would be seriously sabotaged. Unfortunately, there is no simple fix to this situation. For example, Bitcoin nodes could include a security module to scan the programs for such loops. Yet, computer science theory dictates that it won't work as expected. We will not go into details here. Interested readers might search for 'halting problem' to learn more.
Should this limitation be lifted, one may use any computation to authorize UTXO spending. So, this opens up a brand new world for Bitcoin. We could build zk-rollup for Bitcoin and scale Bitcoin massively in its Layer 2s. Bitcoin owners could participate in complex smart contracts, trade stablecoins, and gain liquidity interests, to name a few. We stress that the potential application is only limited by our imagination and that the smart contracts based on UTXO and ZKP would be much different from those based on the account model and Turing complete programming languages found in other ecosystems.
Our Solution
The rapid development of ZKP has presented us with a new option. ZKP is a computer science discipline in that one party (the prover) may prove or argue convincingly that certain computations had been executed, characterized by specific input data and output results. Some inputs, called witness, could be hidden from the other party (the verifier) to protect privacy or confidentiality. Then, the verifier could verify the proof or argument to determine their next move.
The arbitrary computation could be executed off-chain in our solution, resulting in a succinct proof. The proof is further verified on-chain with the proposed OP_ZKP opcode. The verification result constitutes spending conditions for selected UTXOs. The proof and its verification are usually succinct, while running the original computation on chain would be much more expensive in terms of storage and computation time, let alone the security issues mentioned earlier.
By arbitrary computation, we refer to all the computations that could be expressed with arithmetic or boolean logic, usually called circuits in the realm of ZKP. Readers might wonder what is the relationship between arbitrary computation and Turing completeness. There are lengthy discussions online, but considering them equivalent is acceptable in practice. We will not go into details here also.
Applications — zkBTC Bridge
Now, let's talk about how we could build applications over OP_ZKP. Our first application is zkBTC, a ZKP-based bridge between Bitcoin and Ethereum. The project zkBTC issues $zkBTC, designed as an ERC-20 token and 1:1 pegged $BTC. Below is how it works.
One may mint $zkBTC simply by depositing some $BTC to the designated Bitcoin address, and then proof will be generated off-chain and verified in an Ethereum smart contract. By ascertaining the proof, the smart contract ensures that the deposit transaction has happened in the Bitcoin network. It then mints $zkBTC tokens properly for the user, ensuring 1:1 pegging.
Figure 1: Minting $zkBTC (ignore the fee rate for now)
The redemption works backward; that user must call the Ethereum smart contract to destroy some of their $zkBTC tokens. Then, proof will be generated off-chain. Depending on whether the proposed OP_ZKP opcode is activated or not, the proof is verified either by the Bitcoin network or in a tamper-proof container as an interim solution to authorize the final payout of some UTXOs.
Figure 2: Redeeming $zkBTC
We stress that users could redeem their $zkBTC tokens anytime by calling the provided smart contract. Your fund is safe. The locked $BTC is only redeemable after the ZKP verification of the proper redemption transaction. No private key is underlying the address backed by the proposed OP_ZKP opcode. In the case of the interim solution, the container is confidential, and none of the multisig private keys is known to anyone, not even to the contributor team or anybody operating the tamper-proof container. Interested readers may refer to our white paper for further technical details.
Project zkBTC aims to bridge Bitcoin and Ethereum while we strive to use this project to fund the development of opZKP and then to ignite the entire Bitcoin Layer 2 ecosystem. The OP_ZKP opcode proposal is non-profit, but its implementation is rather costly and might last a few years. Project zkBTC, on the other hand, could generate some cash flow from gathering fees from funds going to and fro the bridge.
Token Economics
There are two kinds of ERC-20 tokens: $zkBTC is pegged to $BTC exactly 1:1, and $L2 is rewarded to users as they pay fees to mint or redeem $zkBTC. All fees (nearly all but only a tiny percentage, see section Emergency Situations) collected will be pooled in a custodian smart contract, which no one, including the team, could touch. The value in the pool is shared equally among all existing $L2 tokens. Users can exchange $L2 for the $zkBTC in the pool at any time, permission-less and fee-free, according to the rate at the time of exchange, determined by the amount of existing $L2 and the amount of $zkBTC in the pool. The exchanged $L2 will be destroyed, of course.
Figure 4: Lifecycle of $L2 Tokens: 1) Users are rewarded $L2 tokens as they pay fees to use the bridge; 2) Users burn $L2 tokens to exchange back $zkBTC.
The smart contract is programmed to cut the fee rate in half over the total mint amount (TMA), eventually set to zero after halving it a few times. From then on, zkBTC will become a free public infrastructure (users still need to pay the Bitcoin miner fee or Ethereum gas). Accordingly, the token reward will be cut over time and become zero. From then on, $L2 should be pegged to $zkBTC at a fixed rate, which will be much higher than the above exchange rate when the project is live in the main net. Please refer to our white paper for a detailed schedule.
Community and Incentive Programs
The community takes one-third of all pre-minted tokens. Most will go to community members through various incentive programs, including airdrop, strategic incentives, staking incentives, eco-partner sales, etc. The purpose is to encourage investors and users to use $zkBTC as they wish. We expect people to use many $zkBTC tokens in Swap or DeFi protocols. However, there are no limitations. For example, we will also incentivize any team to re-peg $zkBTC in Ethereum L2s or even in other blockchains in a fully decentralized way.
Eco-Partner Program
Action: We encourage any team willing to re-peg $zkBTC to Ethereum L2s or other blockchains to contact us now to secure a quota of eco-partner sales. You are not obligated to deliver such products at the end, but we will provide more incentives once you do, and you may resale the tokens immediately after your product launch. There is also no minimum purchase amount if your plan is solid. However, if you contact us after the selling period or do not want to purchase the tokens, the incentives remain.
The Layer 2 Foundation
So we send 33.5% of the pre-minted $L2 token to a to-be-setup foundation to fund the research and development of OP_ZKP and research towards applications on top of this new opcode. The foundation will be non-profit and support related research so that Bitcoin becomes more and more valuable over time. We believe there are many investment opportunities in the Bitcoin Layer 2 ecosystem, and we position the foundation to promote the underlying research and infrastructure building.
Another responsibility the foundation carries is to ensure the overall security of the entire system and to remedy damages from potential attacks, which might cause $zBTC to potentially de-peg from $BTC. See later sections for details.
VC Sales and Private Sales
Among the pre-minted 128 base packs, we have reserved some base packs for VC and private sales. The VC sale price will depend on the total pre-minted $L2 valuation. The private sale price will lie somewhere between the VC sale price and the initial mining costs.
Price is not the only thing, however. For the project zkBTC to succeed, there must be lots of bridge usage and lots of $zkBTC in use to make the ecosystem robust and practical. We want the investors to be partners and build the ecosystem with us. Contact us if interested. You may find contact details at the end of this document.
Security, along with some Technical Details
It is more than fair to demand the zkBTC bridge to be highly secure, as the asset security of hundreds of billions of dollars relies on it. We understand that ZKP technology is still fast growing. And our implementation could still be vulnerable to novel attacks some days later, no matter how many resources we commit. We have prepared. Here is a brief introduction to what we have done or will do.
Upgradable ZKP Verification Modules
In the architectural design of zkBTC, there are multiple ZKP verification modules, with one upgrading another in a rolling schedule. After deploying the first ZKP verification module, we will start developing its successor, either adopting a new ZKP scheme or enhancing the existing one regarding security and efficiency. The earlier module will phase out over time.
Even if no attack happens, we still schedule to upgrade the ZKP modules regularly. It is similar to administrators patching servers on a daily basis.
From Bottlenose Dolphin to Blue Whale: Maturity Model
In parallel to upgradability, a new circuit, usually combined with a new scheme, might also be promoted from Bottlenose Dolphin to Blue Whale. People refer to holders with large amounts of Bitcoin as whales, so we use Blue Whale to refer to ZKP modules that handle large amounts of minting or redemption in our system. Then Bottlenose Dolphin refers to ZKP modules handling a small amount of minting or redemption.
The design aims to first put a new ZKP module into the real world with limited potential damage. After battle-testing, it can handle larger amounts, with some enhancements.
Further, although the Blue Whale is the biggest mammal on earth, it is still of finite size. Therefore, there is also an upper limit for the minting or redemption amount that a Blue Whale module could handle.
Realtime Monitoring
We actively monitor Bitcoin and Ethereum in real time. If we find in the mempool a transaction not backed by an actual $BTC deposit or $zkBTC burn, we can respond quickly.
Emergency Situations
Emergency Switch
As we have stressed before, we commit many resources to security with carefully crafted architecture, strictly reviewed circuit implementations and security audits. Asset security is of paramount importance to us. Still, we have also prepared ourselves for the worst-case scenario.
Once we confirm an attack event to a ZKP verification module, we will flip an emergency switch for that module, preventing further minting, redemption, or both to limit the damage. Once flipped, the switch cannot be flipped back again, so the switch controller cannot abuse its controlling power.
For those users who use the provided portal to mint or redeem, the flipping shall not cause any issues. However, other users who use non-official software shall take care of themselves.
A transaction safelist, which the community will eventually govern, could be used to retrieve the remaining funds from the locked modules safely.
Emergency switches will phase out over time when the system is mature enough, subject to expert evaluations in the future. For example, we might verify the final modules with formal methods, and we have put these modules on bug bounty programs for an extended period.
Remedy Procedures
Attacks that mint $zkBTC tokens without depositing $BTC in the first place or that redeem $BTC without destroying $zkBTC tokens cause $zkBTC to potentially de-peg from $BTC.
First, the community does not need to panic. The damage is usually limited if we flip the emergency switch in time. Users can still redeem $zkBTC for $BTC in a 1:1 ratio as long as there is still $BTC remaining to be redeemed. This 1:1 ratio is hardcoded in the smart contract. The foundation will not redeem any $zkBTC token in this situation. The de-peg is only potential. We can fix it by burning the excessive $zkBTC tokens.
Then, we choose a time to burn a certain amount of $zkBTC tokens to restore the pegging, but no rush or hush is necessary, as we just explained. The situation is handled, and eventually, the balance will be restored.
The community will have a say in how the foundation manages its funds to ensure that the foundation will not bank-run against the community in case of de-pegging resulting from attacks.
Fund Reserve for Re-Pegging
Funds to restore the pegging comes from two directions. First, we reserve some amount of $L2 token from the pre-minted. We can exchange the tokens for $zkBTC to burn them.
Second, although we promise to cancel the minting and redemption fee someday, after cutting the fee rate in half a few times, we might cancel it a bit later than canceling the $L2 rewards. We program the smart contract to send all the fees collected to the foundation. The fee rate will be ridiculously low at that time, so a reward will mean little to users anyway. However, it makes sense for the foundation to collect future liquidity.
In rare cases, sophisticatedly orchestrated attacks could deplete the foundation's funds. With a future award ahead, however, the foundation could manage to fund itself to conduct damage remedies and to continue serving the community. The community could help decide how many fees to reserve for this purpose.
About the Team
Weiji Guo, Founder and CEO, cryptographic engineer. Mr. Guo has a B.S. degree in mathematics and has worked as a software engineer for over 20 years, with about ten years in cryptography-related engineering. Mr. Guo authored SMGo, a Go implementation of the Chinese Cipher algorithms SM2/3/4, perhaps the first constant-time SM2 and SM4 implementation, possibly the fastest in some hardware platforms. He also authored EIP 6051. Mr. Guo proposed the OP_ZKP opcode idea to the Bitcoin developer mailing list in April 2023.
Last updated