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 his views on RGB++, 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 some questions and opinions 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 systems
- Interpretation of CKB's design philosophy
- How to address some shortcomings of the UTXO model in DeFi ecosystem construction
- Why CKB chose RISC-V and related contract development language choices
- Views on decentralization issues in the Bitcoin and Ethereum ecosystems
Below is the text record of this interview, and everyone is welcome to read 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 as competitive, but I encountered unscrupulous manufacturers when I bought my first mining machine. 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 manager. During this time, I also wrote some white papers and early industry 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 more meaningless; it is just a dictatorial regime. Later, my work focus shifted to permissionless public chains. By chance, I participated in the early construction of CKB with a few 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.
By the summer of 2023, the entire Bitcoin ecosystem began to warm up, even experiencing a renaissance. In mid-February of this year, I proposed a concept called RGB++, with the vision of creating a native smart contract environment for BTCFi while not compromising Bitcoin's security. In response, we quickly established 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 vigorous upward phase.
After addressing the functional expansion issues for BTC, we then focused on 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 significantly from Ethereum. If we were to create L2 on Bitcoin, how would we implement state transition proofs, cross-chain, 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 view: copying Ethereum's thinking onto 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 carry the banner to build a nearly native functional expansion and programmable ecosystem for BTCFi. Currently, we are doing more work on the market and business side, and some ecosystem-related activities will follow, so everyone can look forward to progress in this area.
2. Wuyue: What is the relationship between UTXO Stack and RGB++ Layer? It seems there is a subordinate relationship between the two. Could you elaborate on this?
Cipher: The relationship can be described from two perspectives. 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 a wide range of 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. The smart contracts of OP Stack run on Ethereum, while those of UTXO Stack run on the RGB++ Layer.
Returning to the ultimate subordinate relationship and priority between the two, this involves a logical issue: the premise for all L2s 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 will the expansion of BTC become a real demand, and at that point, the launch of UTXO Stack will be a natural progression.
3. Faust: You mentioned BTC Layer 2; recently, we have received information from various channels suggesting that BTC L2 has reached a phase of stagnation, with more people or institutions focusing on BTCFi. However, many BTCFi projects merely replicate the wBTC model, bridging Bitcoin to other public chains or Bitcoin sidechains, which is not truly BTC Native. In your view, what is the real difference between BTCFi and something like wBTC?
Cipher: My consistent view is that the ceiling for EVM-based BTC L2 is very low. The reason is simple: using EVM does not contribute to the expansion 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 seems to solve the problem, it actually avoids the most critical aspect: in this way, Bitcoin's own ecosystem does not develop at all, and the income of Bitcoin miners, on-chain data, etc., will not change. What you are doing is merely the simplest asset bridging; after bridging, can you create new stories and new scenarios? Obviously 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 purpose?
With EVM, can you surpass the DeFi system that already exists on Ethereum? The short-term prospects for EVM-based Bitcoin Layer 2 may create a false prosperity due to airdrop expectations, but long-term development is easily limited. What can truly impact and empower the Bitcoin ecosystem in the long run will definitely be 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, allowing 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 at the EVM application layer, this approach has various issues that hinder BTC holders' entry. However, our UTXO-based Layer 2 solutions directly support interaction using Bitcoin wallets, and its AA implementation is closer to the underlying layer, so users may not even perceive it, making it very convenient, simpler, easier to use, and more seamless.
Moreover, 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 in between; I just need to put 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, obtain transaction results, and show the lending platform: I can instantly return the assets and interest I borrowed from you. We can use on-chain flash loans to quickly conduct various financial activities, but there are no flash loans in the UTXO world, although there are other mechanisms.
For instance, the UTXO model has a mechanism for nested contract scripts, allowing a series of transactions to be generated continuously, simplifying user interaction processes. 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 example, if we want to perform cross-chain DeFi, we first transfer assets from chain A to chain B, then sell half on a DEX, and finally form an LP pair with the remaining tokens to put into the liquidity pool. These four steps can be achieved in one click using the nested contract script method within the RGB++ Layer's smart contract framework. This means that for the entire process mentioned above, the user only needs to operate once, and 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, such as a stepwise increase or decrease in purchase price after the first 100-200 blocks, and some require early buyers to lock their assets for a month, while the last buyer may need to lock for three months. For instance, locking for an additional month might yield 50% more tokens, and locking for a year might yield 100%, with many different methods available.
Previously, these 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. However, once they can be combined with smart contracts, it means that 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 BTC itself, it often leads to single scenarios like remote staking or cross-chain. If we truly want to make the ecosystem prosperous, we need to issue various assets to flourish. In the current Ethereum world, the market value of ERC-20 assets should be roughly equivalent to that of ETH itself, or even exceed it, while the non-BTC assets in the Bitcoin ecosystem may not even account for 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 truly decentralized asset categories that empower Bitcoin. This has never happened with Bitcoin before; it has either been meme coins or centralized assets. In summary, we are very optimistic about the potential for creating new assets for the Bitcoin ecosystem using the smart contract layer.
5. Faust: In 2018-2019, CKB positioned itself as "L1 designed specifically for L2," making many supporting designs for state settlement and other scenarios, 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 verifying and settling for a specific Layer 2. CKB, as a UTXO chain, is inherently inclined towards verifying off-chain computation results rather than directly running computations on-chain. This was a point that Jan, as the chief architect, strongly insisted on when CKB was initially established; he believed that blockchain's computational resources, storage resources, and bandwidth resources are extremely precious and should not be used for any complex tasks but rather for the simplest things.
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, have everyone compute it once, and reach an agreement on the same result, which is the logic of the account model; the other is to complete the state change off-chain, send me the proof of its validity, and I can verify this proof without having 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 ordinary ERC-20 asset transfers did not need to be done this way, but as everyone knows, whether it is ZK or Rollup, they are both paradigms of off-chain computation and on-chain verification. At this point, you will realize 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 been proposing the narrative of parallel EVM, but through some channels, I learned that the so-called parallel EVM often does not achieve a parallelism of even 2 after being put into actual use. UTXO, on the other hand, inherently supports parallel computation; the number of CPU cores determines how many threads can run in parallel, and this efficiency cannot be matched by EVM-based solutions.
We have been pursuing 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 certain functionalities. 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 there are even views that RGB++ and CKB would encounter resistance if they directly developed DeFi ecosystems on Layer 1. What do you think of these views? What solutions have you introduced to address these issues?
Cipher: Firstly, there is some reasonableness to these views because the account model is more intuitive, similar to previous standalone programs, where considering some attack scenarios is sufficient. 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 unique properties of UTXO require that among those 100 people, only one can modify its state at any given time, leading to contention issues. If these conflicting transaction requests are not handled, 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 have also seen 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 functionalities similar to Uniswap 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 users to submit their intentions on-chain, and the second step is for the Aggregator to aggregate everyone's intentions, merge them, and initiate a transaction to interact with the liquidity pool. The liquidity pool can satisfy these intentions all at once, generating a final UTXO based on the results.
There may be a block delay issue here because in the first step, users need to submit their individual intentions on-chain, which are then processed by the aggregator/sorter before the latter performs the next operation on-chain. However, in practice, users can directly send their transaction intentions to the Aggregator off-chain, allowing the latter to process them in batches, thus solving the response delay issue, which is actually quite similar to Rollup. We already have very 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 later disappeared for various reasons, the core reason being that order book DEXs are not suitable for running on an account model, as every order and cancellation, even if not executed, incurs transaction fees, which is unbearable for PMF. This is why the AMM model emerged. However, in the UTXO model, it is different; for example, you can place 100 orders simultaneously. In the UTXO world, associating one transaction with 100 UTXOs is easy and low-cost; if you want, you can place even more. Therefore, order book DEXs will have more utility in the UTXO model.
Moreover, we also have PSBT partial signature technology, which means that order transactions do not even need to be submitted on-chain; you can simply send a concise signature, and the matcher can aggregate multiple signatures and put the transaction on-chain. This way, the order book model becomes 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 along 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 more copycat projects exist 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 have 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 lead to a fragmented developer ecosystem for a public chain. 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 already become a mainstream CPU architecture, and it is expected to surpass ARM in the next 5 to 10 years, supporting a wide range of 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 ranging from 30% to 300% slower. 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 developed 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 designed for hardware, it tends to be more stable and does not change instructions every year like EVM, which is the caution that open-source protocols require.
Secondly, for smart contract platforms or blockchains, we believe it is best for their core functions to tend to be fixed, otherwise, frequent changes can easily lead to problems. Our entire approach is fundamentally different from Ethereum. EVM has basically undergone opcode iterations every year, which has impacted the compatibility and stability of programs, and we strive to avoid that. Therefore, based on this thinking, we adopted the RISC-V instruction set, which has proven to be very forward-looking.
Now that ZK is becoming prevalent, you will find that many projects are using RISC-V as their virtual machine at the bottom layer. As a public chain based on RISC-V, it becomes very easy for us to accommodate new ZK facilities, as there is no need for any translation at the instruction level, and the efficiency is clearly 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 dictatorial; 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 are strong competitive relationships between miners, developers, and large Bitcoin holders; it is not the case that whatever 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 instance, the transition from PoW to PoS or EIP-1159 in Ethereum 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 and stablecoins. Once a true fork occurs, the entities issuing these centralized assets will truly determine the future direction.
Therefore, both subjectively and objectively, the centralized forces led by the Ethereum Foundation have much more powerful 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, hoping that Bitcoin does not undergo too many changes; developers on the periphery may be more inclined 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, who are not only more willing to accept new things but also actively seek innovation and change. The outermost layer includes various multi-signature bridges and EVM 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; there is no need to worry that their mistakes will lead the entire ecosystem astray. As long as one group is ultimately correct among so many, that is sufficient. While the Ethereum model may appear to progress faster on the surface, the Bitcoin model is more stable, without the risk of a small group's erroneous decisions plunging the entire ecosystem into chaos. Therefore, from this perspective, we are very optimistic about the Bitcoin ecosystem because it is like a large melting pot with strong inclusivity and error-correcting capabilities.
Taking BTC Layer 2 as an example, I see that on your website BTCEden, various solutions with different ideas are summarized, including the Lightning Network, RGB, and other client verification models, as well as sidechains and even Layer 2s that span both Ethereum and Bitcoin, showcasing a diversity of approaches. In contrast, looking at Ethereum, no one is working on sharding anymore, and state channels and Plasma have also fallen out of favor; 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 and do not have a say, but I can see that more roles are gradually leaning towards community development. The overall scale of CKB is still relatively small, and the demand for decentralized decision-making is not as strong yet; expectations for CKB may still be a bit faster. However, to my knowledge, the core decision-makers of CKB are very open and will not concentrate too much power in their hands; they will definitely find the right opportunity to complete the decentralization.
📖 Recommended Reading: