Interviewee: Cipher
Interview: Geek Web3
On July 22, 2024, Geek Web3 had the honor of inviting Cipher, co-founder of CKB and proposer of RGB++, to have a series of exchanges on his views on RGB++ and UTXO system, CKB itself and Bitcoin ecology. During the interview, Cipher talked about his past experience, the unique significance of RGB++ Layer and UTXO model to BTCFi, and some questions and opinions about CKB and Bitcoin ecology. The specific issues involved in this interview include:
Cipher Personal Experience
The relationship between UTXO Stack and RGB++ Layer
My opinion on Bitcoin Layer 2 and BTCFi, especially EVM Layer 2
RGB++ Layer has unique scenarios and development concepts compared to EVM
Interpretation of CKB’s design concept
How to solve some shortcomings of the UTXO model in DeFi ecosystem construction
Why CKB chose RISC-V and related contract development language selection
Views on the decentralization of Bitcoin and Ethereum ecosystems
The following is a transcript of the interview. Please read it carefully.
Faust: First, could Cipher please introduce yourself?
Cipher: I first came into contact with blockchain in 2013, because I participated in Bitcoin mining. At that time, mining was not so popular. As a result, 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 Bitcoin and made a little money. At the end of 2015, the bear market came, and I temporarily left the cryptocurrency 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 as the product manager. During this period, I also wrote some white papers, early privacy protection documents in the industry, and patents related to digital property rights.
In 2018, I realized that the alliance chain was the wrong direction: all alliances have a leader, and if there is a leader, there is no need to use blockchain. 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 access permissions. By chance, I and several partners participated in the early construction of CKB. I was responsible for products and part of the research work at that time.
Around 2021, I gradually separated from the CKB Foundation and founded my own company to work on peripheral projects within the CKB ecosystem, such as JoyID. JoyID currently has more than 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 easy to use. It can be used directly without a mobile phone number, email address, or mnemonic phrase, and is a non-custodial wallet in terms of security model.
In the summer of 2023, the entire Bitcoin ecosystem began to pick up, even to the point of a Renaissance. In mid-February of 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. We quickly set up a special team to launch 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 on capacity expansion and other aspects. In April, we set up a company 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 you do Layer2 on Bitcoin, how to implement state transition proof, cross-chain, asset forced exit and DA? If you copy the account model and Rollup ideas of Ethereum, it is difficult to get good results. 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 underway. 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.
Wuyue: What is the relationship between UTXO Stack and RGB++Layer? They seem to be subordinate to each other. Can you explain this 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 UTXO Stack brand; 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 they are 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, which can transfer the BTCFi assets of the main network to Layer2 for transactions through Leap. The smart contract of OP Stack runs on Ethereum, and the smart contract of UTXO Stack runs on RGB++ Layer.
Going 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 functions are limited and cannot meet user needs.
At present, there are not so many assets and applications on the smart contract layer composed of Bitcoin + RGB++layer, so we hope to guide new developers and users to RGB++Layer first to develop DeFi applications, trading platforms and asset issuance, develop the BTCFi ecosystem first and then go deeper into L2 work. Only when BTCFi itself is popular enough, BTC expansion can become a real demand, and then the launch of UTXO Stack will be a natural result.
Faust: You mentioned the BTC Layer 2. Recently, we have heard from some sources that BTC Layer 2 has reached a stage bottom, and more people or institutions have focused on BTCFi. However, 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 Bitcoin ecosystem, but introducing BTC into other ecosystems. 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 most core thing:
In this way, Bitcoin's own ecosystem has not been developed at all. Bitcoin miners' income and on-chain data will not change. You are just bridging the simplest assets. Can you get new stories and new scenes after bridging? Obviously not. Because everything you do is what WBTC and Ethereum ecosystem have done a long time ago. There is no innovation, just creating a new BTC bridge asset. So what is the meaning of your existence?
It’s the same EVM, can you surpass the existing DeFi system 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 more native, UTXO-based Layer 2 must be able to influence and empower the Bitcoin ecosystem in the long term.
The so-called native BTC second layer is not attractive because of its legitimacy, but because this "native" nature can bring more interesting scenarios to the Bitcoin ecosystem. For example, RGB++ has a technology called bridgeless cross-chain Leap, where BTCFi assets can jump back and forth from L1 to L2 or L2. This method does not need to rely on the Lock-Mint paradigm of traditional cross-chain bridges, and can avoid many risks of traditional cross-chain bridges. It also 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.
Another point is whether there are BTC native attributes 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 abstract accounts at the EVM application layer, this approach has various problems and 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 be able to perceive it. This is very convenient, simpler, easier to use, and more seamless.
In addition, we know that the 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 I don’t have to worry about how to call the smart contract in the middle, how to set the function parameters, etc. I just put the input and output results I want on the chain for verification. If you want to do an Intent scenario on Ethereum, you may need a series of components such as Operator and Aggregator, which are bloated, but it is very simple in the UTXO world. This is also the feature of UTXO Layer 2 compared to EVM Layer 2. In short, we are optimistic about the new DeFi scenarios that UTXO can bring about for Layer2.
Faust: What are the main points of integration between RGB++Layer and BTC? Which scenarios are the most important? What will be the core ecological layout and roadmap of RGB++ and CKB?
Cipher: The combination of the two is mainly in various application scenarios. Some scenarios have been mentioned just now, and here are some more 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 instantly. We can use on-chain flash loans to quickly carry out various financial activities, but there is no flash loan in the UTXO world, but there are other things.
For example, UTXO has a contract script nesting mechanism that can continuously generate a series of transactions, simplifying 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 now, 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 part of the token and put it 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 set of processes mentioned above, users only need to operate once, and the rest can be automatically completed by decentralized smart contracts.
There is another clear point of integration, which is IB0, that is, financing through Bitcoin. Of course, this is not a new thing. Ethereum is a 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 also financing like IC0, 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. In addition, the first buyer needs to lock it for one month, and the last buyer may need to lock it for three months. For example, if you lock it for one more month, you will get 50% more coins, and if you lock it for one year, you will get 100% more coins. There are many different methods like this.
Previously, such special rules could not be implemented on IB0, but we can change this through RGB++ Layer. A major problem with Bitcoin assets is that they are not programmable, which is equivalent to only issuing 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 come to the Bitcoin ecosystem construction.
For BTCFi or any Fi, the premise is to have assets and corresponding rich scenarios. If the asset is limited to BTC itself, it can only be used in 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 of the Bitcoin ecosystem may not even account for 1% of the BTC market value. Therefore, 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.
Faust: In 2018-2019, CKB positioned itself as "Layer 1 designed for Layer 2". It made many supporting designs for Layer 2 in scenarios such as state settlement. 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 the first layer and what is 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 under the chain, rather than running calculations 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 they should not be used to do any complex work, but should do the simplest things.
In fact, both Layer2 and Layer1 need to reach a consensus on the state change, and there are only two ways to reach a 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 that you complete the state change off-chain, and you send me the proof that proves its validity. I just need to verify this proof, and there is no need to calculate the original content yourself. This is actually the current idea of Rollup.
When we proposed the second method in 2018, everyone thought it was strange. Calculation and verification seemed to be the same thing, but Jan said they were actually different. For example, the complexity of the sorting algorithm is much less than the complexity of direct calculation. At that time, many people thought 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, they are all paradigms 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 been talking about parallel EVM, but through some channels I learned that the so-called parallel EVM, when put into actual use, often does not even reach a parallelism of 2. UTXO inherently supports parallel computing, and as many threads as there are CPU cores can be parallelized. This efficiency is not comparable to things based on EVM.
We have been following the UTXO path for 5 years. In the scenarios we just described, UTXO naturally has more advantages than the account model. Moreover, both we and Bitcoin are UTXO, which can support isomorphic binding, making some functions 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.
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 to a certain extent, because the account model is more intuitive, just like the previous stand-alone program, it is OK to consider some attack scenarios. The UTXO model is not like that. The contract you write on the chain is the validator, and you also need to build a special calculator off the chain, which we usually call the Aggregator or Generator. The Gennerator is responsible for calculating the state off the chain and generating it, and then throwing it on the chain for verification, which is relatively complicated.
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 at the same time, but the special properties of UTXO require that only 1 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 1 out of 100 transactions may succeed, and the remaining 99 transactions will all fail. This problem is a great challenge to 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 Uniswap-like functions on the UTXO chain. UTXOSwap in the ecosystem was also launched on the mainnet not long ago, and many people are already adding 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 that the user submits his intention to the chain, and the second step is for the Aggregator to aggregate everyone's intentions, and then initiate a transaction to interact with the liquidity pool. The liquidity pool can satisfy these intentions at one time and generate a final UTXO based on the results.
There may be a problem of block delay here, because in the first step, the user must first send his or her individual intention to the chain, which will be packaged and processed by the aggregator/sorter before the next step is performed on the latter chain. However, in actual operation, users can directly send 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 problems, 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. In the past, there were order book model DEXs on Ethereum, but they disappeared later. There are many reasons for this. The core reason is that 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 executed. This 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. If you want, you can place more. So under the UTXO model, 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 only 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. This also includes AMM, which can use interval ladder prices like UniswapV3 to provide virtual liquidity, placing 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. However, this level of innovation is unlikely to be done on an EVM chain, which is mostly copycat projects with no innovative ideas at all. We want to truly attract native developers of the Bitcoin ecosystem, or developers who love the UTXO model. These developers often have strong capabilities and innovation drivers, and we are very optimistic that a new BTCFi paradigm can emerge under this model.
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: Currently, Rust is the first choice, followed by C. Both have relatively complete support. RISC-V is already a mainstream CPU architecture, and it is foreseeable that it will surpass ARM within 5 to 10 years. It also supports a lot of compilers. But currently CKB officially supports more Rust and C, and also supports some scripting languages. We have also made some runtimes to support LUA and javascript, but the performance loss will be great, and the limit may be 30% to 300% of the 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 the open source protocol needs.
Secondly, for smart contract platforms or blockchains, we think it is best to keep the core functions fixed like Bitcoin, otherwise it is easy to cause problems if the content is added or removed every few days. It can be said that our whole idea is different from Ethereum. EVM has almost every year iterates the opcodes, which has been the case for 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 projects 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 facilities. No translation is required at the instruction level, and the efficiency is obviously much higher than running RISC-V on EVM.
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 Bitcoin ecosystem? Some people previously thought that BlockStream was a bit arbitrary. Does CKB have its own opinion on this?
Cipher: I think the structure of Bitcoin ecosystem is completely different from that of Ethereum ecosystem. The Ethereum Foundation has a very strong voice. In contrast, in the Bitcoin world, you can say that the core developers behind it are an organization with a relatively strong influence, but there is an obvious balance of power among multiple parties in the Bitcoin ecosystem. There is a strong game relationship between mining pools, developers, and Bitcoin majors. It does not mean that miners will unconditionally accept whatever developers promote. If the proposal is excessive, miners and mining pools will directly oppose it.
I think this is different from Ethereum. For example, 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 many centralized assets, such as RWA, stablecoins, etc. Once a real fork occurs, the issuers of these centralized assets will determine the future direction.
Therefore, whether subjectively or objectively, the centralized forces headed by EF in the Ethereum ecosystem have much stronger voice than the 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. On the outer layer, 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 layer 2.
Because of the diversity 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 are 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. 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 the BTC second layer as an example. I saw that your website BTCEden has summarized various solutions with different ideas, including the Lightning Network, RGB client verification mode, side chains, and even the second layer across Ethereum and Bitcoin. In short, a hundred flowers bloom and each has its own strengths. If you look at Ethereum again, no one has done Sharding, state channels, and Plasma. There is almost only a single route of Rollup. 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 that strong. People's expectations for CKB may still be a little faster. But as far as I know, the core decision-makers of CKB are very open and will not hold too much power in their own hands. They will definitely find the right time to complete decentralization.
