The Succession Battle of Bitcoin L2: Origins, Turning Points, and CKB's Choice
TechFlow Selected TechFlow Selected
The Succession Battle of Bitcoin L2: Origins, Turning Points, and CKB's Choice
Fast speed is not our feature; our feature is slow speed.
Navigating Web3 tides with focused insightsCompiled by: Byteyuan CKB
Podcast source: Orange Book
In the latest episode of the Orange Book podcast, Li Yang invited Jan Xie, Chief Architect of Nervos, to discuss topics related to Bitcoin Layer 2. It's packed with insights and highly recommended.
Below is the transcript based on the podcast audio, approximately 20,000 words in total. For easier reading, some subheadings have been added 😊:
1. Opening Remarks
Li Yang (Host): Hello everyone, welcome to Orange Book. This episode continues our exploration of the Bitcoin ecosystem, focusing on Bitcoin Layer 2.
At the end of the last episode, I had a strong feeling that inscriptions were just the first wave of the Bitcoin ecosystem—we're only getting started. But I didn't expect the new trend and赛道 of Bitcoin Layer 2 to heat up so quickly.
Let me tell you a ghost story: there are already 34 publicly announced projects aiming to build Bitcoin Layer 2 solutions. And those not yet public? Probably another 60+. Combined, over 100 teams are now competing in Bitcoin Layer 2. I can’t recall the last time the crypto space saw such a crowded赛道. If I asked you right now what “Bitcoin Layer 2” means or what it’s for, I bet you’d be just as clueless as I was. Even those building these projects might only grasp bits and pieces. The rest of us have just heard the term, but we don’t really know what it is. I feel strongly that in three or four months, Bitcoin Layer 2 could become as hot as BRC-20 was last year—right now, it’s still bubbling under the surface.
Anyway, my guest today is Jan Xie. He’s the Chief Architect of Nervos CKB—the person I know who best embodies the label “technical idealist.” His background is deeply technical, with extensive experience in both the Bitcoin and Ethereum ecosystems.
We discussed how the Bitcoin Layer 2 ecosystem began and evolved, past attempts and explorations within it, and how inscriptions opened new opportunities. Of course, we also focused on CKB’s stance and strategy toward this market—and why CKB may be the ideal Bitcoin Layer 2.
2. Why Tweet That “CKB Is the Ideal Bitcoin Layer 2”?
Li Yang (Host): Recently, I saw your long Twitter thread explaining why CKB is the ideal Bitcoin Layer 2. Honestly, I was quite surprised when I saw that tweet. Can I interpret this as a Pivot (shift) for CKB?
Jan Xie: I’d say it’s both a pivot and also just continuing what we’ve always done.
The reason I made that statement is because, from a broader market perspective—especially since late 2023—there’s been a major shift. This change was triggered by the emergence of Ordinals and BRC-20. Previously, people paid little attention to the Bitcoin ecosystem or UTXO-based systems. Many believed Ethereum had already won, that the blockchain wars were over, and that Ethereum was the future—so we should all build on it.
But Ordinals and BRC-20 revealed new possibilities—showing there’s still a vast blue ocean here. Before, it was barren. BTC was passive—you could only HODL, nothing more. Even if you wanted to experiment—say, use $1 out of $100—it wasn’t feasible. Now, people realize that might actually be possible.
Whether due to wealth effects or other reasons, many users and developers have entered this space, learning how to operate on UTXO. People now talk about UTXO, its limitations—even embracing them, much like how users and developers once accepted Ethereum’s constraints. This is a huge shift.
When I see this shift, I think it’s a great opportunity to help others understand what we’re doing at CKB. Because CKB has always firmly stuck to PoW and UTXO, believing we should follow Bitcoin’s path rather than making a 180-degree turn to Account Model or PoS. In the past, trying to explain this was hard—either due to our own limitations or lack of interest. But now, things have changed. People get it: “UTXO is interesting—I’m looking into it. What else can we do on UTXO? Bitcoin has limitations—how is your UTXO different?” The baseline perception is shifting. So this feels like a perfect moment. There’s a saying: “You must strive through self-effort, but also consider the tides of history.” This is exactly that tide. The changing landscape gives us a powerful angle to explain what CKB truly is.
We can absolutely view CKB as a Bitcoin Layer 2. We can ask: What is Layer 2? How do we define it? Why does CKB fit that definition perfectly? That’s why I wrote that tweet.
Li Yang (Host): I’ve had a similar feeling—recently, people suddenly started saying “Ethereum is doomed,” while just months ago they were “embracing Ethereum.” The turnaround is so fast—it feels like everyone jumps on the bandwagon when a wall starts to fall. Quite bizarre.
3. What Is Bitcoin Layer 2?
Li Yang (Host): If CKB is a Bitcoin Layer 2, the core issue is that we’re familiar with Ethereum’s Layer 2—but most people have no idea what Bitcoin Layer 2 even means. So, what do you think Bitcoin Layer 2 actually is?
Jan Xie: Historically, the earliest concept was Off-Chain, as opposed to On-Chain.
We do many things on-chain—computation, storage, etc.—but performance and upgradeability are severely limited. So we naturally want to move some operations off-chain. This thinking led to various Off-Chain protocols. I believe “Off-Chain” encompasses Layer 2, Layer 3, Layer N—all of it.
Initially, Off-Chain structures were simple—like one-way Channels. These were discussed early in Bitcoin forums, even from Bitcoin’s inception.
Over time, the concept evolved: Can we create two-way Channels? Can we build a separate chain connected somehow? Can we do Merged Mining? Can we link bidirectional Channels into a network?
Looking back, Off-Chain has a clear evolutionary path—people gradually added more complex concepts and structures. Simple designs evolved into sophisticated ones, eventually forming finer classifications. We can broadly split them into Layer 2, then further into Channel-based vs Chain-based—essentially these two categories.
So, even before Ethereum emerged, Off-Chain protocols were already a well-studied field. However, progress was limited by Bitcoin’s own capabilities. Due to programming constraints, development could only advance in small steps.
After Ethereum arrived, the journey was winding: first Sharding, then State Channels, Plasma, and finally settling on Rollups. Ethereum developed over a long period, ultimately adopting a Rollup-centric roadmap. Ethereum declared Layer 1 should optimize for Rollups—so even Sharding plans had to adapt, adding more data availability for Rollups on Layer 1.
I think it’s human nature to focus on the most recent memory. Right now, Rollups dominate attention—so when people think Layer 2, they default to Rollups. This is natural, especially for casual observers outside the core research and developer circles. But if you look back at the full history of evolving solutions, the concept of Layer 2 becomes much broader.
So if you ask me for a definition, I’d say Layer 2 is first and foremost Off-Chain—it’s not on the main chain. But it maintains some direct link to Layer 1. A Layer 3 would link to Layer 2, not directly to Layer 1—that’s the meaning of “layer.”
Layer 2 should enhance Layer 1 in key areas—performance, programmability, or privacy. Broadly speaking, Layer 2 can solve scalability, smart contract capability, or privacy issues. It must have a direct connection to Layer 1—whether via consensus mechanisms like Merged Mining, a bridge (called Two-Way Peg in Bitcoin, Bridge in Ethereum), or any other form of linkage—technological or even economic.
That’s my broad definition of Layer 2.
Li Yang (Host): Regarding definitions, in the Bitcoin ecosystem, at least for now, no one has officially defined what Layer 2 is. I don’t know if that’ll ever happen.
Jan Xie: I think this is precisely what makes the Bitcoin ecosystem more fun. Everyone can have their own interpretation. Teams in the Bitcoin ecosystem don’t need to worry about Satoshi suddenly appearing tomorrow to declare their project invalid. That kind of random event probably won’t happen in Bitcoin. But in return, you face fiercer competition—you need stronger capabilities, because no one will step in to validate or invalidate your work. You’re on your own.
4. Influential Bitcoin Layer 2 Projects
Li Yang (Host): Among existing Bitcoin Layer 2 projects, which ones are influential or promising?
Jan Xie: Let me list a few—my list may not be exhaustive.
The most impactful is clearly Lightning Network. It’s been around a long time, progressing steadily. Technically, it keeps iterating—though externally it still looks like “just Lightning.” Personally, I love Channel Networks.
Its advantage is theoretical scalability without upper limits—unlike other schemes that hit protocol-level bottlenecks. Channels don’t have that problem. But engineering implementation faces many challenges, hence the slow progress. That’s the fascinating part: the harder something is, the more interesting—especially when it’s theoretically possible but practically elusive.
For example, in a Channel Network: A→B, B→C, C→D. A wants to send money to F. The payment can be split—say, 10 units of $1 each—sent along different paths. How do we ensure all ten $1 payments either succeed together or fail together?
This is a classic graph theory problem—or something network engineers face often. Internet packet routing works similarly: data packets split and travel multiple paths. But in value networks, this becomes extremely complex because we’re transferring assets, not data.
What’s the difference? When transmitting data, the channel capacity (e.g., between two computers) is effectively infinite—we can keep sending. I can message you endlessly—the channel doesn’t degrade. But in value networks like Lightning, transferring funds consumes channel capacity. Suppose I start with $100 on my end, $0 on yours. After sending ten $10 transfers, I’m out of funds, you have $100. I can’t send more—the channel is exhausted.
These differences make Lightning’s value network far more complex than data networks. And because it involves money, security adds another layer of complexity. Despite these hurdles, Lightning has advanced steadily. For years, people criticized “Lightning is too slow—Bitcoin isn’t progressing.” But I disagree: the problem is simply that hard. We’re not comparing problems of equal difficulty. Channel-based Layer 2 is inherently harder than chain-based. Lightning also sets an exceptionally high bar—it aims to solve privacy simultaneously, which further complicates everything. When you try to run Lightning over TON, every hop must protect privacy—making the whole system vastly more complex.
Anyway, I really admire this project. To conclude: Lightning is a Layer 2.
Next is Liquid, a sidechain built by Blockstream. Its original paper explicitly called itself a Sidechain. Liquid uses PoA (Proof of Authority) consensus—essentially a multi-sig where, say, 10 parties take turns producing blocks. The bridge between Liquid and Bitcoin—known in Bitcoin terms as a Two-Way Peg—is also multi-sig. So it’s a multi-sig sidechain connected via a multi-sig bridge.
What’s interesting about Liquid is twofold: it helps Bitcoin scale by enabling cheaper transfers, and it serves as a testing ground for Bitcoin’s best ideas and technologies. It’s structurally similar to Bitcoin Layer 1 but introduces features difficult to implement directly on Layer 1—like privacy enhancements or Covenants.
With these capabilities, you can build Layer 3s on top of Liquid—for instance, deploying Lightning on Liquid. Normally, Lightning’s Open/Close transactions settle on Layer 1. But if Lightning settles on Layer 2 instead, its capacity increases significantly.
So Liquid is a great experimental platform. If you’re okay with its centralization and trust assumptions, the user experience is better—lower fees, and it’s UTXO-based like Bitcoin.
Another project adds an EVM layer atop Bitcoin via merged mining—Rootstock. It’s a solid project with strong technical foundations and consensus improvements.
However, merged mining has issues: it essentially delegates Layer 2 security to Bitcoin miners. Miners may not care about Layer 2’s health—if Layer 1 survives, they keep earning block rewards regardless. Thus, merged mining is often criticized: a majority of Bitcoin hash power could easily attack any merged-mined chain. This is a valid concern for Rootstock. Other projects on this path—like Drivechain—are exploring ways to address this, perhaps via incentive alignment. These are meaningful explorations.
Then there’s Stacks, which recently underwent a major redesign, bringing it closer to Bitcoin. In my view, Stacks remains a Sidechain despite adjustments. Its new design uses various methods to argue how Stacks binds to Bitcoin Layer 1’s consensus and stores data on Bitcoin—so when Bitcoin finalizes, Stacks finalizes too. Still, I see it as a Sidechain.
Stacks has several interesting aspects. First, its consensus—PoX (Proof of Transfer)—requires locking BTC on Layer 1 to participate. Second, it ties consensus to bridge design: you must stake Stacks’ native token STX to join the bridge’s multi-sig. While still a multi-sig bridge, participation is permissionless—anyone staking STX can join. Benefits include earning BTC rewards: transaction fees paid in BTC, plus BTC from PoX participants. It’s a clever design.
On Stacks, programmability is stronger—you can do more. They designed Clarity, a safer, formally verifiable language.
Overall, this upgrade tightly couples Stacks to Bitcoin at both consensus and bridge levels—shifting from a loosely connected strategy to a deeply integrated one.
Recently, there’s Babylon—a Staking Layer, not a sidechain. Babylon allows direct staking of BTC on Bitcoin to secure other Layer 2 chains. It’s somewhat like Ethereum’s EigenLayer, but for Bitcoin: using BTC staking to secure PoS-based Layer 2s.
Those are the most notable Bitcoin Layer 2 projects I can recall.
Li Yang (Host): Aside from Babylon, which is relatively new, the others are quite old—three to four years, Lightning even older. I’m fairly familiar with Lightning and Stacks, but rarely hear about Liquid’s progress. My impression of Lightning is like scientists working on nuclear fusion—brilliant but incredibly hard, with no clear timeline. As for the others, it’s unclear what problems they’re solving, or whether users care. Am I wrong?
Jan Xie: Not entirely. Looking ahead, I believe various Layer 2 types will coexist.
Lightning stands apart—it’s channel-based, fundamentally different in architecture. Channel-based and chain-based Layer 2s each have pros and cons. I personally love Lightning and channel-based designs, but they have drawbacks.
First, channel liquidity management is tricky. As I mentioned earlier, to send funds via a channel, you need funds on your end. If you’re a new user opening a channel, you must deposit funds upfront—which is cumbersome for average users.
Second, managing liquidity is complicated. If you constantly send money—one-way traffic, like a boss paying an employee—after three paychecks, your end runs dry. You must close and reopen the channel, or find a way to replenish liquidity. Each option is burdensome. Simply closing/reopening means submitting a Layer 1 transaction—annoying and costly.
Also, if someone wants to send you money, you need an open channel. Contrast this with rollups: as a new user, you don’t need prior interaction. As long as someone sends to your address, you can later claim funds using your private key—no setup required. Much more user-friendly for individuals.
Channel management is full of such hassles. Opening channels requires setting fees; closing might incur high fees if conditions change, requiring complex fee adjustment mechanisms—another pain point.
Overall, channel-based Layer 2s seem unsuitable for average or consumer (C-end) users. If you’re a regular person who dislikes complexity, or willing to trust third parties—or treating $100 as disposable pocket money—chain-based Layer 2s are perfect.
I see Lightning fitting B2B use cases. If you’re a business with real needs, you might value its privacy and extreme scalability—and have the expertise and willingness to manage channels. Businesses can afford dedicated teams—imagine a bank hiring staff just for channel ops. Consumers likely won’t bother. Conversely, consumers prefer rollups or sidechains—more accessible.
How do these chains transfer liquidity? Here, channels can help—they enable cross-chain liquidity if connected to multiple chains within a larger network.
Long-term, these projects and approaches may coexist—and complement each other.
5. Will Inscriptions Greatly Accelerate Bitcoin Layer 2 Development?
Li Yang (Host): Before inscriptions, there wasn’t much demand for C-end user solutions—perhaps because they weren’t mature enough. Or maybe people just held Bitcoin passively. With inscriptions, many started actively transacting on-chain. Do you think this resurgence will greatly accelerate Bitcoin ecosystem or Layer 2 development—making it more focused?
Jan Xie: Absolutely. The inscription craze resembles Ethereum’s ICO era—many share this view, and I strongly agree.
Inscriptions attract new users and create new assets. But they don’t solve Bitcoin’s core limitation: beyond issuing assets, there’s little to do. Ethereum differs—its Layer 1 supports diverse applications. Post-ICO, you could keep building on Ethereum. On Bitcoin, after issuing an asset, further actions require Off-Chain or Layer 2 solutions.
Thus, I believe inscriptions will drive significant attention, users, and capital into Off-Chain/Layer 2 ecosystems.
6. How Will CKB Approach Bitcoin Layer 2?
Li Yang (Host): So how will CKB approach Bitcoin Layer 2?
Jan Xie: Within the Bitcoin Layer 2 framework, CKB fits the Sovereign Chain category. Upon research, you’ll find Sovereign Chains—chains with independent consensus, linked to Bitcoin. CKB has its own consensus and PoW.
For CKB to serve as a BTC Layer 2, a bridge between CKB and BTC is essential. This bridge can be centralized, decentralized, or hybrid. It’s a prerequisite—enabling BTC assets to move to CKB for broader utility.
Beyond bridges, CKB has unique properties distinguishing it from other Bitcoin Layer 2s. For example, CKB supports various signature schemes—meaning Bitcoin wallets can directly interact with CKB apps. Like how Ethereum Layer 2s are expected to work with MetaMask.
This continuity matters to users—it lowers barriers. Imagine Bitcoin users switching from UniSat on Layer 1 to MetaMask on Layer 2—awkward.
On CKB, you can lock assets to a Bitcoin address and unlock them using a Bitcoin wallet. From a user’s view, they remain within the Bitcoin ecosystem—even if operations occur on Layer 2. They might not even realize they’re using Layer 2.
In this regard, CKB might offer a smoother experience than Lightning—users barely notice transitioning between layers. Bridges and UX are strengths CKB can leverage.
For developers arriving at Layer 2: do they enter an EVM account-model world, or stay in the UTXO world? Both types exist. CKB suits developers who appreciate Bitcoin’s architecture, enjoy working in UTXO, and are comfortable in both worlds. Others might dislike context-switching—using UTXO one day, accounts the next. That mental shift is taxing—especially for bridge development, requiring contracts on both layers. But if you only build on Layer 2, the model may not matter.
For developers, CKB’s advantage is its structural similarity to Bitcoin—familiar and convenient, with expanded capabilities. So CKB’s priorities are user and developer experience: robust bridges, comprehensive tools—making app development seamless.
Li Yang (Host): Earlier you said users can use UniSat for both Bitcoin and CKB. Does UniSat need to adapt to support CKB?
Jan Xie: No adaptation is needed from UniSat. Any Bitcoin wallet with a signing interface works. Compatibility is handled within CKB’s contracts, which can verify signatures. Regardless of signature or hash algorithm, the wallet signs a transaction, and the on-chain contract verifies it.
CKB supports various cryptographic algorithms—original Bitcoin Secp256k1, Schnorr, etc.—all implemented. Implementation is easy because CKB uses a RISC-V VM. Bitcoin’s crypto code can be directly ported. Whether written in C or Rust, it runs natively in CKB’s VM.
This differs from Ethereum. Porting to Ethereum requires rewriting C/Rust code into Solidity—costly, error-prone, and potentially insecure. Even if successful, performance suffers. Hence, few attempt it.
These issues don’t exist on CKB—explaining its flexibility with cryptographic algorithms. This enables seamless support for wallets like UniSat.
Li Yang (Host): So I can use UniSat throughout—to migrate Bitcoin to CKB, then perform subsequent operations like minting or trading inscriptions on CKB.
Jan Xie: Yes.
Li Yang (Host): That’s a solid experience—I hate downloading new wallets. For users, installing a new wallet—psychologically and practically—is a big hurdle.
Jan Xie: Exactly. Among Layer 2s, those preserving Bitcoin’s user and developer experience form one category. Others target different niches with distinct audiences.
7. What to Do After Migrating Bitcoin to Layer 2?
Li Yang (Host): From Ethereum’s experience, Layer 2s incompatible with EVM or MetaMask struggle to gain traction or migrate users. So after migrating Bitcoin to CKB, what comes next? What can developers and users do?
Jan Xie: Great question. Actually, many things are possible because CKB is an enhanced UTXO model. Jian wrote an excellent article titled Understanding CKB Programmability Through Bitcoin Application Programming—highly recommend it. He explains it very clearly.
Key improvements are at two levels. First, the virtual machine: Bitcoin only supports Bitcoin Script—a simple, Forth-like language with limited instructions and expressiveness.
On CKB, we fully implement the RISC-V instruction set—a mature, industry-adopted, open-source chip architecture. GCC and LLVM can compile to RISC-V, enabling diverse programming languages on CKB. This vastly expands instruction-level expressiveness.
Second, UTXO model enhancements. On CKB, each UTXO can store arbitrary additional data—not just sat amounts and ownership.
On Bitcoin, a UTXO stores only sats and owner info.
On CKB, a UTXO can hold extra data: a song, image, file—or a TypeScript defining data rules. For example, storing a poem with a rule: edits can only append, never modify prior content, and only specific users can append. This enforces data mutation rules—an improvement.
Additionally, CKB scripts can read data from other UTXOs—unlike Bitcoin. This enables easy implementation of features like Covenants. A Covenant lets a UTXO script specify constraints on future UTXOs created when spending—e.g., requiring certain scripts or addresses.
Without Covenants, you have no control over new UTXOs—they can be set freely. With Covenants, you can constrain future UTXO chains. This property is crucial. Its presence determines whether Bitcoin can support Rollup-like Layer 2s. Without it, perhaps not; with it, yes. That’s why Covenants are now a hot topic—debates about adding them to Layer 1. But on CKB, they’re natively supported.
With these capabilities, CKB supports various FTs (Fungible Tokens), NFTs, DeFi, DAOs, governance, Autonomous Worlds, fully on-chain games—anything possible on Ethereum.
Essentially, you can build anything feasible on Ethereum. The difference is like developing on iPhone vs Android—different underlying architectures. CKB’s UTXO structure resembles Git. GitHub, the world’s largest programmer social site, hosts countless code repositories powered by Git—a version control tool.
CKB is like a shared global Git—like GitHub. You can store anything: C code, Python, poetry, articles, blogs, images, binary files—anything, even obscure binaries only you understand.
CKB is such a shared repository. Every file has clear ownership—this file belongs to Li Yang (only he can edit), that to Jan. Some files are shared—anyone can edit, but changes require passing checks defined by contracts. This global data store—its storage, modification, and validation rules—is secured by a PoW consensus. On such a foundation, you can build anything—any application imaginable.
Li Yang (Host): When you mentioned iPhone and Android, I had a thought: Is Bitcoin like an original open-source Android, with Ethereum influenced by it, creating a more feature-rich but Apple-controlled model? Now CKB might be like an advanced Android built on that open foundation.
8. CKB: Contract Kernel of Bitcoin
Li Yang (Host): I recall Yang Min commenting: “CKB: Contract Kernel of Bitcoin.” What does “Contract Kernel” mean?
Jan Xie: He views Bitcoin as an asset issuance and storage layer. We use Bitcoin as a highly secure vault for value storage.
But this vault is empty. To put assets to use—building products and applications—we need an execution engine to run logic.
The Contract Kernel is that execution engine. It complements a SOV Layer 1: store assets on Bitcoin Layer 1, issue tokens like inscriptions, then use them on a more capable Layer 2.
Li Yang (Host): So we can move not only Bitcoin but also inscriptions to CKB?
Jan Xie: Yes. This extends Bitcoin’s design philosophy: do Verification on Layer 1, move Computation Off-Chain. The Contract Kernel—or execution—is synonymous with computation. Move computation to CKB, leave verification on BTC.
Interestingly, for CKB, each Layer 2 may handle both Verification and Computation relative to BTC. A Layer 2 performs Computation for BTC but Verification for its own Layer 3. For Bitcoin, the Contract Kernel is a computational layer.
9. Layer 2 Can’t Match Layer 1 Security
Li Yang (Host): One interesting point: when discussing Bitcoin Layer 2s, their security relationship with Bitcoin Layer 1 seems looser than Ethereum’s tight Layer 1–Layer 2 bond. Ethereum Layer 2s are currently arguing—some smaller ones want independence, refusing to “pay taxes” to Layer 1. But in our Bitcoin discussion, we haven’t touched on this—taxation, tighter bonds. Is the relationship indeed looser?
Jan Xie: Yes, likely due to differing Layer 2 development paths. Ethereum was forced toward Layer 2—first Sharding, then realizing Layer 1 couldn’t scale. Bitcoin faced the same constraint—Layer 1 can’t do much. But Bitcoin’s limitation existed from the start, so Layer 2 was considered early. Ethereum adopted Layer 2 later. Once there, with Core Teams driving direction, they tightly bind Layer 2 to Ethereum Layer 1—primarily via security. This makes sense: like courts, higher courts overturn lower rulings, granting Layer 2 equivalent security.
But Layer 2 cannot achieve Layer 1-level security—due to inherent constraints. Bitcoin has fundamental limitations preventing it.
I tweeted recently: if you insist on Layer 1-equivalent security, channel-based Layer 2s like Lightning might come closest—similar to Rollups. The main risk is withdrawal during Layer 1 congestion: high fees delay your exit transaction. Otherwise, security holds.
But for chain-based Layer 2s on Bitcoin, matching Layer 1 security is extremely difficult without Layer 1 hard forks adding functionality. The core issue remains Bitcoin’s limited capabilities—especially lacking a secure Two-Way Peg (2WP) or bridge.
We can securely bridge from Bitcoin to a Layer 2 chain—since the Layer 2 can run a Bitcoin light client or SPV client to verify events. But reversing—Bitcoin verifying Layer 2 events—is impossible. Bitcoin lacks the capability to run a light client for external chains. Thus, moving assets from Layer 2 back to Layer 1 faces inherent limitations—bridge designs must make trade-offs. This is a fundamental constraint: perfect security is unattainable.
Conversely, should Layer 2 even aim for Layer 1-level security? This premise deserves scrutiny. It’s a proposition—popularized by Ethereum communities—but is it necessary? Not necessarily. The essence of Layer 2, to me, is sacrificing some security, decentralization, or trustlessness to gain other benefits. Layer 2 is about trade-offs. The only no-trade-off solution is doing everything on Layer 1—but that’s infeasible, hence moving things Off-Chain.
Is there a silver bullet—moving Off-Chain with zero downsides? I believe not. Even Rollups and Channels have edge cases that are hard to resolve.
Therefore, we must accept that Off-Chain or Layer 2 solutions always involve trade-offs. Marketing often highlights benefits, ignoring drawbacks or prerequisites—prerequisites often overlooked more than downsides.
For example, a current debate claims “Validium is less secure than Rollup.” This hides many assumptions. Validium is a ZK-Rollup, but its data availability (DA) relies on a separate DA layer, not Ethereum. The conclusion assumes that alternative DA layer is less secure than Ethereum. But consider: what if Bitcoin served as the DA layer? Would such a Validium be more or less secure than a Rollup? You’d then need to argue Ethereum is a more secure DA layer than Bitcoin—which may not hold.
On Twitter, these nuances go unmentioned—character limits prevent deep dives.
My point: going Off-Chain is a compromise—acknowledging Layer 1 scaling and expansion are unrealistic. Bitcoin’s community embraces this earlier because Bitcoin was constrained from the start. Ethereum’s community initially viewed Layer 1 as omnipotent, so naturally expected Layer 2 to inherit that. Perhaps Ethereum needs more time to accept trade-offs as inevitable.
Li Yang (Host): Ethereum’s community feels youthful—I reject trade-offs. Though I consider myself young, lately I see trade-offs everywhere.
Jan Xie: People dislike hearing about trade-offs. They prefer “I want both, I can have it all.”
10. How Will Bitcoin Layer 2 Evolve?
Li Yang (Host): How do you see Bitcoin Layer 2 developing?
Jan Xie: Bitcoin’s halving arrives in April—I expect the first wave of Layer 2s around then. With timing fixed, teams chasing this window must rush—prioritizing speed over perfection to capture early market share. I foresee an initial wave, followed by recognition of flaws—much like the inscription saga.
Initially, BRC-20 leveraged Ordinals to write data, relying on Indexers. At first, everyone was happy—later, issues surfaced: inconsistent indexers, centralization risks worsening over time. Then came Atomicals and others attempting fixes.
Layer 2 will mirror this. An initial wave emerges around April. Later, teams recognize problems—whether copying Ethereum Layer 2 models or otherwise—and seek solutions tailored to Bitcoin’s nature.
Thus, one or two waves may emerge, paralleled by Layer 2 application projects building diverse apps.
Current Layer 2s prioritize expanding contract capabilities—EVM, Wasm, or CKB’s RISC-V. Privacy isn’t a focus—too hard, too slow. Scalability matters less—anything faster than Bitcoin suffices, given Bitcoin’s low baseline. Focus is on enabling diverse applications.
For ecosystem growth, EVM offers immediate advantages: mature tools, codebases, and developers—fastest path. But I’m unsure if EVM best suits Bitcoin. Bitcoin has its own UTXO model, values, etc.—many differences. Yet this won’t stop the first wave from taking this shape.
Later, as more people enter, study Bitcoin and UTXO characteristics, novel ideas will emerge—designs increasingly tailored to Bitcoin, not mere grafts.
11. AMM or Order Book—Depends on Layer 2 Design
Li Yang (Host): Ethereum’s ICO boom centered on ERC-20; Bitcoin’s centers on inscriptions. Clearly, inscriptions differ vastly from ERC-20—even on Layer 2, they won’t vanish, likely dominating early assets. Naturally, inscription lending and trading demand unique infrastructure.
Jan Xie: What differences do you mean?
Li Yang (Host): For example, I doubt AMMs can directly meet inscription trading needs.
Jan Xie: Not necessarily. Once inscriptions bridge from Layer 1 to Layer 2, their suitability depends on Layer 2’s design. If it’s EVM-based, implementing an AMM is straightforward.
Clarify: “inscription” may mean Inscription or BRC-20—distinct concepts. Inscriptions (NFTs) don’t suit AMMs. BRC-20 tokens (FTs) can enter AMMs on Layer 2 without issue.
Ultimately, it hinges on Layer 2’s architecture. If Layer 2 is UTXO-based, AMMs are possible but may not be optimal—Order Books might suit better, dictated by UTXO structure. Conversely, AMMs thrive in account models. Ethereum saw Order Book DEXs, but they died—Uniswap prevailed.
So, the choice heavily depends on Layer 2’s specific design.
I believe inscriptions—as valuable assets—can adapt to any Layer 2. Assets are like water—highly liquid, shapeless, able to mold into any application. That’s my view.
12. What Determines Competition Among Layer 2s?
Li Yang (Host): Among so many Layer 2s, what will determine success?
Jan Xie: First, seizing big opportunities—like Bitcoin’s April halving—is crucial. Entrepreneurs use various methodologies—“capturing time windows” is one. If you believe investing heavily now—winning 70% market share in three months—means survival, that’s a valid strategy.
But another view exists: we strongly believe in Bitcoin’s long-term future. Like standing in 2016–2017 during ICO mania—believing you must seize the window or perish. In hindsight, that’s flawed: ICOs sparked multiple development phases. Many successful Ethereum projects emerged long after ICOs—some survived, others arose later. That’s another path.
Some teams excel at capturing market windows; others don’t. This applies across Web3, crypto, and other ventures. Neither method guarantees victory. Individually, no strategy ensures success. But macroscopically, due to the law of large numbers, 1–2 projects may survive this phase—winners who continue growing, possibly multiplying 2x or 10x each stage, becoming giants. Or they may fade later—possible outcomes.
I believe some will win this phase—a race against time. Fastest teams gain advantage: clearly understanding market desires, allocating resources aggressively to capture share. Teams with this mindset may lead.
Li Yang (Host): Is speed your strategy?
Jan Xie: Speed isn’t our trait—we’re known for being slow.
13. Nervos’ Strategy
Li Yang (Host): If you’re slow, what’s your annual strategy?
Jan Xie: Slowness was an initial design and team culture choice. As many know, Nervos is technically strong—whether building a Layer 1 or, as now framed, a Bitcoin Layer 2. Security is paramount—prioritizing security inherently slows progress.
We also adopt a long-term mindset. We see many tasks requiring sustained effort. Another startup approach: test an idea for three months—fail, pivot, restart. Lightweight, flexible. But Nervos isn’t that. We consider more.
If you ask about our yearly strategy, we continue favoring a small Core Team, empowering community-driven growth. Some criticize this—such projects face inherent disadvantages.
Compare Solana: a strong central Core Team concentrating resources to push initiatives. Nervos chooses otherwise—a deliberate choice. Opinions vary: you might call it unfit for markets or eras. But this is our core strategy: minimal Core Team, maximal community enablement.
Crypto originated from ideals—we aim to advance those, avoiding Web2’s pitfalls—a regrettable path. I joined the internet post-1995—experienced dial-up (now forgotten), forums, chat rooms. In college, we had BBS via Telnet—a relic then. I lived through a vibrant, authentic forum era—deeply nostalgic. That was Web2’s purest spirit—gradually lost post-2000, for various reasons.
Today’s social networks differ fundamentally—perhaps due to scale, but the atmosphere changed. Maybe Web2’s stateless protocols—requiring centralized data custodians—inevitably concentrate data in big corporations, causing cascading issues I won’t detail.
Web3/blockchains revived hope—perhaps we can reclaim the internet’s original vision. I dread Web3 repeating Web2’s arc: initial excitement, gradual disillusionment, eventual regression. I fear this strongly—current trends suggest our ideals may collapse. Warning signs are visible.
Back to Nervos: we aim to preserve and amplify those original ideals—finding a path forward
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
@CKBEcoFund
