New version — Flash Trade on swaps.io (demo)
Kinetex is excited to introduce BTCX, a Bitcoin ZK light client, built with Succinct. Developed using the plonky2x framework and deployed seamlessly through Succinct’s unified proving stack, BTCX enables EVM-compatible networks to directly verify Bitcoin state without any centralized actors in -between.
BTCX is the first step towards integrating the Bitcoin network into Kinetex's Flash Trade and establishing trustless interoperability between the two largest blockchain ecosystems.
BTCX allows developers to communicate trustlessly from Bitcoin to any EVM-compatible chain with the security of Bitcoin’s consensus protocol. This represents a momentous upgrade over the security standards of existing cross-chain bridges that rely on multi-sigs or centralized actors.
Most of the existing bridges rely on cryptoeconomic security achieved through capital staked by a set of validators. The validators are incentivized to act honestly through network rewards and slashing penalties. The bridge can then be considered secure as long as a majority of validators (usually 2/3) are honest.
However, cryptoeconomic security is difficult to scale. The Cost-of-Corruption of these bridges is equivalent to bribing a majority of the validators (proportional to the total staked amount), but the Profit-from-Corruption increases with the amount of capital locked in the bridge. Therefore, the security of these bridges diminishes as the TVL in them increases relative to the total staked collateral.
The BTCX implementation, on the other hand, does not rely on any centralized or cryptoeconomic committees with risky trust assumptions. Instead, it leverages zero-knowledge (ZK) technology to validate Bitcoin block headers. This method verifies the correctness of submitted blocks in alignment with the Bitcoin network's consensus rules, and allows for the majority of hash computations and other light client validation tasks to be conducted off-chain. Consequently, only a single proof needs to be verified on-chain, requiring roughly 300,000 gas.
BTCX contains a set of ZK circuits that implement the chain's validation logic in the Bitcoin light client. The primary circuit “verify” serves as the entry point and validates a sequence of Bitcoin headers.
Presently, the logic is relatively straightforward. First, this circuit takes the "previous" header hash as input alongside a sequence of subsequent header bytes, and then generates a proof containing corresponding hashes and the total work related to the provided headers, if they are valid.
The validation logic within these circuits ensures that the hash aligns with the block header, that the header's work fits within the defined difficulty bits, and that the parent hash field of the current block matches the previous header's hash.
Although this suffices for validating the provided block header sequence, additional logic is required to select the longest chain and handle pruning following chain reorganization — details that will be explored further in subsequent sections.
Succinct is a decentralized proving network that enables any developer to build blockchain applications and infrastructure secured by cryptographic truth, not trust. Succinct’s base layer simplifies the complexities associated with using ZKPs by synthesizing the entire developer experience into one network and providing a unified interface for the entire ZK stack.
The plonky2x framework integrated into the Succinct network substantially streamlines the development of ZK circuits, replacing months of deploying custom infrastructure for ZKP generation and wrangling customized SDKs, with seamless production deployment. Succinct also significantly optimizes debugging and release preparation by tracking progress on the latest circuit builds and proof systems.
The BTCX light client was developed leveraging the vast array of tools provided by Succinct’s unified proving stack. . BTCX is based on BTC Warp, initially implemented in plonky2, with the primary objective of achieving faster synchronization of Bitcoin nodes. The original circuits were ported to plonky2x, enhancing code readability and maintainability while allowing for several optimizations. One such optimization was the use of a STARK-based accelerator (also a part of the Succinct interface) built with the open-source Curta AIR-builder library. It allowed us to optimize SHA-256 computations significantly and thereby reduce proving time.
Finally, the GitHub repository was integrated into the Succinct network, and the subsequent deployment and generation of the first proofs required just a few simple steps, completed in a visually friendly interface.
Utilizing ZK technology in Bitcoin light clients offers a broad range of possibilities for various purposes. For instance, the blog post "BTC Warp: Don't Sync, Verify" introduces the concept of near-instant synchronization for a Bitcoin node, achieved through a sophisticated approach involving recursive zkSNARKs and composable trees.
However, during the development of BTCX, we pursued a different goal: creating an on-chain light client for the Bitcoin network. Therefore, it took the form of a smart contract deployed on EVM-like networks. The smart contract is responsible for verifying off-chain proofs that attest to the chain's correctness,enabling on-chain verification of blocks, transactions, and UTXOs.
Currently, we focus on optimizing the on-chain light client to be as gas-efficient as possible, both for the verification process and for the utilization of smart contract storage. This optimization is crucial given that the latter is one of the costlier operations when interacting with EVM.
It is important to follow the full set of Bitcoin consensus rules, and our plan includes expanding the logic of the current circuits by incorporating all the necessary chain checks. Currently, a key missing component is the Difficulty Retargeting check, which plays a crucial role in ensuring the chain's correctness by confirming alignment with the difficulty adjustment formula.
Every 2016th block, the current difficulty is recalculated based on the time spent finding the previous 2016 blocks. Furthermore, all blocks within the same window should share the same target, and the blocks of the subsequent period should have a target corresponding to the correct adjustment.
Integrating this check, along with other minor header block checks like timestamp and version, will eliminate any possibility of manipulation with on-chain light client updates.
The off-chain component of BTCX, in the form of a ZK circuit, enables the validation of any block sequence without requiring specific context or information about the network and time period to which the sequence belongs. This approach should closely interact with the on-chain component, a light client's smart contract responsible for storing the current network state.
This smart contract must be initialized correctly by setting the accurate genesis block or a verified checkpoint and ensuring its immutability. Additionally, the light client is expected to keep a record of the accumulated work and handle block reorganization.
In the PoW consensus mechanism, there are no validators designated to select the exclusively correct chain. Therefore, in the context of Bitcoin, the correct chain is the "longest chain", indicating it has the highest cumulative work. Consequently, a previously accepted chain may be partially or entirely pruned and replaced if a new chain has a greater amount of cumulative work.
Given that any sequence can be deemed correct if it aligns with a previously saved chain and adheres to the rules of the Bitcoin network, the light client should follow incoming updates by promptly integrating them with the correct blockchain. This process should override any other previous chains with less work done while relying on appropriately set parameters for finalizing the chain.
Obviously, the light client's smart contract must provide methods to verify a block's inclusion in the chain, confirm the completion of a specific transaction, and, ideally, be able to validate the correctness of particular transaction details and track the state of UTXOs.
Validating Bitcoin block headers using ZK technology is the initial phase in creating a comprehensive on-chain light client. Such a validation might raise efficiency concerns when dealing with a few blocks in a sequence. However, it is essential to recognize that the block header constitutes only a part of the entire Bitcoin block. A complete block includes raw transaction data and other metadata. To fully validate a block, it is required to validate the correctness of every transaction within that block, which introduces a significant increase in resource requirements for the overall validation process.
It is evident that performing these calculations directly on-chain would be ineffective and impractical. Therefore, we plan to augment ZK circuits with the necessary logic for transaction validation.
Continuing with full block proving and transaction validation, the next logical step involves monitoring UTXOs and their commitments. By doing so, we can maintain a record of all UTXOs and, even segregate them by individual accounts, forming a tree-based structure. The root hash of this tree would then be stored within the on-chain light client alongside each new block.
The UTXO model only records transaction receipts, and the approach proposed above offers several advantages, including the ability to validate available UTXOs for future transactions and accurately determine account balances at any given moment. All that is required is the correct proof of inclusion for the specified account.
There are various potential solutions for implementing this, including Utreexo and other structures designed to work effectively with zkSNARK. This approach opens up exciting possibilities for interacting with the Bitcoin network. For instance, it can be utilized to develop oracle-based EVM applications, leveraging the state and actions of accounts within the Bitcoin network.
Despite the fact that most of the gas costs are excluded with the help of off-chain ZK calculations, the blockchain data must still be stored in the light client's smart contract storage. Using storage is one of the most expensive operations, and keeping the entire history of the Bitcoin blockchain can cost more than 16 billion gas units.
To optimize storage usage, one can consider the Merkle Mountain Range (MMR) structure. This structure enables efficient handling of large datasets, making it particularly suitable for working with blockchain historical data.
MMR is an append-only structure that includes a sequence of Merkle trees, each decreasing in height from left to right. The highest node of each tree is the "peak." Collectively, these peaks represent the entire MMR structure. The number of peaks in the standard implementation does not exceed n, with the number of elements being 2**n.
Thus, instead of storing each block hash, it is enough to store only the peaks, recalculating them with each update. Rewriting a reserved slot of storage takes only 5k gas units (the number of updated peaks varies). At the same time, updating the state of the light client can be done in batches without the need to save new block headers in storage. The array of these hashes needs to be included in the calldata, and we need ZK proof that all hashes are valid and linked. It is important to note that there is a limit to the amount of the calldata that can be passed within a transaction, which means that a maximum of 1,000 block headers can be included in each. That is acceptable for the Bitcoin network, as it produces only up to 144 block headers daily. Such a reasonable quantity enables the creation of an on-chain MMR without relying on ZK technology, ensuring transparency in its updates during appends and striking a balance between the resource intensity of ZK operations and gas costs.
Over the past 15 years, the Bitcoin network has continuously evolved. The primary mechanism for implementing significant upgrades has been the proposal and endorsement of BIPs (Bitcoin Improvement Proposals). These formalized documents allow any user to introduce an idea for improving the network. However, approval from developers and miners is necessary for a BIP to be fully activated in the Bitcoin code.
Over time, a considerable number of proposals have gained acceptance, and we have plans to gradually integrate support for the key ones. Specifically, our focus is on implementing support for SegWit (BIP141), Taproot (BIP340-342), and potentially even Ordinals and Atomicals.
Although the rise of DeFi has somewhat overshadowed Bitcoin, it continues to play a pivotal role in the cryptocurrency landscape due to its reliability, high decentralization, and exceptional resistance to 51% attacks. Recent market developments, such as the approval of Bitcoin ETFs, indicate just how vital Bitcoin is in the crypto economy and how important it is to bridge the gap between traditional exchange trading and DeFi.
Kinetex has set itself the task of uniting the two largest ecosystems: Ethereum and Bitcoin. This will allow institutional players and other users who prefer to use the original cryptocurrency to enjoy all the benefits of the DeFi sector. While most Bitcoin trading currently takes place on centralized exchanges and custodians, Kinetex takes an entirely different approach. It merges the advantages of both ecosystems, benefiting from Bitcoin's maturity and capital stability, as well as the advanced DeFi technologies implemented in Ethereum.
