Author: Duncan Source: blocmates Translation: Shan Ouba, Golden Finance
While runes have stolen the spotlight, Bitcoin developers are still working hard - introducing a "Frankenstein" on the world's most trusted blockchain. These solutions come in many forms, and you might be mistaken for thinking that Bitcoin's Layer-2 technology is more venture-backed sophistry (Guǐ biàn shù - Gish gallop) than the ultimate frontier of finance.
But dear reader, please note that Bitcoin's potential is far greater than people think.
Bitcoin has layers, just like an onion.
In the case of Bitcoin, there is Layer-2 technology, an emerging narrative that promises to bring Bitcoin to the promised land of abundant, high returns in decentralized finance.
But, like an onion, there are different kinds of Layer-2, and how they are handled is crucial.
But what is substance and what is hype? Will all these fancy technologies bring in new users or just create more people holding onto their coins?
What is Layered Technology?
In blockchain development, when we think about Layer-2, we think about scalability: how can we make Bitcoin faster, better, and more powerful? Bitcoin itself is a bit slow, and its basic use, besides being a store of value, is peer-to-peer token transfers. When we talk about Layer-2, we mean doing transactions in a reasonable way and within an acceptable time, such as using Bitcoin in a smart contract to do something meaningful.
This scaffolding already exists on Ethereum's Layer-2, such as Optimism and Arbitrum, which batch transactions and then submit them back to the main network. Bitcoin Layer-2 developers have cleverly borrowed these concepts and implemented them with varying degrees of complexity.
Overall, the concept is the same: Bitcoin Layer-2 is designed to make Bitcoin more robust to use.
Menu: How Developers Are Cooking Bitcoin Layer-2
Think of the different ways an onion can be cooked. It can be a side dish that elevates the dish, or it can play a key role, or even be the star of the show. With Bitcoin Layer-2, developers are also thinking about how to use Bitcoin. Keep it simple, or build a completely custom solution?
It turns out that these solutions can differ in the technical details. Luckily, I’ve prepared a menu for you with some of the key dishes I’ve picked out. (I avoided the 50-course restaurant-style menu.)
In a nutshell: Citrea
In a nutshell, I will present Citrea. Other solutions that fall into this category include Stacks, Build on Bitcoin (BOB), and SatoshiVM. They all focus on the core aspects of Layer-2: block space scalability and smart contract usage. It sounds complicated, but it's not.
Citrea is a zero-knowledge (ZK) rollup designed to expand Bitcoin's block space. As a rollup, it inherits Bitcoin's security and batches transactions, and verifies validity proofs through BitVM on Bitcoin.
Citrea also uses a two-way anchor mechanism between Bitcoin and itself, and is compatible with the Ethereum Virtual Machine (EVM) through BitVM, which allows Bitcoin to process (Turing-complete) smart contracts offline.
It’s important to note that Citrea is a rollup, not a sidechain - just like garlic and onions are from the same family, but completely different. It aims to scale blockspace, not transaction throughput - that is, focusing on storing blockchain information more efficiently, rather than the number of transactions processed on the L2.
In Citrea’s case, validity proofs are written into Bitcoin, allowing transaction batches to be easily aggregated. An important difference is that these inscriptions are optimistically validated - all transactions are considered valid until proven otherwise, and fraud proofs are used to challenge illegal transactions.
So, what role does ZK technology play in Citrea? First, transaction data is not published to Bitcoin itself, only the inscriptions. This allows Citrea and other Bitcoin L2 solutions that use a similar paradigm to provide some guarantees in terms of user privacy.
Second, it provides a trust-minimized bridge that enables bidirectional pegs between Citrea and Bitcoin, with withdrawals only possible with valid ZK proofs. Citrea uses ZK-STARK proofs (Zero-Knowledge Succinct Non-Interactive Arguments of Knowledge) to leverage light clients to recursively verify batch proofs.
Now, this sounds a lot like “the taste of onions is controlled by thiosulfite” — which sounds like bullshit to the average user. There are a lot of important technical details involved, but in practice, the appeal of this solution lies in its simplicity.
If we think of Citrea as just another rollup like zkSync, Arbitrum, or Optimism, then all the fancy-sounding ingredients are easier to understand. Of course, they are not exactly the same, especially at a technical level; rather, it is just a loose analogy for comparison. Imagine using native Bitcoin on Citrea, where instead of trusting a third party to custody your Bitcoin, you control its use: you only need to trust the open source code. This is a strong appeal of Citrea.
Made for you: Bison
Some teams have taken different approaches to using Bitcoin natively. In fact, there are quite a few solutions that rely on using the EVM to facilitate their form of DeFi. Bison Labs addresses this with its Bison product suite, which consists of Bison Network, Bison OS, and Bison Prover.
Bison cites its own analogy: Bison is to Bitcoin what Starknet is to Ethereum. Similar to Citrea (and some other solutions), Bitcoin network inscriptions are used as a DA (data availability) layer, which enforces the immutability of data and allows for easier data retrieval from the chain. They also use a Zero-Knowledge Scalable Transparent Argument of Knowledge (ZK-STARK) approach for their rollups.
Bison Network has components that are native to rollup and smart contract functionality. These components include L2 Dapp logic, sequencer and token contracts, and bridge contracts. Essentially, we can think of Bison as a high-level form of “native Bitcoin DeFi” that doesn’t leverage (or rely on) the EVM to handle this work.
For the fans of cooking analogies here, Bison suggests adding raw onions to dishes instead of sautéing them in olive oil every time “because it tastes better.”
Spider on a Dish: Botanix
Other teams have taken a completely different approach to leveraging native Bitcoin. If you’re looking for something exotic, look no further than Botanix, which proposes implementing Proof-of-Stake on its own Layer-2. Yes, it’s new.
Bitcoin's Proof of Stake (PoS) looks different than other PoS networks, which distribute revenue to stakers through inflation, block rewards, or both.
In Botanix, stakers lock up their Bitcoin and generate fees through base transaction fees, priority transaction fees, and "down fees" generated when users want to bridge from Botanix to Bitcoin. In theory, the base reward for blocks on Botanix is 0. This means that Botanix benefits from higher user adoption. (Not surprising at all!)
Botanix secures staked Bitcoin in an architectural model called “Spiderchain.”
Spiderchain is “a series of continuous multisigs between Botanix Orchestrators,” essentially a “full node” for the Botanix protocol. On every Bitcoin block, a new multisig is created between randomly selected valid coordinators.
The Bitcoin in the multisig cannot be accessed by the orchestrator without receiving a majority of the symbols in the random multisig, which are controlled by the amount of Bitcoin staked by the orchestrator themselves, which means they must control 2/3 of the stake themselves. This security model means that as the network becomes more decentralized, the more orchestrators there are, the more secure it becomes.
Now, it is worth noting that Bitcoin is "native" in that it exists on the Spiderchain. All Bitcoin in Botanix's EVM portion is synthetic. If user Alice bridges from Bitcoin to Botanix, her Bitcoin will be locked in Spiderchain, and she will receive synthetic Bitcoin to use on the Botanix EVM.
When she wants to bridge back to Bitcoin, the synthetic Bitcoin is burned and she receives Bitcoin from Spiderchain. This is called “pegging” and “pegging” respectively, as the supply should remain pegged 1:1.
Is Botanix truly unique — like eating spiders? I don’t know. It could be disgusting, or it could be the most delicious dish I’ve ever had. All I know is that it’s definitely cooked with onions.
That magical touch: where do they overlap?
Now you might be wondering: will this article ever mention onions again? The answer is yes! Did you know that cocktail onions are the garnish for Gibson’s martinis? If not, now you know! There are onions everywhere in this article. You can’t escape it.
Similarly, there are some key components that are present in multiple Bitcoin Layer-2 solutions. The main commonalities are the use of BitVM and the use of inscriptions as a data availability layer.
BitVM technically allows fraud proofs to be enabled on Bitcoin. Computations performed through BitVM are simply verified - similar to optimistic rollups - but contain elements inherent to zero-knowledge rollups, such as obfuscating transaction details and using trust-minimized bridges.
You'll also notice that most Layer-2 solutions leverage EVM compatibility to leverage the power of smart contracts and the existing developer base on Ethereum.
Some of the differences you may see is whether the solution uses a token. For example, Merlin Chain, Map Protocol, and SatoshiVM all have their own tokens. They are not necessarily used as gas fees and have different applications.
So, does it really matter?
Well, it depends on what kind of dish you're cooking, right? Raw onions, cooked onions, sautéed onions, grilled onions... you get the idea. The core of all this Layer-2 talk is technical, and yes, if you're cooking, and to some extent, if you're going to eat whatever you're cooking, then it does matter. But for the average user, no, it probably doesn't matter - that's the price of ubiquity.
What does this mean for your portfolio? Well, it probably comes down to user experience. If Citrea is clunky to use, even though I think it's straightforward, then people probably won't use it. Bison and Botanix may look daunting on paper, but they may be revolutionary UX.
But even so, UX is a different science. It goes back to whether people prefer raw, cooked, sautéed, or grilled onions: the market will go where the demand is.
Ultimately, Bitcoin Layer-2 represents a big step toward greater user adoption, and products will go where there’s market demand. If people like eating onions with spiders in them, who’s to judge them?
Summary
Over time, complex technologies become simpler and easier to understand, allowing people to better understand and use them (thus improving the user experience). Sometimes you do need a more complex solution. Adoption of any kind is generally a positive for your portfolio.
Technology is great when your portfolio is going up: adoption drives technological improvements, which lead to new, more complex solutions. In general, the more attention a cryptocurrency gets, the greater the development support — in other words, the more likely your portfolio will profit.
But we’re talking about Bitcoin here. It’s widely assumed that Bitcoin’s value will go up no matter what. What we’re interested in is whether the technology will be adopted first. In a layer-2 environment, we could see Bitcoin used as money in different scenarios (wow, what a crazy idea!).
We should ask ourselves: Is Bitcoin too entrenched as a store of value or market hedge to seriously consider this?
I think initially, this will appeal to holders who just want to increase their Bitcoin holdings. The question will always be who will try it first, and for those who succeed, their risk will be well rewarded. However, for most people, Bitcoin will remain in its current function: store of value and risk hedge.
Again, see a need, meet a need; if the market demands onions cooked a certain way, paired with certain dishes, they will get them. As to whether they will be eaten regularly, that is another matter.
Conclusion
Personally, I am interested in native solutions like Bison. I think there is a market need for a solution like Botanix, and I think a perfect marriage between the two is the best solution.
Of course, I think there is enough interest in the market to justify its development, but I think it will only be a small part of Bitcoin's total market cap, and the technology as a whole has a long and interesting road ahead.
What do you think? Is it better for Bitcoin to be used in a native way or to keep operating in its current form?