Discussion with Bitlayer, CKB, and Bool Network (Part 2): Perspectives on Technical Approaches for the BTC Ecosystem
TechFlow Selected TechFlow Selected
Discussion with Bitlayer, CKB, and Bool Network (Part 2): Perspectives on Technical Approaches for the BTC Ecosystem
Three guests discussed Bitcoin cross-chain bridges, BitVM, the Lightning Network, and RGB and RGB++.
Navigating Web3 tides with focused insightsHost: Jomosis, Geeker web3
Guests: Kevin He, Co-Founder of Bitlayer;
Baiyu, CKB Eco Fund Partner;
Kai, Researcher at Bool Network
On the evening of May 16th, Geeker web3 invited guests from Bitlayer, CKB, and Bool Network for a Twitter Space discussion on various issues surrounding Bitcoin Layer 2. The conversation covered many interesting topics. Due to the volume of content, the written transcript has been divided into two parts. The second half covers the following questions:
-
Compared to Ethereum, Bitcoin is not well-suited as a base layer for Layer 2 solutions. In what ways does Bitcoin hinder Layer 2 development?
-
Two days ago, the xlink cross-chain bridge was hacked due to a private key leak, losing over $4 million. Security—especially withdrawal bridges—is one of the core challenges for Layer 2. How does your team address the security of withdrawal bridges?
-
The Lightning Network and RGB protocol were once highly anticipated but have underdelivered in ecosystem growth. What are your thoughts on this?
-
In today’s Bitcoin Layer 2 ecosystem, which projects stand out in terms of technology or narrative? Why?
-
How many hurdles remain before Bitcoin Layer 2 can achieve the same level of popularity as Ethereum Layer 2?
Throughout the discussion, insightful remarks were made by the guests. Professor Baiyu stated bluntly: "I believe the biggest obstacle for the Bitcoin ecosystem is that Ethereum has been too successful—people's minds are imprinted with Ethereum-centric thinking."
Due to the extensive content, we've split it into two parts. Below, please enjoy the second half, and draw inspiration from the guests' excellent insights.
Link to Part One: "Dialogue with Bitlayer, CKB, and Bool Network (Part 1): A Grand Debate Among Bitcoin L2 Schools"
1. Jomosis: Bitcoin isn’t really suitable as a base layer for Layer 2. Where exactly does it create obstacles?
Kevin: Mainly in hindering Layer 2 technological implementation. Personally, I believe the key factor for Layer 2 adoption lies in whether large holders—or whales—recognize and trust your solution. From what I understand, many big holders are still reluctant to move BTC to Layer 2 or enter relatively unreliable yield-generating channels, though they often distrust CEXs even more.
We can see projects like Babylon—a ReStaking initiative—with clear security models that solve real problems and gradually gain acceptance among BTC holders, including institutional investors. This shows people are beginning to accept narratives where Bitcoin can securely move to Layer 2 or other zones, locked on the main chain while generating yield elsewhere. User perception is slowly shifting.
Returning to the original question: technically, the reason so many different approaches exist stems from Bitcoin's inherent limitations. Specifically, Bitcoin lacks on-chain verification capability. Without this, verifying withdrawal actions from Layer 2 back to Layer 1 becomes extremely difficult, making secure two-way bridges hard to implement.
Additionally, under the UTXO model, each UTXO exists as an independent parallel space, making it difficult to establish interconnections. Features like Covenants haven't yet gained community consensus.
Another critical issue is that Bitcoin lacks global state. Without global state, functions such as emergency exits, forced withdrawals, or conditional responses based on verification results cannot be implemented. Instead, everything relies on off-chain indexers or lightweight nodes to read transactions, or specific transaction patterns for reverse indexing or linking.
In summary, both public understanding and technical innovation regarding Bitcoin and Layer 2 need to advance further. Innovations like CKB’s Cell model or BitVM attempting to enable verification on Bitcoin could significantly enhance the ecosystem beyond its current state.
Baiyu: I think the biggest obstacle is that Ethereum has been too successful—our minds carry strong mental imprints from Ethereum. Back then, Ethereum was revolutionary, breaking through Bitcoin’s purist community by proposing blockchain as a smart contract platform, abandoning UTXO in favor of an account-based model.
While Ethereum seemed avant-garde at the time, years later we realize it's best suited for financial applications—even its founder admits it's become a highly financialized world. The only major non-financial application seems to be ENS, ironically boosted by a comment from Vitalik himself. That’s quite ironic.
Now, when building within the Bitcoin ecosystem, we habitually try to replicate Ethereum’s approach. We struggle to build in Bitcoin’s space, only to find our efforts swayed by opinions from established Ethereum players. Recently, I met someone who’d spent years in the Ethereum community. After hearing my pitch about joining CKB’s North American team, he asked: “All these things already exist on Ethereum—why go to Bitcoin?”
Many top talents share this view—that whatever Bitcoin builds already exists on Ethereum. Why rebuild from scratch? I’m tired of hearing this question. So I believe the most important thing now is to explore how Bitcoin can do things Ethereum cannot. Ethereum keeps evolving, but ultimately circles back to Staking and Restaking. Should we repeat the same cycle in Bitcoin?
Breaking free from Ethereum-style mental imprinting is key—and remains the biggest barrier to attracting talent to the Bitcoin ecosystem. How do we attract the brightest minds to help push blockchain forward using Bitcoin?
2. Jomosis: A few days ago, the xlink bridge lost over $4 million due to a key leak. Cross-chain bridge security—especially withdrawal bridges—is one of Layer 2’s core issues. Many Layer 2s still rely on simple multi-sig bridges vulnerable to collusion or external breaches. Could you explain how your team addresses withdrawal bridge security?
Kai: To put it simply, the problem with Bitcoin bridges is that Bitcoin scripts aren't Turing-complete, so we can't directly port Ethereum-style verification mechanisms onto Bitcoin. Given this, Bool Network has explored multiple alternatives. The simplest approach treats each Layer 2 as a centralized exchange, relying on decentralized custodians to manage cross-chain operations.
Bool Network extends this idea by focusing on decentralizing asset custody. Our first priority is solving witness security. We use a POS mechanism to allow permissionless participation. Then, we leverage TEE, MPC, and our proprietary RingVRF to dynamically select bridge witnesses from across the Bool Network—randomly choosing a few nodes from hundreds to serve as validators.
TEE ensures code runs strictly under defined constraints, making it nearly impossible for outsiders to tamper with logic or data. Combined with our MPC scheme, private key shares rotate continuously among hundreds of nodes in the Bool Network.
However, Bool Network nodes are public, so privacy protection is essential to prevent attackers from identifying custodial nodes. Our RingVRF with privacy features allows a node to prove its public key belongs to a hidden set of N keys via zero-knowledge proofs, revealing only a temporary communication key without exposing identity.
Thus, our entire architecture is clear: We hide the DHC (Dynamic Hidden Committee) nodes within a large network of potential witnesses—hundreds or thousands of nodes. Using ZK + RingVRF, we conceal each witness's identity. Every node runs TEE, ensuring private key shards and core computation happen inside secure enclaves. Even selected witnesses don’t know they’ve been chosen—preventing collusion and external compromise at the root level.
Baiyu: For CKB, we categorize assets into two types: Bitcoin itself and derivative assets issued on Bitcoin, such as BRC-20 or various runes. We’ve studied internally and concluded that if Bitcoin avoids hard or soft forks, BitVM represents the ideal verification-capable bridging/Layer 2 solution. However, BitVM will take significant time to mature. Therefore, in the short term, there is no cryptographically secure way to safely shuttle Bitcoin between Layer 1 and Layer 2.
Given this, Bitcoin bridges tend toward two extremes. One is extreme centralization—licensed institutions acting as custodians trusted by large holders due to legal oversight. WBTC is the prime example, with tens of billions in market cap on Ethereum, managed by BitGo.
The other extreme is maximal decentralization. But bridges differ greatly—one shouldn’t assume all bridges are equal. Differences between bridges can exceed those between bridges and non-bridges. You must examine their trust assumptions. Ultimately, the closest achievable model resembles POS: economic incentives deter malicious behavior through slashing.
In fact, nearly every possible Bitcoin bridge model has already been tested in BTC-ETH bridges. People have long experimented with ways to bring Bitcoin off-chain to Ethereum. Most ideas are already exhausted—we don’t need to reinvent them. Among more decentralized options, TBTC stands out, though it may not be widely usable.
CKB is currently discussing collaboration with Bool Network. We’re also developing WBTC-like solutions and exploring protocols like RGB++ or other UTXO-like asset frameworks. These assets can achieve trustless interoperability between CKB and other UTXO chains via isomorphic binding.
We're also considering whether isomorphic binding can integrate DLC or BitVM advancements to enable BTC-side verification, allowing us to issue something like RBTC—an R-wrapped BTC—via RGB++. There's some promise here, but it's too early to conclude.
So remember: bridges are honeypots full of money. Beyond hacking risks, consider events like Multichain, where external forces caused funds to vanish overnight.
Kevin: Let me briefly touch on bridges. First, security and decentralization aren't absolutely correlated. Fireblocks holds vast amounts of funds yet hasn't suffered major losses, whereas decentralized bridges frequently get hacked. So currently, high decentralization doesn’t guarantee higher security.
Second, we need more advanced technical solutions. It requires innovation from us or the community to make bridges trustless, because being trustless inherently strengthens the custodian’s security—a goal worth pursuing.
Looking at bridge models: traditional bridges require users to hand over funds entirely to operators, surrendering control. Funds are governed via multi-sig, POS, fraud proofs, or ZK validity proofs. The common flaw? Users lose full control of their assets. Can we let users retain partial control?
During research, Bitlayer found DLC models might offer new possibilities. Under DLC, both user and platform lock assets using 2-of-2 multisig and pre-signatures based on predicted outcomes—users never fully relinquish control. With OP-DLC bridges, worst-case scenario is uncooperative bridge operators, but assets won’t be stolen. Ultimately, bridge designs based on DLC or channel models can shift trust models and power distribution in meaningful ways.
Our technical whitepaper and phase-two testnet include such designs, aiming to offer the market and community a fresh alternative.
Regarding key leaks—the root cause of past major hacks—we ask: how should keys be managed? MPC helps mitigate risks. Principles like cold-hot separation and role isolation are industry standards. We’ll provide these guidelines to developers via a Security Codebook-style document.
3. Jomosis: Next, let's discuss the Lightning Network and RGB protocol. Both were once highly anticipated but have underperformed in ecosystem growth. What are your views?
Baiyu: Our favorite Bitcoin paths include the Lightning Network. As Cipher and Jan say, the Lightning Network is a lighthouse for the Bitcoin world. We strongly support advancing related developments. Yet despite five to six years of effort—even with major companies like Lightning Labs pushing it—progress remains slow. This reflects deeper issues within the Bitcoin community, highlighting the need for catalyst teams like CKB.
We noticed that CKB announced its own Lightning Network, with RGB++ compatible for reuse. Since then, Lightning Labs has accelerated development. We believe the Lightning Network should become more open—not controlled by a few centralized entities—but evolve into an open standard, capable of supporting any compliant UTXO asset on Bitcoin Layer 1. Currently, Lightning Labs prioritizes Taproot Assets compatibility, limiting openness.
We hope the Bitcoin ecosystem promotes greater openness in technical standards like Lightning. Currently, it serves more B2B than direct consumers. Most users find Lightning’s UX intolerable—security sacrifices usability. Convenience requires trading off some security. Financial service providers thrive in this gap, offering better UX despite lower security—like LSD, which considers compliance in design. These reflect current Lightning Network trends.
CKB’s own Lightning Network will launch on testnet around mid-June, followed by testing phases. We welcome participation. We hope combining Lightning, RGB++, and wallets like Joyid’s PassKey will enable mass adoption.
On RGB: instead of discussing the protocol broadly, let’s focus on its two core components. First, CSV (Client-Side Validation), a crucial scaling approach in the Bitcoin community. Sadly, CSV is overlooked. Most prefer Ethereum-style Bitcoin scaling—building another chain off Bitcoin—rather than constructing a P2P network off-chain.
At its heart, the Bitcoin community values P2P—peer-to-peer connections enabling mutual validation of critical data. CSV embodies this: building an off-chain P2P network where individuals can independently verify transaction validity. To achieve this, a key concept is Single-Use Seal—using Bitcoin’s UTXOs as one-time seals.
These two elements—CSV and Single-Use Seal—are RGB’s foundation, enabling numerous innovations. View CSV as a service; build DApp platforms around it. CKB’s core contribution based on RGB is RGB++, treating CKB as an off-chain client for RGB, secured via isomorphic binding.
We also have a bolder idea: Bitcoin may not be the optimal base for CSV, given its limited verification capacity. Perhaps CKB is better suited for CSV, possibly integrating with Nostra. We may soon release a technical proposal on integrating Nostra with CKB, encouraging builders to develop social applications.
In summary, I believe the Bitcoin community possesses powerful ideas—RGB, Lightning Network—excellent protocols that deserve wider recognition. By combining them, we can build things impossible on Ethereum. Ethereum once attempted a Lightning-like network—early adopters recall the “Raiden Network”—but eventually abandoned it. Yet this is precisely what Bitcoin can excel at. Why not continue down this path?
Moreover, I know some Ethereum projects are now exploring CSV and client-side validation—techniques originally pioneered in the Bitcoin community. We should champion and expand upon them.
Kevin: Regarding the Lightning Network, if I recall correctly, it was initially designed for microtransactions. But fundamentally, using Bitcoin for small payments makes less sense than using stablecoins. Limited supported asset types is a constraint. Now that Ordinals, BRC-20, and Runes are gaining traction, could issuing stablecoins via new asset protocols and using them for payments or swaps on Lightning unlock new potential? I'm very hopeful.
Before launching Bitlayer, we researched RGB but chose not to adopt it, seeing niche protocols requiring broader education. For us, market fit matters more—we prioritize widely accepted technologies. Hence, we pursued BitVM on Bitcoin. Given the growing BitVM community, meaningful breakthroughs seem achievable, even without significant BTC mainnet hard or soft forks. Our BitVM PoC has already succeeded.
Overall, our vision is a flourishing Bitcoin ecosystem with diverse ideas gaining recognition. Bitlayer supports multiple VMs and security models. Once verification capabilities improve, we can accommodate various programming paradigms.
Kai: The Lightning Network is primarily limited by its non-Turing completeness and lack of smart contracts, restricting app expansion, since it was originally intended only for fast micro-payments. CKB, however, represents a major upgrade—offering Turing-completeness.
Baiyu: I think Kevin and Kai highlighted crucial points. Today’s Lightning Network isn’t just for micropayments anymore. Nobody uses Bitcoin for payments now—it’s primarily seen as an asset store. Retail users hold little BTC. The realistic scenario is Lightning becoming infrastructure compatible with various Bitcoin-issued asset protocols.
For example, issuing USDT via RGB++, then routing it through Lightning. Thus, Lightning acts like a highway—originally for one type of vehicle (BTC), now open to others. That’s its biggest evolution.
Secondly, as Kai noted, Bitcoin’s Lightning remains non-Turing complete. But on CKB, Lightning can incorporate conditions—supporting multiple asset protocols, enabling swaps, even DeFi within Lightning. The possibilities are vast.
4. Jomosis: How many challenges remain before Bitcoin Layer 2 reaches Ethereum Layer 2 scale?
Kevin: First, perception. People need to recognize Bitcoin beyond just store-of-value. Second, technical barriers—resolving on-chain verification and gaining broader acceptance for client-side validation.
Baiyu: I think expectations for the Bitcoin ecosystem are actually low. Ethereum took years to discover applications fitting its architecture. Bitcoin needs more time to cultivate a thriving ecosystem. We stand on Ethereum’s shoulders, learning from its experience—a vital advantage.
Still, we must explore Bitcoin-native concepts: What can UTXO truly enable? For instance, we’re investigating whether UTXO is better suited for NFTs, given its inherent parallelism and individual ownership—unlike contract-controlled assets.
In DeFi, UTXO computes off-chain, then posts results on-chain for verification. This off-chain compute / on-chain verify model suits intents and OrderBooks well. Orderbook exchanges originated as Ethereum ideas, but poorly executed—leading to AMMs dominating. Bitcoin’s path may differ. These require longer exploration and market validation.
Kai: Bitcoin Layer 2 must ensure trustlessness and security, delivering standardized solutions. Also, UX matters—many Layer 2s use Ethereum-style accounts, but you could instead extend Bitcoin’s native account model into Layer 2 use cases. These are just hypotheses—I believe better solutions will emerge to overcome current limitations.
5. Jomosis: In today’s Bitcoin Layer 2 landscape, which projects impress you most in technology or overall narrative?
Kevin: Well, naturally I’ll mention Bitlayer, haha. I believe Bitlayer offers a clear architecture and problem-solving methodology. We identified key issues and developed effective solutions, innovating beyond existing approaches. For example, we achieved FRI or STARK verification on BTC using Taproot without relying on the OP_CAT opcode (via BitVM)—this is our innovation.
Our OP-DLC bridge introduces an improved capital control model, and our multi-VM design reflects substantial thought and effort. Overall, we aim to advance the BitVM technical community—for instance, co-launching BTCEden, a Bitcoin Layer 2 risk assessment site with Geeker web3, contributing public goods.
We’ve also helped grow the BitVM community. The Chinese BitVM community now boasts tens of thousands of followers. Through consistent科普 (popular science), weekly BitVM reports, and sharing internal research as products, we aim to attract more contributors to BitVM research and development—benefiting all developers.
We’re excited to see the BitVM ecosystem rapidly expanding—over six or seven projects now building around it. We are core contributors—our researcher recently won the SHA256 OPCode challenge and received the prize. We hope more teams join us in exploring and breaking new ground, enabling verification on Bitcoin with minimal forks—benefiting the entire ecosystem.
Also, teams here today—CKB and Bool—are highly distinctive, committed to their visions with solid execution. They command great respect.
Baiyu: I most admire the CSV path represented by RGB and RGB++, and the fast-payment route exemplified by the Lightning Network. Both share a common trait: off-chain scaling, leveraging Bitcoin UTXO security and limited script capabilities—unique strengths of the Bitcoin ecosystem.
We constantly try to make Bitcoin more like Ethereum—adding smart contract verification to do more things. Exploration continues off-chain. I hope more teams pioneer innovative paths. Everyone admires Uniswap—500 lines of code created a revolution. But before Uniswap, many DeFi protocols existed; countless attempts paved the way.
I believe the Bitcoin ecosystem is at such a dawn—abundant with creative ideas and concepts not yet fully recognized or productized. Great opportunities await discovery. That’s my perspective.
Kai: I believe the BitVM bridge is a promising solution, though practical deployment will take time. During this interim, alternative approaches—like multi-sig or MPC—can address current Bitcoin Layer 2 challenges. Thus, Bool Network aims to help Bitcoin ecosystem projects quickly build applications bridging Bitcoin to Layer 2.
Join TechFlow official community to stay tuned
Telegram:https://t.me/TechFlowDaily
X (Twitter):https://x.com/TechFlowPost
X (Twitter) EN:https://x.com/BlockFlow_News
@godrealmx
