This article is reprinted from "Geek Web3", original link: https://mp.weixin.qq.com/s/SyZgWBBq1dPkQx8HOAh60w
On July 22, 2024, "Geek Web3" had the honor of inviting Cipher, co-founder of CKB and proposer of RGB++, to discuss RGB++ and the UTXO system, CKB itself, and the Bitcoin ecosystem. During the conversation, Cipher talked about his past experiences, the unique significance of the RGB++ Layer and UTXO model for BTCFi, and shared some questions and views regarding CKB and the Bitcoin ecosystem.
The specific topics covered in this interview include:
- Cipher's personal experiences
- The relationship between UTXO Stack and RGB++ Layer
- Views on Bitcoin Layer 2 and BTCFi, especially EVM-based Layer 2
- Unique scenarios and development concepts of RGB++ Layer compared to EVM-based systems
- Interpretation of the design philosophy of CKB itself
- How to address some shortcomings of the UTXO model in DeFi ecosystem construction
- Why CKB chose RISC-V and the related choice of contract development languages
- Views on decentralization issues in the Bitcoin and Ethereum ecosystems
Below is the text record of this interview, and everyone is welcome to read it carefully.
1. Faust: First, could you please introduce yourself, Cipher?
Cipher: I first came into contact with blockchain in 2013, entering the space through Bitcoin mining. At that time, mining wasn't so competitive, but the first time I bought a mining machine, I encountered a dishonest manufacturer. By 2014-2015, due to the significant price fluctuations of Bitcoin, I wrote an automated trading program and made some money. When the bear market hit at the end of 2015, I temporarily left the crypto space; at that time, I hadn't established a belief, I was just speculating.
In 2016, I officially entered the blockchain industry, joining a blockchain research institute within the system, participating in the development of central bank digital currency and consortium chains, where I served as the product leader. During this time, I also wrote some white papers and early privacy protection documents, as well as patents related to digital property rights.
In 2018, I realized that consortium chains were the wrong direction: All consortia will have a leader, and if there is a leader, there is no need to use blockchain. If it is a consortium chain under a state-owned entity, it is even less meaningful; it is just a dictatorship of the leader. Later, my work focus shifted to permissionless public chains. By chance, I participated in the early construction of CKB with several partners, where I was responsible for product and some research work.
By around 2021, I gradually became independent from the CKB Foundation and established my own company, working on peripheral projects within the CKB ecosystem, such as JoyID. Currently, JoyID has over 500,000 users and can be said to be the most complete Passkey wallet in the industry. Although Passkey itself has some limitations in device compatibility, our wallet is still very user-friendly, allowing direct use without phone numbers, emails, or mnemonic phrases, and it operates as a non-custodial wallet in terms of security model.
In the summer of 2023, during the inscriptions boom, the entire Bitcoin ecosystem began to warm up, even experiencing a renaissance. In mid-February this year, I proposed a concept called RGB++, with the vision of creating a native smart contract environment for BTCFi while maintaining Bitcoin's security. In response, we quickly formed a special team and launched the RGB++ protocol before the Bitcoin halving in April this year, with good results. At the same time, some projects within the CKB ecosystem, including DEX, Launchpad, and Stablecoin, have also been launched one after another. Overall, the RGB++ ecosystem is in a thriving phase.
After addressing the functional expansion issues for BTC, we shifted our focus to scaling and other aspects. In April, we specifically established a company to initiate the UTXO public chain or Bitcoin Layer 2 UTXO Stack. As for why we chose the UTXO model, the core reason is that Bitcoin itself is a UTXO model, and it differs greatly from Ethereum. If we were to build L2 on Bitcoin, how would we implement state transition proofs, cross-chain interactions, asset forced exits, and DA? If we simply copied Ethereum's account model and Rollup approach, it would be difficult to achieve good results. This has always been my viewpoint: copying Ethereum's approach to Bitcoin is unlikely to end well.
The UTXO Stack has currently completed its first round of financing, and the second round is underway. Although the recent enthusiasm in the Bitcoin ecosystem has declined, we are still very confident and willing to take the lead in building a nearly native functional expansion and programmable ecosystem for BTCFi. Currently, we are doing more work on the market and business levels, and some ecosystem-related activities will follow, so everyone can look forward to progress in this area.
2. Misty Month: What is the relationship between UTXO Stack and RGB++ Layer? It seems there is a subordinate relationship; could you elaborate on this?
Cipher: The relationship can be described from two angles. From a branding perspective, the RGB++ Layer is a product under the UTXO Stack brand; from a technical perspective, the RGB++ Layer adds a smart contract execution layer to BTCFi through isomorphic binding. Isomorphic binding is applicable not only to BTC and CKB but also to broader public chain ecosystems like Cardano, Fuel, and Sui, as long as they are related to UTXO.
As for UTXO Stack, it is somewhat similar to OP Stack, which can be used to quickly launch BTC L2. It directly comes with isomorphic binding functionality, allowing BTCFi assets on the mainnet to be transferred to L2 for trading via Leap. OP Stack's smart contracts run on Ethereum, while UTXO Stack's smart contracts run on the RGB++ Layer.
Returning to the final subordinate relationship and priority between the two, this involves a logical issue: the premise for all L2s to be established is that L1 is already sufficiently congested or that L1's functionality is limited and cannot meet user needs.
Currently, the smart contract layer formed by Bitcoin + RGB++ Layer has not yet seen a surge of assets and applications, so we hope to guide new developers and users to RGB++ Layer first to develop DeFi applications, trading platforms, and asset issuance, thereby developing the BTCFi ecosystem before delving deeper into L2 work. Only when BTCFi itself has sufficient enthusiasm can Bitcoin scaling become a real demand, at which point the launch of UTXO Stack will be a natural progression.
3. Faust: You mentioned Bitcoin Layer 2; recently, we have received information from various channels suggesting that BTC L2 has reached a phase bottom, and more people or institutions are focusing on BTCFi. However, many BTCFi projects are merely the wBTC model, bridging Bitcoin to other public chains or Bitcoin sidechains, which are not truly BTC native. In your view, what is the real difference between BTCFi and something like wBTC?
Cipher: My consistent viewpoint is that the ceiling for EVM-based BTC L2 is very low. The reason is simple: using EVM does not contribute to the growth of Bitcoin's ecosystem but rather brings BTC into other ecosystems. We know that it is difficult to implement smart contracts on the Bitcoin mainnet, and TPS cannot be high, so there is a simple solution: bridge Bitcoin to other places.
While this may seem to solve the problem, it actually avoids the most critical issue: in this way, Bitcoin's own ecosystem does not develop at all; Bitcoin miners' income and on-chain data will not change. What you are doing is merely the simplest asset bridging; after bridging, can you obtain new stories and scenarios? Clearly not. Because everything you do has already been done by wBTC and the Ethereum ecosystem long ago, with no innovation, just creating another type of BTC bridging asset. So what is your significance?
Similarly, with EVM, can you surpass the DeFi system that already exists on Ethereum? The Bitcoin Layer 2 based on EVM may create a false prosperity in the short term due to airdrop expectations, but long-term development is likely to be limited. What can truly impact and empower the Bitcoin ecosystem in the long run is a more native, UTXO-based L2.
The so-called native BTC Layer 2 is attractive not because of its orthodoxy, but because this "native" can bring more interesting scenarios to the Bitcoin ecosystem. For example, RGB++ has a technology called bridge-less cross-chain Leap, which allows BTCFi assets to jump back and forth between L1 and L2 or between L2s. This method does not rely on the traditional cross-chain bridge's Lock-Mint paradigm, avoiding many risks associated with traditional cross-chain bridges, and has significant advantages in cross-chain response speed and liquidity aggregation, bringing great convenience to the DeFi ecosystem. The Leap function has been online since April, and many users are enjoying the convenience brought by this technology. This is one of the innovations brought by the Bitcoin native solution.
Additionally, the native attributes of BTC will also affect the audience. For example, many BTC holders do not like to use MetaMask and prefer to use mainstream wallets already available in the BTC ecosystem. Although there are some so-called AA solutions that allow Bitcoin wallets to perform account abstraction in the EVM application layer, this approach has various issues that hinder BTC holders' entry. In contrast, our UTXO-based Layer 2 solution directly supports interaction using Bitcoin wallets, and its AA implementation is closer to the underlying layer, so users may not even notice it, making it very convenient, simpler, easier to use, and more seamless.
Furthermore, we know that the UTXO model is "off-chain computation, on-chain verification," which is particularly suitable for intent-driven transaction scenarios. The so-called intent means that I only tell the system what I am willing to pay and what I need to receive for this transaction, but I do not need to worry about how to call smart contracts or set function parameters; I only need to place my desired input and output results on-chain for verification. If you want to create intent scenarios on Ethereum, you may need a series of components like Operators and Aggregators, which can be cumbersome, but in the UTXO world, it is much simpler. This is also a characteristic of UTXO Layer 2 compared to EVM Layer 2. In summary, we are optimistic about the new DeFi scenarios that UTXO can give rise to for L2.
4. Faust: What are the main points of integration between RGB++ Layer and BTC, and which scenarios are the most important? What are the core ecological layouts and roadmaps for RGB++ and CKB moving forward?
Cipher: The integration of the two mainly lies in various application scenarios. Some scenarios have already been mentioned, and here are a few more examples. We know that flash loans have a significant presence in the Ethereum ecosystem; they can continuously call a series of contracts within a single transaction, obtaining transaction results and showing the lending platform: I can instantly return the assets and interest I borrowed. We can use on-chain flash loans to quickly conduct various financial activities, but there are no flash loans in the UTXO world; however, there are other mechanisms.
For example, UTXO has a mechanism for nested contract scripts, which can continuously generate a series of transactions, simplifying the user's interaction process. The output result of one transaction can directly serve as the input parameter for the next transaction. Through this method, we can quickly generate a batch of transaction instructions that are interconnected. For instance, if we want to conduct a cross-chain DeFi operation, we first bridge assets from chain A to chain B, then sell half on a DEX, and finally form an LP pair with the remaining tokens to place in a liquidity pool. These four steps can be achieved in one click within the RGB++ Layer's smart contract framework using the aforementioned nested contract script method. This means that the entire process can be completed with a single user operation, while the rest can be automatically handled by decentralized smart contracts.
Another clear integration point is IBO, which refers to financing through Bitcoin. Of course, this is not a new concept; Ethereum has adopted this financing method, where early on, one Bitcoin could be exchanged for ten or twenty thousand Ethereum. However, the problem with previous IBOs was that, although they were similar to ICOs in terms of financing, once the assets were raised, there were no gameplay options. For example, some ICOs have a clear price curve, where the purchase price rises or falls in a stepwise manner after the first 100-200 blocks, and some require early buyers to lock their assets for a month, while the last buyer might need to lock for three months. There are many different methods, such as offering an additional 50% of tokens for locking for an extra month or 100% for locking for a year.
Previously, such special rules could not be implemented in IBOs, but we can change that through the RGB++ Layer. One major issue with Bitcoin assets is the lack of programmability, which means they can only issue meme coins, but once they can be combined with smart contracts, it means assets can be empowered. Only after these connections are made will project teams be willing to build in the Bitcoin ecosystem.
For BTCFi or any finance, the prerequisite is to have assets and corresponding rich scenarios. If the asset is limited to Bitcoin itself, it often only allows for remote pledging, cross-chain, and other singular scenarios. If we truly want the ecosystem to thrive, we need to issue various assets to flourish. In the current Ethereum world, the market value of ERC-20 assets should be comparable to that of ETH itself, or even greater, while the non-BTC assets in the Bitcoin ecosystem may account for less than 1% of BTC's market value. Therefore, how to create new assets in the BTC ecosystem is key to development.
Thus, I believe the biggest integration point between RGB++ Layer and Bitcoin is to utilize the programmability of RGB++ Layer to create decentralized asset categories that truly empower Bitcoin, something that has never appeared in Bitcoin before; it has either been meme coins or centralized assets. In summary, we are very optimistic about the potential of using the smart contract layer to create new assets for the Bitcoin ecosystem.
5. Faust: In 2018-2019, CKB positioned itself as "L1 designed specifically for L2," making many supporting designs for scenarios like state settlement for L2, which can be said to be a decentralized verification layer specifically designed for Rollup. In your opinion, what is CKB's core advantage compared to ordinary public chains?
Cipher: It is actually difficult to define what constitutes Layer 1 and Layer 2 in the Bitcoin ecosystem. I believe that CKB and RGB++ Layer are not primarily focused on validating and settling for a specific Layer 2. CKB, as a UTXO chain, is inherently inclined towards verifying off-chain computation results rather than directly performing calculations on-chain. This was a point that Jan, as the chief architect, strongly insisted upon when CKB was initially established; he believed that blockchain's computational, storage, and bandwidth resources are extremely precious and should not be used for complex tasks, but rather for the simplest functions.
In fact, whether for L2 or L1, consensus must be reached on state changes, and there are only two ways to achieve consensus: one is to take the contract that executes the state change and have everyone compute it to reach the same result, which is the logic of the account model; the other is to complete the state change off-chain, sending me the proof of its validity, and I can verify this proof without needing to compute the original content myself, which is essentially the current Rollup approach.
When we proposed the second method in 2018, many people found it strange; computing once and verifying once seemed like the same thing, but Jan pointed out that they are actually different. For example, in sorting algorithms, the complexity of verifying results is far less than that of direct computation. At that time, many people thought that transferring ordinary ERC-20 assets was unnecessary, but as we all know, whether it is ZK or Rollup, they are both paradigms of off-chain computation and on-chain verification. At this point, you will find that the second method is more effective and valuable.
The UTXO model also has many advantages for parallel computation. We know that Ethereum has recently proposed the narrative of parallel EVM, but through some channels, I learned that the so-called parallel EVM often does not achieve a parallelism level of even 2 when put into actual use. In contrast, UTXO inherently supports parallel computation; the number of CPU cores determines the number of threads that can run in parallel, and this efficiency cannot be matched by EVM-based systems.
We have been following the UTXO path for five years, and in the various scenarios we just described, UTXO naturally has more advantages than the account model. Moreover, since we and Bitcoin both use UTXO, we can support isomorphic binding, further simplifying some functions. Therefore, I believe the main advantage lies in the architecture; by adopting the UTXO architecture to interface with Bitcoin, we are certainly more efficient.
6. Faust: Some believe that UTXO is not conducive to supporting DeFi, as different UTXOs cannot call each other's states, and some even think that RGB++ and CKB would encounter resistance if they directly developed the DeFi ecosystem on Layer 1. What is your view on these opinions? What solutions have you introduced to address these issues?
Cipher: First of all, there is some reasonableness to these views because the account model is more intuitive, similar to previous standalone programs, where you only need to consider some attack scenarios. However, the UTXO model is different; the contracts you write on-chain are verifiers, and you also need to build a dedicated off-chain calculator, which we usually refer to as an Aggregator or Generator. The Generator is responsible for computing the state off-chain and generating it, then sending it on-chain for verification, which is relatively complex.
If it is a UTXO-based DEX platform like UTXOSwap, it is difficult to know the result when initiating a transaction because there may be 100 people submitting operations simultaneously. However, the special properties of UTXO require that among those 100 people, only one can modify its state at any given time, leading to contention issues. If we do not handle conflicting transaction requests, ultimately, only one of the 100 transactions may succeed, while the remaining 99 fail. This issue poses a significant challenge for product design, which is why people say the UTXO model is not conducive to DeFi.
However, we also see that even in the past two years, new UTXO chains have emerged, such as Fuel. Why do people continue to use the UTXO model despite various troubles? Because it has many advantages, which I have mentioned before. So how do we overcome these issues? After five years of refinement, we have developed a very mature solution that can implement Uniswap-like functionality on UTXO chains. The UTXOSwap in the ecosystem was recently launched on the mainnet, and many people are already adding LPs and trading pairs. If you truly experience it, you will find that it is almost indistinguishable from Uniswap.
In fact, the design of UTXOSwap is quite simple; we divide each transaction into two steps: the first step is for the user to submit their intent on-chain, and the second step is for the Aggregator to aggregate everyone's intents, merge them, and initiate a transaction to interact with the liquidity pool. The liquidity pool can satisfy these intents all at once, generating a final UTXO based on the results.
There may be a block delay issue here because in the first step, the user must first submit their individual intent on-chain, which is then processed by the aggregator/sorter before the latter performs the next operation on-chain. However, in practice, users can directly send transaction intents to the Aggregator off-chain, allowing for batch processing, which can solve the response delay issue, making it similar to Rollup. We already have mature solutions for these UTXO issues, and CKB is also working on some solutions to implement the processes mentioned above.
Another aspect is that UTXO is very suitable for supporting order book models. In the past, there were order book DEXs on Ethereum, but they have since disappeared for various reasons, the core being that order book DEXs are not suitable for running on the account model because every order and cancellation, even if not executed, incurs a fee, which is unbearable for PMF. This is why the AMM model emerged. However, under the UTXO model, it is different; for example, you can place 100 orders simultaneously. In the UTXO world, associating a transaction with 100 UTXOs is easy and low-cost, and if you want, you can place even more.
Moreover, we also have PSBT partial signature technology, where order transactions do not even need to be submitted on-chain; you just need to send a simple signature, and the matcher can aggregate multiple signatures and put the transaction on-chain, making the order book model more compatible with the UTXO model. AMM can also adopt tiered pricing like Uniswap V3 to provide virtual liquidity, placing different liquidity shares at different prices rather than a smooth curve.
These are unique DeFi scenarios in the UTXO environment, representing a high level of innovation. Such levels of innovation are unlikely to occur on an EVM chain, where most projects are merely copycat clones with no innovative ideas. We genuinely want to attract native developers from the Bitcoin ecosystem or developers who love the UTXO model; these developers often possess strong capabilities and innovative drive, and we are very optimistic about the emergence of new BTCFi paradigms under this model.
7. Faust: CKB uses the RISC-V instruction set, which supports multiple programming languages. However, some believe that supporting too many programming languages is not a good thing, as it can make a public chain's developer ecosystem chaotic and fragmented. What do you think is the preferred language for development on CKB currently?
Cipher: Currently, the preferred languages are still Rust and C, both of which have relatively complete support. RISC-V has now become a mainstream CPU architecture, and it is foreseeable that within 5 to 10 years, it will surpass ARM, supporting many compilers. However, the CKB official support is still primarily for Rust and C, while also supporting some scripting languages. We have also developed some runtimes to support LUA and JavaScript, but the performance degradation can be significant, potentially between 30% to 300%. Therefore, for algorithm-intensive tasks, it is still recommended to use Rust or C, and there won't be too many programming languages to fragment the developer ecosystem.
I actually want to talk about the advantages of RISC-V itself. When we first created CKB in 2018, we were the only ones globally to choose RISC-V as the virtual machine for a public chain, and the reason is simple: RISC-V is an instruction set designed for hardware devices, characterized by simplicity and caution. Since it is an instruction set aimed at hardware, it is often quite stable and does not undergo the annual fluctuations in instructions like EVM, which is precisely the caution that open-source protocols require.
Secondly, for smart contract platforms or blockchains, we believe it is best for core functionalities to tend to be fixed, otherwise, frequent changes can easily lead to problems. Our entire approach is fundamentally different from Ethereum. EVM undergoes opcode iterations almost every year, and this has impacted program compatibility and stability, which we strive to avoid. Therefore, based on this reasoning, we adopted the RISC-V instruction set, which has proven to be very forward-looking.
Now that ZK has begun to flourish, you will find that many projects are using RISC-V as their virtual machine at the base layer, so as a public chain based on RISC-V, it becomes very easy to accommodate new ZK facilities, as there is no need for any translation at the instruction level, and the efficiency is obviously much higher than running RISC-V on EVM.
8. Faust: From CKB's perspective, how do you view the Bitcoin ecosystem? For example, do you think there are centralized organizations in the Bitcoin ecosystem similar to the Ethereum Foundation? Some have previously suggested that BlockStream is somewhat autocratic; does CKB have its own views on this?
Cipher: I believe that the structure of the Bitcoin ecosystem is completely different from that of the Ethereum ecosystem. The Ethereum Foundation has a very strong voice, while in the Bitcoin world, you could say that the core developers behind it form a relatively influential organization, but the Bitcoin ecosystem exhibits clear checks and balances among multiple forces. There is a strong competitive relationship between miners, developers, and large Bitcoin holders; it is not the case that whatever the developers promote will be unconditionally accepted by miners. If proposals are excessive, miners and mining pools will directly oppose them.
I think this point is different from Ethereum. For example, Ethereum's transition from PoW to PoS and EIP-1159 faced significant controversy, but the Ethereum Foundation or Vitalik himself largely had the final say, which is well known. On the other hand, the Ethereum ecosystem is now very large, with many centrally issued assets, such as RWAs, stablecoins, etc. Once a genuine fork occurs, the future direction will be determined by the issuers of these centralized assets.
Therefore, both subjectively and objectively, the centralized forces led by the Ethereum Foundation have much greater influence than the various organizations in the Bitcoin ecosystem.
Another point is that there is no particularly unified value system in the Bitcoin ecosystem. For example, core developers are closer to Bitcoin maximalism, resisting OP_CAT or inscriptions, wishing Bitcoin not to undergo too many changes; developers on the periphery may tend to support the passage of OP_CAT. Further out, teams like the Lightning Network and RGB are more inclined towards new things compared to the first two. Then there are teams like ours, which not only welcome new things but actively seek innovation and change. The outermost layer includes various multi-signature bridges and EVM-based Layer 2s.
Because of the diverse backgrounds of various individuals, the Bitcoin ecosystem is very inclusive, and there is no need to worry that a particular layer or a small group of people is wrong; as long as there is a group that is ultimately correct, that is sufficient. While the Ethereum model may appear to progress faster on the surface, the Bitcoin model is more stable, without the worry that a small group's erroneous decisions will lead the entire ecosystem into a crisis. Therefore, from this perspective, we are very optimistic about the Bitcoin ecosystem because it is like a large melting pot, possessing strong inclusivity and error-correcting capabilities.
Taking BTC Layer 2 as an example, I see that your website BTCEden aggregates various different approaches, including the Lightning Network, RGB's client verification model, sidechains, and even Layer 2s that span both Ethereum and Bitcoin, showcasing a diverse array of solutions. In contrast, looking at Ethereum, no one is working on sharding anymore, and state channels and Plasma are also no longer being pursued; there is almost only a single path of Rollup. Therefore, we certainly prefer the Bitcoin ecosystem; it is freer and more robust.
The CKB Foundation is also trying to make decision-making more decentralized. Of course, I am not currently in the foundation, so I do not have a say, but I can see that more roles are gradually shifting towards community development. The overall scale of CKB is still relatively small, and the demand for decentralized decision-making is not yet so strong; people's expectations for CKB may still be for faster progress. However, to my knowledge, the core decision-makers of CKB are very open and will not concentrate excessive power in their hands; they will definitely find suitable opportunities to achieve decentralization.
📖 Recommended Reading: