Cipher, the proposer of RGB++: My view on RGB++, UTXO and BTCFi

Source: Geek Web3

On July 22, 2024, Geek Web3 had the honor of inviting Cipher, the co-founder of CKB and the proposer of RGB++, to have a series of exchanges on his views on RGB++ and the UTXO system, CKB itself and the Bitcoin ecosystem. During the period, Cipher talked about his past experiences, the unique significance of the RGB++ Layer and the UTXO model to BTCFi, and some issues and opinions about CKB and the Bitcoin ecosystem. The specific issues involved in this interview include:

1. Cipher's personal experience

2. The connection between UTXO Stack and RGB++ Layer

3. Views on Bitcoin Layer 2 and BTCFi, especially EVM Layer

4. RGB++ Layer's unique scenarios and development concepts compared to EVM

5. Interpretation of CKB's own design concept

6. How to solve some shortcomings of the UTXO model in Defi ecosystem construction

7. Why CKB chose RISC-V and related contract development language selection

8. Views on the decentralization of Bitcoin and Ethereum ecosystem

The following is a text record of this interview, welcome to read carefully.

1.Faust: First, please introduce yourself, Cipher?

Cipher:I first came into contact with blockchain in 2013, because I participated in Bitcoin mining. At that time, mining was not so hot, but I encountered a black-hearted manufacturer when I bought a mining machine for the first time. In 2014-2015, because the price of Bitcoin fluctuated greatly, I wrote a program to automatically speculate on coins and made a little money. At the end of 2015, the bear market came, and I temporarily left the coin circle. At that time, I had not established faith, but was just speculating.

In 2016, I officially entered the blockchain industry and joined the blockchain research institute within the system. I participated in the development of the central bank's digital currency and alliance chain, and my position was product manager. During this period, I also wrote some white papers, as well as early privacy protection documents in the industry, and patents related to digital property rights.

In 2018, I completely realized that the alliance chain was the wrong direction:All alliances will have a leader, and there is no need to use blockchain if there is a leader. If it is a national alliance chain, it is even more meaningless, because it is just the leader's one-man show. Later, my work focus shifted to public chains that do not require permission. By chance, I and several partners participated in the early construction of CKB. I was responsible for products and part of the research work.

Around 2021, I gradually became independent from the CKB Foundation and established my own company to do peripheral projects within the CKB ecosystem, such as JoyID. JoyID currently has more than 500,000 users. It 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 easy to use. It can be directly free of mobile phone numbers, email addresses and mnemonics. It is a non-custodial wallet in terms of security model.

By the summer of inscriptions in 2023, the entire Bitcoin ecosystem began to pick up, even a Renaissance. In mid-February this year, I proposed a concept, RGB++, with the vision of creating a native smart contract environment for BTCFi without losing the security of Bitcoin. For this, we quickly set up a special team and launched the RGB++ protocol before the Bitcoin halving in April this year, and the effect was quite good. At the same time, some projects within the CKB ecosystem, including DEX, Launchpad, and Scaling, have also been launched one after another. Overall, the RGB++ ecosystem is in a booming stage.

After solving the problem of expanding the function of BTC, we focused our attention on capacity expansion and other aspects. In April, we set up a company specifically to start the UTXO public chain or the UTXO Stack of Bitcoin's second layer. As for why the UTXO model was chosen, the core is that Bitcoin itself is a UTXO model, and it is very different from Ethereum. If Layer2 is built on Bitcoin, how should state transition proof, cross-chain, forced asset exit, and DA be implemented? If you copy the account model and Rollup ideas of Ethereum, it is difficult to get a good result. This is also my view all along: Copying the ideas of Ethereum to Bitcoin is unlikely to have a good ending.

UTXO Stack has completed the first round of financing, and the second round of financing is also in progress. Although the popularity of the Bitcoin ecosystem has declined recently, we are still very confident and willing to take up the banner to build a nearly native function expansion and programmable ecosystem for BTCFi. At present, we have done more work on the market and business level, and some ecosystem-related activities will follow one after another. Everyone can look forward to progress in this regard.

2. Wu Yue: What is the relationship between UTXO Stack and RGB++Layer? The two seem to have a subordinate relationship? Can you introduce this aspect in detail?

Cipher: The relationship between the two can be introduced from two perspectives. From a brand perspective, RGB++Layer is a product under the big brand of UTXO Stack;From a technical perspective, RGB++Layer uses isomorphic binding to add a smart contract execution layer to BTCFi. Isomorphic binding is not only applicable to BTC and CKB, but also to a wide range of public chain ecosystems such as Cardano, Fuel and Sui, as long as it is related to UTXO.

As for UTXO Stack, it is somewhat similar to OP Stack and can be used to quickly start BTC Layer2. It comes with an isomorphic binding function directly, and can transfer the BTCFi assets of the main network to Layer2 through Leap for transactions. The smart contract of OP Stack runs on Ethereum, and the smart contract of UTXO Stack runs on RGB++ Layer.

Back to the ultimate subordination and priority between the two, this involves a logical problem: The premise for the establishment of all L2s is basically that L1 is already congested enough, or that L1 has limited functions and cannot meet user needs.

At present, there are not so many assets and applications emerging on such a smart contract layer composed of Bitcoin + RGB++layer, so we hope to guide new developers and users to RGB++Layer first, to do Defi applications, trading platforms and asset issuance, and to develop the BTCFi ecosystem first before going deeper into L2 work. Only when BTCFi itself is hot enough, can BTC expansion become a real demand, and then the launch of UTXO Stack will be a natural outcome.

3.Faust: Here you mentioned the BTC second layer. Recently, we have received news from some channels that BTC Layer2 has reached a stage bottom, and more people or institutions have focused on BTCFi. But many BTCFi are just WBTC models, bridging Bitcoin to other public chains or Bitcoin side chains, and are not BTC Native at all. In your opinion, what is the real difference between BTCFi and WBTC?

Cipher: My consistent view is that the ceiling of BTC Layer2 of the EVM system is very low. The reason is very simple. If you use EVM, you are not strengthening the ecology of Bitcoin, but introducing BTC into other ecologies. We know that it is difficult to implement smart contracts on the Bitcoin mainnet, and the TPS is not high. There is a very simple way: bridge Bitcoin to other places. This seems to solve the problem, but it actually avoids the core:

In this way, Bitcoin's own ecosystem has not been developed at all, and there will be no changes in Bitcoin miners' income, on-chain data, etc. You are just the simplest asset bridge. Can you get new stories and new scenes after the bridge? Obviously not. Because everything you do is what WBTC and the Ethereum ecosystem have done a long time ago, without any innovation, just creating an additional BTC bridge asset. So what is the meaning of your existence?

It is also EVM, can you surpass the DeFi system that already exists on Ethereum?The EVM-based Bitcoin Layer 2 may create a false prosperity in the short term due to the expectation of airdrops, but its long-term development is easily restricted.The one that can influence and empower the Bitcoin ecosystem in the long run must be the more native, UTXO-based Layer2.

And the so-called native BTC Layer 2 is not attractive because of its orthodoxy, but because this "native" can bring more interesting scenes to the Bitcoin ecosystem. For example, RGB++ has a technology called bridgeless cross-chain Leap. BTCFi assets can jump back and forth between L1 and L2 or L2. This method does not need to rely on the Lock-Mint paradigm of traditional cross-chain bridges, can avoid many risks of traditional cross-chain bridges, and has great advantages in cross-chain response speed and liquidity aggregation, which can bring 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. In addition, whether there is a BTC native attribute will also affect the audience. For example, many BTC holders don’t even like to use Metamask, and prefer to use the existing mainstream wallets in the BTC ecosystem. Although there are some so-called AA solutions that allow Bitcoin wallets to do account abstraction at the EVM application layer, this method has various problems that will hinder the entry of BTC holders. And our UTXO-based second-layer solution directly supports interaction with Bitcoin wallets. Its AA implementation is closer to the bottom layer, and users may not even perceive it. This is very convenient, simpler, easier to use, and more seamless.

In addition, we know that UTXO model is "off-chain calculation, on-chain verification", which is particularly suitable for intent-driven transaction scenarios. The so-called intent is that my transaction only tells the system what I am willing to pay and what I need to get, but how to call smart contracts in the middle, how to set function parameters, etc., I don’t have to worry about it at all. I just put the input and output results I want on the chain for verification. If you want to do Intent scenarios on Ethereum, you may need a series of components such as Operator and Aggregator, which are relatively bloated, but it is very simple in the UTXO world. This is also the feature of UTXO second layer compared to EVM second layer. In short, we are more optimistic about the new DeFi scenarios that UTXO can bring to Layer2.

4.Faust: What are the main points of integration between RGB++Layer and BTC, and which scenarios are the most important? What will be the core ecological layout and roadmap of RGB++ and CKB?

Cipher:The integration of the two is mainly in various application scenarios. Some scenarios have been mentioned just now, and here are some examples. We know that flash loans are very popular in the Ethereum ecosystem. It can continuously call a series of contracts in a transaction, get the transaction results and show the lending platform: the assets and interest I lent you can be returned to you in an instant. We can use on-chain flash loans to quickly carry out various financial activities, but there are no flash loans in the UTXO world, but there are other things.

For example, UTXO has a mechanism for nesting contract scripts, which can continuously generate a series of transactions and simplify the user's account transfer process.The output result of the previous transaction can be directly used as the input parameter of the next transaction. In this way, we can quickly generate a batch of transaction instructions that are connected to each other. Let me give you an example. For example, if you want to do a cross-chain DeFi, you first move the assets from chain A to chain B, then sell half of them in DEX, and then form an LP pair with the unsold tokens and put them in the liquidity pool. These four steps can be implemented in one click in the smart contract framework of RGB++Layer using the contract script nesting method mentioned above. This means that for the entire process mentioned above, users only need to operate once, and the rest can be automatically completed by decentralized smart contracts.

There is also a clear combination point, which is IB0, that is, financing through Bitcoin. Of course, this is not a new thing. Ethereum is taking this financing method. In the early days, one Bitcoin could be exchanged for 10,000 or 20,000 Ethereum. But the problem with IB0 in the past was that although it was the same as IC0 for financing, there was no gameplay after the assets were financed. Let me give you an example. Some IC0s have a clear price curve. For example, after the first 100-200 blocks, the purchase price rises or falls in a step-by-step manner. Some people who buy at the beginning need to lock it for one month, and the last person who buys it may need to lock it for three months. For example, if you lock up for an extra month, you will get 50% more coins, and if you lock up for a year, you will get 100% more coins. There are many different ways like this.

Previously, this kind of special rule could not be implemented on IB0, but we can change this through RGB++ Layer. A big problem with Bitcoin assets is that they are not programmable, which means that they can only issue Meme coins. Once they can be combined with smart contracts, it means that assets can be empowered. Only after these things are connected will project parties be willing to build the Bitcoin ecosystem.

For BTCFi or any Fi, the premise is to have assets and corresponding rich scenarios. If this asset is limited to BTC itself, it can often only be used for single scenarios such as remote staking and cross-chain. If you really want the ecosystem to prosper, you need to issue various assets to let a hundred flowers bloom. In the current Ethereum world, the market value of ERC-20 assets and ETH itself should be similar, and the latter may even be more than the former, while the non-BTC assets in the Bitcoin ecosystem may not even account for 1% of the BTC market value. So how to create new assets in the BTC ecosystem is the key to development.

So I think the biggest combination of RGB++ Layer and Bitcoin is to use the programmable capabilities of RGB++Layer to create a decentralized asset class that truly empowers Bitcoin.This has never happened to Bitcoin before, either Memecoin or centralized assets. In short, we are very optimistic about the possibility of using the smart contract layer to create new assets for the Bitcoin ecosystem.

5.Faust: In 2018-2019, CKB positioned itself as "Layer 1 designed for Layer 2", and made a lot of supporting designs for Layer 2 to do state settlement and other scenarios. It can be said that it is a decentralized verification layer designed specifically for Rollup. In this regard, what do you think is the core advantage of CKB compared to ordinary public chains?

Cipher:It is actually difficult to define what is called the first layer and what is called the second layer in the Bitcoin ecosystem. I think CKB and RGB++Layer are not based on verification and settlement for a certain second layer. As a UXTO chain, CKB is good at verifying the calculation results off-chain, rather than running the calculation directly on the chain. This is a point that Jan, as the chief architect, insisted on when CKB was first founded. He believes that the computing resources, storage resources, and bandwidth resources of the blockchain are extremely precious, and should not be used to do any complex work, but should do the simplest things.

In fact, whether it is Layer2 or Layer1, consensus must be reached on the state change, and there are only two ways to reach consensus. One is to take the contract that executes the state change, and everyone calculates it once to get the same result to reach a consensus. This is the logic of the account model; the second is you complete the state change off-chain, you send me the proof that proves its validity, and I just need to verify this Proof, without having to calculate the original content myself. This is actually the idea of ​​​​Rollup now.

When we proposed the second method in 2018, everyone still felt strange. Calculating once and verifying once seemed to be the same thing, but Jan said that they are actually different. For example, the complexity of the sorting algorithm is much less than the complexity of direct calculation. At that time, many people felt that it was unnecessary to do this for ordinary ERC-20 asset transfers, but everyone knows the story later. Whether it is ZK or Rollup, it is a paradigm of off-chain calculation and on-chain verification. Only then will you find that the second method is more effective and valuable.

The UTXO model also has many benefits for parallel computing. We know that Ethereum has recently mentioned the narrative of parallel EVM, but through some channels I learned that the so-called parallel EVM, after being put into actual use, often does not even reach a parallel degree of 2. UTXO naturally supports parallel computing. As many CPU cores as there are, as many threads can be parallelized. This efficiency is not comparable to things based on EVM.

We have been on the UTXO path since 5 years ago. In the scenarios we just described, UTXO naturally has more advantages than the account model. Moreover, we and Bitcoin are both UTXO, which can support isomorphic binding, so that some functions can be further simplified. So I think the main advantage is still in the architecture. We will definitely be more efficient if we use the UTXO architecture to connect to Bitcoin.

6.Faust: Some people think that UTXO is not conducive to supporting DeFi. For example, there is no way to call each other between different UTXO states. Some even think that RGB++ and CKB will encounter resistance if they develop the DeFi ecosystem directly on the first layer. What do you think of these views? And what solutions have you launched to solve these problems?

Cipher:First of all, these views are reasonable, because the account model is more intuitive, just like the previous stand-alone program, considering some attack scenarios is ok. The UTXO model is not, the contract you write on the chain is a validator, and you also need to build a special calculator off the chain, which we usually call Aggregator, or Gennerator. Gennerator is responsible for calculating the state off the chain and generating it, and then throwing it to the chain for verification, which is relatively complicated.

If it is a DEX platform based on UTXO like UTXOSwap, it is difficult to know the result when initiating a transaction, because there may be 100 people submitting operations at the same time, but the special properties of UTXO require that only one person out of 100 people can rewrite its status at the same time, and then there will be contention problems. If these conflicting transaction requests are not processed, only one transaction out of 100 may succeed, and the remaining 99 transactions will all fail. This problem is a great challenge for product design, which is why everyone says that the UTXO model is not conducive to DeFi.

But 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 all the troubles? Because it has many advantages, which I have mentioned before. So how do we overcome these problems? After 5 years of polishing, we have a very mature solution that can implement functions similar to Uniswap on the UTXO chain. UTXOSwap in the ecosystem was also launched on the mainnet not long ago, and many people have already added LPs and trading pairs. If you really experience it, you will find that it is almost no different from Uniswap.

In fact, the design of UTXOSwap is also very simple. We divide each transaction into two steps. The first step is for the user to submit his intention to the 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 at one time and generate a final UTXO for the results.

There may be a problem of block delay here, because in the first step, the user must first send his individual intention to the chain, which will be packaged and processed by the aggregator/sequencer, and then the next step will be performed on the chain by the latter. However, in actual operation, users can directly send their transaction intentions to the Aggregator off-chain, and the latter will process them in batches, which can solve the problem of response delay, which is actually similar to Rollup. We already have mature solutions to these UTXO issues, and CKB is also working on some solutions to implement the above-mentioned processes. Another aspect is that UTXO is very suitable for supporting the order book model. There used to be an order book model DEX on Ethereum, but it disappeared later. There are many reasons for this. The most important reason is that the order book DEX is not suitable for running on the account model, because every order and withdrawal must pay a handling fee even if it is not traded, which is unbearable for PMF, so the AMM model appeared later. But it will be different under the UTXO model. For example, you can place 100 orders at the same time. In the UTXO world, it is easy and low-cost to associate a transaction with 100 UTXOs, and you can place more if you want. So under the UTXO model, the order book DEX will be more useful.

What's more, we also have PSBT partial signature technology. Orders do not even need to be submitted to the chain. You just need to send a simple signature. The matchmaker aggregates the signatures of multiple parties and puts the transaction on the chain together. In this way, the order book model is more suitable for the UTXO model. Including AMM, it can use interval ladder prices like UniswapV3 to provide virtual liquidity, and put different liquidity shares at different prices instead of a smooth curve.

These are all unique DeFi scenarios in the UTXO environment, and they are all quite high-level innovations. And this level of innovation is unlikely to be done on an EVM chain.The EVM chain is more of a copycat project with no innovative ideas at all. We want to really attract native developers of the Bitcoin ecosystem, or developers who love the UTXO model. These developers often have strong capabilities and innovation drivers.We are also very optimistic that a new BTCFi paradigm can emerge under this model.

7.Faust: CKB uses the RISC-V instruction set, which supports multiple programming languages. However, some people believe that supporting too many programming languages ​​is not a good thing, as it will make the developer ecosystem of a public chain chaotic and fragmented. In this regard, what do you think is the preferred language for development on CKB?

Cipher:At present, Rust is still the first choice, followed by C, both of which have relatively complete support.RISC-V is currently a mainstream CPU architecture, and it can be foreseen that it will surpass ARM in 5 to 10 years, and it supports a lot of compilers. But at present, CKB officially supports more Rust and C, and also supports some scripting languages. We have also made some Runtime ourselves to support LUA and javascript, but the performance loss will be very large, and the limit may be a 30% to 300% speed reduction. So if it is an algorithm-intensive business, it is still recommended to write it in Rust or C, and there will not be too many programming languages ​​to split the developer ecosystem.

I actually want to talk about the advantages of RISC-V itself. When we first started CKB in 2018, we were the only one in the world to choose RISC-V as a public chain virtual machine. The reason is very simple. RISC-V is an instruction set suitable for hardware devices. Its design has two characteristics: simplicity and caution. Since it is an instruction set designed for hardware, it is often more stable and will not increase or decrease instructions every year like EVM. This caution is exactly what open source protocols need.

Secondly, for smart contract platforms or blockchains, we think it is best to be like Bitcoin, with its core functions tending to be fixed, otherwise it is too easy to add or decrease content every few days.It can be said that our entire idea is different from Ethereum. EVM basically has an iteration of the opcode every year, which has been the case in the past few years. This will affect the compatibility and stability of the program, which we try our best to avoid. So based on this idea, we adopted the RISC-V instruction set, which has proven to be very forward-looking.

Now that ZK is becoming popular, you will find that many project parties use RISC-V as a virtual machine at the bottom layer. As a public chain based on RISC-V, it is very easy for us to be compatible with the new ZK facility. 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 the perspective of CKB, what do you think of the Bitcoin ecosystem? For example, do you think there is a centralized organization similar to the Ethereum Foundation in the current Bitcoin ecosystem? Some people previously thought that BlockStream was a bit arbitrary. Does CKB have its own views on this?

Cipher: I think the structure of the Bitcoin ecosystem is completely different from that of the Ethereum ecosystem. The Ethereum Foundation has a very strong voice. Looking at the Bitcoin world, you can say that the core developers behind it are an organization with a relatively strong influence, but the Bitcoin ecosystem has obvious checks and balances among multiple forces. There is a strong game relationship between mining pools, developers, and Bitcoin big players. It does not mean that miners will unconditionally accept what developers promote. If the proposal is excessive, miners and mining pools will directly oppose it. I think this point is different from Ethereum. Things like Ethereum POW to POS and EIP-1159 were very controversial at the time, but the Ethereum Foundation or Vitalik himself was largely in control, which is obvious to all. On the other hand, the Ethereum ecosystem is now very large, with a lot of centralized assets, such as RWA, stablecoins, etc. Once a real fork occurs, the issuers of these centralized assets will really determine the future direction. So, whether subjectively or objectively, the centralized forces headed by EF in the Ethereum ecosystem have much stronger voice than various organizations in the Bitcoin ecosystem. Another point is that there is no particularly unified value in the Bitcoin ecosystem. For example, core developers are closer to Bitcoin maximalism, resisting things like OP_CAT or inscriptions, and hope that Bitcoin will not make too many changes; peripheral developers may tend to support the passage of OP_CAT and the like. One more layer outside, teams like Lightning Network and RGB are more inclined to new things than the first two. Then there are people like us who are not only more willing to accept new things, but also actively seek innovation and change. The last layer is to add all the multi-signature bridges and EVM second layers.

Because of all kinds of people from different backgrounds, the Bitcoin ecosystem is very inclusive. There is no need to worry that a certain layer or a small group of people is wrong, and their mistakes will lead the entire ecosystem astray. With so many groups of people, as long as one group is right in the end, it will be fine. Although Ethereum's model is faster on the surface, Bitcoin's model is more stable, and there is no need to worry that the wrong decision of a small group of people will lead the entire ecosystem into the abyss. So from this perspective, we are very optimistic about the Bitcoin ecosystem, because it is like a melting pot with strong inclusiveness and error correction capabilities.

Take BTC's second layer as an example. I saw that your website BTCEden has summarized various solutions with different ideas, including the Lightning Network, RGB, a client verification mode, and side chains, and even a second layer that spans Ethereum and Bitcoin. In short, a hundred flowers bloom and each has its own strengths. And if you look at Ethereum again, no one has done Sharding, state channels, and Plasma, and there is almost only a single route of the Rollup system. So of course we prefer the Bitcoin ecosystem, which is freer and more stable.

The CKB Foundation is also trying to make decision-making more decentralized. Of course, I am not in the foundation now and have no say, but I can see that more roles are gradually leaning towards community development. The overall size of CKB is still relatively small, and the demand for decentralized decision-making is not so strong. Everyone's expectations for CKB may still be faster. But as far as I know, CKB's core decision-makers are very open-minded and will not hold too much power in their own hands. They will definitely find the right time to complete decentralization.