At the end of July this year , Geek Web3 had the honor to invite Cipher, the co-founder of CKB and the proposer of RGB++, to conduct a series of exchanges on his views on RGB++ and the UTXO system, CKB itself and the Bitcoin ecosystem. During this period, Cipher talked about his past experience , the unique significance of RGB++ Layer and UTXO models to BTCFi, and some issues and opinions about CKB and Bitcoin ecology.
Specific questions covered in this interview include:
- Cipher personal experience
- The relationship between UTXO Stack and RGB++ Layer
- My views on the second layer of Bitcoin and BTCFi, especially the second layer of the EVM system
- RGB++ Layer’s unique scenarios and development concepts compared to the EVM series
- Interpretation of CKB’s own design philosophy
- How to solve some shortcomings of UTXO model in Defi ecological construction
- Why CKB chooses RISC-V and related contract development language options
- Views on decentralization issues in the Bitcoin and Ethereum ecosystems
The following is the transcript of this interview. You are welcome to read it carefully.
Cipher's personal experience
Faust: First of all, Cipher, please introduce yourself?
Cipher: I first came into contact with blockchain in 2013 when I participated in Bitcoin mining. Mining was not that complicated at that time. As a result, I encountered a shady manufacturer when I bought a mining machine for the first time. In 2014 or 2015, because the price of Bitcoin fluctuated greatly, I wrote an automatic currency speculation program and made a little money. The bear market came at the end of 2015, and I temporarily left the crypto. At that time, I had not yet established any faith and was just speculating.
By 2016, I officially entered the blockchain industry, joined the blockchain research institute within the system, and participated in the development of the central bank's digital currency and alliance chain, with the position of product leader. During this period, I also wrote some white papers, early privacy protection files 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 alliance leaders. If there is an alliance leader, there is no need to use the blockchain. If it is an alliance chain with the prefix "国", it will be even more meaningless. It is just the alliance leader. One word. Later, my focus turned to public chains that did not require permission. By chance, several partners and I participated in the early construction of CKB. I was responsible for the product 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. At present, JoyID has more than 500,000 users, and 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 and can be used directly without a mobile phone number, email address and Seed phrase is a non-custodial wallet in terms of security model.
By the Summer of Inscription in 2023, the entire Bitcoin ecosystem has begun to pick up, even 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. We quickly set up a dedicated group and launched the RGB++ protocol before the Bitcoin halving in April this year, and the results were pretty good. At the same time, some projects within the CKB ecosystem, including DEX, Launch pad, and Suanwen, have also been launched one after another. Overall, the RGB++ ecosystem is in a booming stage.
After solving the problem of functional expansion of BTC, we focused on aspects such as capacity expansion. In April, we set up a company specifically to launch the UTXO public chain or the second-layer UTXO Stack of Bitcoin. As for why we chose the UTXO model, the most important thing is that Bitcoin itself is a UTXO model, and it is very different from Ethereum. If we do Layer 2 on Bitcoin, how should we implement the state transition proof, cross-chain, asset forced withdrawal and DA and other parts? If you copy Ethereum's account model and Rollup ideas, it will be difficult to get good results. This has also been my point of view all along: copying the ideas of Ethereum to Bitcoin will hardly end well.
UTXO Stack has currently 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 carry the banner and build nearly native functions for BTCFi. Expand and programmable design ecosystem. At present, we have done more work on the market and business levels, and some ecological-related activities will follow. You can look forward to progress in this area.
The relationship between UTXO Stack and RGB++ Layer
Wuyue: What is the relationship between UTXO Stack and RGB++Layer? There seems to be a subordinate relationship between the two? Can you give a good introduction to this aspect?
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 architecture to add a smart contract execution layer to BTCFi. The isomorphic connection is not only applicable to BTC and CKB, but also to the vast public chain ecosystem 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 directly comes with the isomorphic binding function, which can transfer the BTCFi assets of the mainnet 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 final affiliation and priority of the two, this involves a logical problem: the premise for the establishment of all L2 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 the smart contract layer composed of Bitcoin + RGB++layer, so we hope to guide new developers and users to RGB++Layer first. Build Defi applications, trading platforms and asset issuance, develop the BTCFi ecosystem first, and then go deeper into L2 work. Only when BTCFi itself has enough popularity can BTC expansion become a real demand. At this time, the launch of UTXO Stack will be a matter of course.
Faust: Here you mentioned the second layer of BTC. The recent information we have received from some channels also believes that BTC Layer 2 has reached a periodic bottom, and more people or institutions are paying attention to 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 something like BTCFi and WBTC?
Cipher: My consistent view is that the ceiling of EVM-based BTC Layer 2 is very low. The reason is very simple. Using EVM is not to expand the ecosystem of Bitcoin, but to introduce BTC to other ecosystems. We know that it is difficult to implement smart contracts on the Bitcoin mainnet, and the TPS cannot be high. There is a very simple way: bridge Bitcoin to other places. This may seem to solve the problem, but it actually avoids the core thing:
In this way, Bitcoin's own ecology has not developed at all. There will be no changes in the income of Bitcoin miners, on-chain data, etc. All you do is the simplest asset bridge, and after the bridge you will Can you get new stories and new scenes? Obviously not. Because everything you do has been done by WBTC and the Ethereum ecosystem very early. There is no innovation, it is just the establishment of an additional BTC bridging asset. So what is the meaning of your existence?
The same is EVM, can you surpass the existing DeFi system on Ethereum? The second layer of EVM-based Bitcoin may create false prosperity in the short term due to airdrop expectations, but its long-term development can easily be limited. What can have a long-term impact on and empower the Bitcoin ecosystem must be the more native, UTXO-based Layer 2.
As for the so-called native BTC second layer, its attractive point is not its legitimacy, but that this "native" can bring more interesting scenarios to the Bitcoin ecosystem. For example, RGB++ has a technology called bridgeless cross-chain Leap. BTCFi assets can jump back and forth between L1 to L2 or L2. This method does not need to rely on the Lock-Mint regularization of traditional cross-chain bridges and can circumvent Traditional cross-chain bridges have many risks, but they also have 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 are native attributes of BTC 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, there are various problems in this approach that will hinder the entry of BTC holders. A UTXO-based two-layer solution like ours directly supports interaction with Bitcoin wallets. Its AA implementation is closer to the bottom layer, and users may not even notice it. This is very convenient, simpler, easier to use, and less hassle-free. seam.
In addition, we know that the UTXO model is "off-chain calculation, on-chain verification". This model 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, how to set the function arguments, etc. I put the input I want and The output results can be uploaded to 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 in the UTXO world it is very simple. This is also the characteristic of the second layer of UTXO compared to the second layer of EVM. In short, we are optimistic about the new DeFi scene that UTXO can create for Layer 2.
Faust: What are the main points of integration between RGB++Layer and BTC? Which scenarios are the most important? What will the next core ecological layout and roadmap of RGB++ and CKB include?
Cipher: The combination of the two mainly lies in various application scenarios. Some scenarios have just been mentioned, and here are some examples. We know that flash loan are very present in the Ethereum ecosystem. It can continuously call a series of contracts within a transaction, obtain the transaction results and display them to the lending platform: the assets and interest I lent to you can be returned to you instantly. you. We can use on-chain flash loan to quickly carry out various financial activities, but there are no flash loan in the UTXO world, but there are other things.
For example, UTXO has a contract instruction code nesting mechanism, which 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 argument of the next transaction. In this way We can quickly generate a batch of trading instructions that are connected from beginning to end. Let me give you an example. For example, if you want to create a cross-chain DeFi, first cross 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 tokens and put them in the liquidity In the sex pool. These four-step operations can be implemented with one click in the smart contract framework of RGB++Layer using the contract instruction code nesting method mentioned above. This means that the user only needs to operate the entire process once, and the rest can be automatically completed by the decentralized smart contract.
There is also a clear integration point, which is IB0, which is financing through Bitcoin. Of course, this is not a new thing. Ethereum uses 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 financing as IC0, there was no gameplay after the assets were raised. Let me give you an example, like some ICOs, which have a clear price curve. For example, after the first 100-200 blocks, the purchase price shows a stepwise rise or fall. In some cases, the first purchaser needs to lock up for a month. The last person to buy may need to lock in for three months. Another example is locking for one more month and giving 50% more coins, locking for one year and giving 100% more. There are many different methods like this.
Previously, this kind of 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 it can be combined with smart contracts, it means that assets can be empowered. Only after these things are cleared up will projects 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 engage in single scenarios such as remote staking and cross-chain. If you really want the ecosystem to prosper , various assets need to be issued 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 market value of BTC. 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 design capabilities of RGB++ Layer to create a decentralized asset class that truly empowers Bitcoin. This has never happened with 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.
CKB core advantages
Faust: In 2018-19, CKB positioned itself as "Layer 1 designed specifically for Layer 2." It made a lot of supporting designs in scenarios such as state settlement for Layer 2. It can be said to be decentralized specifically designed for Rollup. Authentication layer. In this regard, what do you think are the core advantages of CKB compared to ordinary public chains?
Cipher: It is actually difficult to define what is layer one and layer two 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 calculation results off the chain, rather than directly running calculations on the chain. This is a point that Jan, as the chief architect, insisted on when CKB was first founded. He believed that the difference between The computing resources, storage resources, and bandwidth resources of the blockchain are extremely precious. They should not be used to do any complex work, but should do the simplest things.
In fact, whether it is Layer 2 or Layer 1, 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 everyone can calculate it again and get the same result. Consistent, this is the logic of the account model; second, when you complete the status change off-chain, you send me the Proof that proves its validity, and I just verify the Proof, without having to calculate the original content myself. This is actually what Rollup is now. ideas.
When we proposed the second method in 2018, everyone thought it was strange. Calculating it and verifying it seemed to be the same thing, but Jan said they were actually different. For example, with sorting algorithms, the complexity of verification results is much less than the complexity of direct calculation. At that time, many people felt that there was no need to do this for ordinary ERC-20 asset transfers, but everyone knows the story later. Whether it is ZK or Rollup, it is the formalization of off-chain computing 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 often does not even reach 2 degrees of parallelism after it is put into actual use. UTXO inherently supports parallel computing. There are as many execution threads as there are CPU cores. This efficiency cannot be compared with things based on EVM.
We have been taking the UTXO path since 5 years ago. In some of 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 ties, further simplifying some functions. So I think the main advantage is the architecture. If we use UTXO architecture to connect to Bitcoin, we will definitely be more efficient.
Faust: Some people think that UTXO is not conducive to supporting DeFi. For example, there is no way for different UTXO states to call each other. They even think that RGB++ and CKB will encounter resistance if they directly develop the DeFi ecosystem on the first layer. What do you think of these views? And what solutions have you introduced to solve these problems?
Cipher: First of all, these views are reasonable to a certain extent, because the account model is more intuitive. Like the previous stand-alone program, it is OK to consider some attack scenarios. The UTXO model is not the case. The contract you write on the chain is a validator, and a special calculator must be built off the chain. We usually call it an Aggregator or Gennerator. Gennerator is responsible for calculating the state off-chain, generating it, and then throwing it onto the chain for verification, which is relatively complicated.
If it is a UTXO-based DEX platform like UTXOSwap, it is difficult for you to know the result when you initiate a transaction, because there may be 100 people submitting the operation at the same time. However, the special attributes of UTXO will require that among 100 people, only 100 people can submit the operation at the same time. 1 person rewrites its status, and a contention problem occurs. If these conflicting transaction requests are not processed, only 1 out of 100 transactions may succeed, and the remaining 99 transactions may all fail. This problem is a huge challenge to product design, which is why everyone says that the UTXO model is not conducive to DeFi.
But we have also seen that even in the past two years, new UTXO chains have emerged, such as Fuel. Why do people keep using the UTXO model despite all the troubles? Because it has many advantages, which I have mentioned before. So looking back, how can we overcome these problems? After 5 years of polishing, we already 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 LP and trading pairs. If you really experience it, you will find that it is almost the same as 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. The second step is for the Aggregator to aggregate everyone's intention and initiate a transaction after the merger. Exchanges and liquidity pools interact. The liquidity pool can satisfy these intentions all at once and generate a final UTXO for the result.
There may be a block delay problem here, because in the first step, the user must first send his individual intention to the chain, and then the aggregator/sequencer will package and process it, and then proceed to the next step 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. This can solve the problem of response delay. In fact, it is similar to Rollup. We already have very mature solutions to these UTXO problems, and CKB is also working on some solutions to implement the processes mentioned above.
In another aspect, UTXO is very suitable for supporting the order book model. In the past, there was an order book model DEX on Ethereum, but it disappeared later. There are many reasons for this. The core reason is that the order book DEX is not suitable for execution on the account model, because every pending order and cancellation order will be executed even if there is no transaction. There is a handling fee, which is unaffordable for PMF, so the AMM model later emerged. But it will be different under the UTXO model. For example, 100 orders can be placed at the same time. In the UTXO world, it is easy and low-cost to associate a transaction with 100 UTXOs. You can place more if you want. Therefore, under the UTXO model, the order book DEX will be more useful.
What's more, we also have PSBT partial signature technology. The pending order transaction does not even need to be submitted to the chain. You can just send a concise signature. The matchmaker will aggregate the signatures of multiple parties and put the transaction on the chain together. In this way, the order book model is more suitable. Equipped with UTXO model. Including AMM, it can use range ladder prices like UniswapV3 to provide virtual liquidity, placing different liquidity shares at different prices instead of a smooth curve.
These are unique DeFi scenarios in the UTXO environment, and they are all quite high-level innovations. 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 drive. We are also very optimistic that new BTCFi can be formalized under this model. come out.
Preferred language for developing CKB
Faust: CKB uses the RISC-V instruction set and can support multiple programming languages. However, some people believe that supporting too many programming languages is not a good thing and will make the developer ecosystem of a public chain confusing 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 of them have relatively complete support. RISC-V is now a mainstream CPU architecture. It is expected to surpass ARM in 5 to 10 years, and it supports many compilers. But currently CKB officially supports more Rust and C, and also supports some script languages. We have also made some runtimes to support LUA and javascript, but the performance loss will be huge, and at the extreme it may be a 30% to 300% slowdown. Therefore, 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 fragment 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 ones in the world who chose to use RISC-V as a public chain virtual machine. The reason is very simple. RISC-V is suitable for hardware devices. Instruction set, its design has two characteristics: simplicity and caution. Since the instruction set is made for hardware, it is often relatively stable and does not increase or decrease instructions every year like EVM. This kind of caution is exactly what open source protocols require.
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 will be too easy to cause problems by adding or subtracting content every three days. It can be said that our entire idea is the same as Ethereum is different. EVM basically iterates opcodes every year, and this has been the case in the past few years. This will have an impact on the compatibility and stability of the program, and we try our best to avoid this. So based on this idea, we adopted the RISC-V instruction set, which proved to be very forward-looking.
Now that ZK is becoming popular, you will find that many projects use RISC-V as virtual machines at the bottom level. As a public chain based on RISC-V, it is very easy to be compatible with the new ZK facilities. There is no need for it from the instruction level. Any translation is obviously much more efficient than running RISC-V on the EVM.
Opinions on decentralization issues in the Bitcoin and Ethereum ecosystems
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 thought that BlockStream was a bit arbitrary. Does CKB have its own opinion 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 relatively strong influence. However, there are obvious checks and balances in the bit ecosystem. There is a strong competitive relationship between mining pools, developers, and major Bitcoin players. It does not mean that miners will unconditionally accept whatever developers promote. If the proposal is excessive, both miners and mining pools will directly oppose it.
I think this point is different from Ethereum. Things like Ethereum POW to POS, EIP-1159, etc. were very controversial at the time, but the Ethereum Foundation or Vitalik himself largely covered the sky with one hand, which is obvious to all. of. On the other hand, the Ethereum ecosystem is now very large, with many centrally issued assets, such as RWA, stablecoins, etc. Once a real fork occurs, it is these centralized assets that will truly determine the future direction. Issuer.
Therefore, whether subjectively or objectively, the centralized forces led by EF in the Ethereum ecosystem have a much stronger voice than the various organizations in the Bitcoin ecosystem. Another point is that there are no particularly unified values in the Bitcoin ecosystem. For example, core developers are closer to Bitcoin maximalism and resist things like OP_CAT or inscriptions. They hope that Bitcoin will not make too many changes; peripheral developers It may be inclined to support the passing of OP_CAT or the like. On the outer layer, teams such as 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 take the initiative to seek innovation and change. The last layer is the second layer of multi-signature bridge and EVM system.
Because there are all kinds of people from different origins, the Bitcoin ecosystem is very tolerant. There is no need to worry that a certain layer or a certain person is wrong. Their mistakes will bias the entire ecosystem. There are so many groups of people, as long as one group is right in the end. Although Ethereum's model is faster on the surface, Bitcoin's model is more stable. There is no need to worry about a small person's wrong decision that will bring 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 and has strong inclusiveness and error correction capabilities.
Let’s take the second layer of BTC as an example. I saw that your website BTCEden summarized a variety of solutions with different ideas, including the Lightning Network, client verification mode such as RGB, as well as side chains and even across Ethereum. And the second layer of Bitcoin, in short, a hundred flowers are blooming, each showing its capabilities. And if you look at Ethereum, no one has done Sharding, and no one has done state channels and Plasma. 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 characters are gradually developing towards social development. The overall size of CKB is still relatively small, and the demand for decentralized decision-making is not that strong. Everyone's expectations for CKB may be faster. But as far as I know, the core decision-makers of CKB are very open-minded and will not take too much power into their own hands. They will definitely find the right time to complete decentralization.
