Conversation with Cipher, the proposer of RGB++: RGB++, UTXO and BTCFi in my eyes

On July 22, 2024, Geek Web3 was fortunate to invite Cipher, the co-creator of CKB and the proposer of RGB++, to conduct a series of exchanges on RGB++ and the UTXO system, CKB itself and the Bitcoin ecosystem in his eyes. During this period, Cipher He talked about his past experience, the unique significance of RGB++ Layer and UTXO model to BTCFi, and some issues and opinions about CKB and Bitcoin ecology. The specific questions covered in this interview include:

1. Cipher’s personal experience

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

3. Views on the second layer of Bitcoin and BTCFi, especially the second layer of the EVM system

4 . The unique scenarios and development concepts of RGB++ Layer compared to the EVM system

5. Interpretation of CKB’s own design philosophy

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

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

8. Views on the decentralization issues of the Bitcoin and Ethereum ecology

The following is the text version of this interview. You are welcome to read it carefully.

Faust: First of all, would you like Cipher to introduce yourself?

Cipher: I first came into contact with the blockchain in 2013 when I participated in Bitcoin mining. At that time, mining was not so involved. 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 currency circle. At that time, I had not yet established any faith and was just speculating.

In 2016, I officially entered the blockchain industry, entered 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 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 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. Just a word from the leader. 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.

About 2021, I will gradually become independent from the CKB Foundation and set up my own company to do 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 and can directly eliminate the need for mobile phone numbers, email addresses and mnemonics. The word, in terms of security model, is a non-custodial wallet.

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 function expansion of BTC, we have focused on expansion and other aspects. 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 core 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’s 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 a near-native solution for BTCFi Function expansion and programmable ecology. 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.

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 binding to add a smart contract execution layer to BTCFi. Isomorphic binding 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 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.

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 L1 has limited functions and cannot meet user needs.

Currently, 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 , 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 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: You mentioned the second layer of BTC here. The recent news 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 BTC Layer 2 of the EVM system 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 TPS cannot be high. There is a very simple way: bridge Bitcoin to other places. This seems to solve the problem, but it actually avoids the core thing:

In this way, Bitcoin’s own ecology has not been developed at all, and there will be no income for Bitcoin miners, data on the chain, etc. For any changes, all you do is bridge out the simplest assets. After the bridge is out, 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 creation of an additional BTC bridge asset. So what is the meaning of your existence?

The same is EVM, can you still 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.

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 paradigm 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, preferring to use 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 more seamless. .

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 parameters, etc. I put the input and output results I want. Just put it on the chain and verify it. 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 loans 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 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 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 It 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 build 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 are implemented in the smart contract framework of RGB++Layer with one click using the contract script nesting method mentioned above. This means that the user only needs to operate the entire set of processes mentioned above once, and the rest can be completed automatically 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, and 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 have no programmability, 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 To get up, 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 be 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 programmability of RGB++ Layer to create a decentralized asset class that truly empowers Bitcoin. This has never happened with Bitcoin before. However, it is either Memecoin or centralized assets. In summary, we are very optimistic about the possibility of using the smart contract layer to create new assets for the Bitcoin ecosystem.

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 status settlement for Layer 2. It can be said that it was specially designed for Rollup. Centralized verification 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 off-chain calculation results, rather than running calculations directly on the chain. This was 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 the status change, and there are only two ways to achieve consensus. One is to take the contract that executes the status change, and everyone can calculate it again and get the same result. In order to reach a consensus, this is the logic of the account model; the second is that you complete the status change off-chain, and you send me the Proof that proves its validity, and I just verify the Proof. There is no need to calculate the original content myself. This is actually Now the idea of ​​​​Rollup.

When we proposed the second method in 2018, everyone thought it was strange. Calculating it once and verifying it again seemed to be the same thing, but Jan said they were actually different. For example, in sorting algorithms, the complexity of verifying the 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 a paradigm of off-chain computing and on-chain verification. Only then will you find that the second method is more effective and valuable.

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. As many CPU cores as there are, there can be as many threads in parallel. This efficiency cannot be compared with EVM-based things.

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 binding, further simplifying some functions. So I think the main advantage is the architecture. It will definitely be more efficient for us to use 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's status between different UTXOs. 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. The Generator 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, but the special attributes of UTXO will require that among 100 people, only 100 people can submit the operation at the same time. If one person can rewrite its status, contention problems will arise. 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 continue to use the UTXO model despite all kinds of troubles? Because it has many advantages, which I have mentioned before. So looking back, how can we overcome these problems? After five 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 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. The second step is for the Aggregator to aggregate everyone's intention and initiate a transaction after the merger. A transaction interacts with the liquidity pool. 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 problems of UTXO, and CKB is also working on some solutions to implement the processes mentioned above.

There is another aspect, UTXO is very suitable to support 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 running on the account model, because every pending order and canceled order will be lost even if it is not completed. There is a handling fee, which is unaffordable for PMF, so the AMM model later appeared. 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, 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 will be More suitable for UTXO model. Including AMM, you 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 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. EVM chains are mostly copycat projects with no innovative ideas at all. We want to really attract developers native to 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 there can be a new BTCFi paradigm under this model. come out.

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 which have relatively complete support. RISC-V is now a mainstream CPU architecture and can be expected to surpass ARM within 5 to 10 years. It also supports many compilers. But currently CKB officially supports more Rust and C, and also supports some scripting languages. We have also made some runtimes ourselves 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. The instruction set is designed with 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 thinking It’s different from Ethereum. 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, which we try our best to avoid. 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 for us to be compatible with the new ZK facilities. From the instruction level, No translation is required, and the efficiency is obviously much higher than running RISC-V on the 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 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 from multiple parties in the Bitcoin ecosystem. There is a strong game 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 and EIP-1159 were very controversial at the time, but the Ethereum Foundation or Vitalik himself largely covered the sky with one hand. It is obvious to all. 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.

So no matter 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 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 with strong inclusiveness and error correction capabilities.

Take the second layer of BTC as an example again. I saw that your website BTCEden summarizes various solutions with different ideas, including client verification modes such as Lightning Network and RGB, as well as side chains and even across Ethereum. On the second floor of Fangfang and 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 anything about status 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.

Yayasan CKB juga cuba menjadikan proses membuat keputusan lebih terpencar. Sudah tentu, saya tidak berada dalam yayasan sekarang dan tidak mempunyai hak untuk bercakap, tetapi saya dapat melihat lebih banyak peranan secara beransur-ansur menjadi lebih berorientasikan komuniti. Saiz keseluruhan CKB masih agak kecil, dan permintaan untuk membuat keputusan terdesentralisasi tidak begitu kukuh. Jangkaan semua orang untuk CKB mungkin lebih pantas. Tetapi setakat yang saya tahu, pembuat keputusan teras CKB sangat terbuka dan tidak akan mengambil terlalu banyak kuasa ke tangan mereka sendiri. Mereka pasti akan mencari masa yang sesuai untuk menyelesaikan desentralisasi.

The above is the detailed content of Conversation with Cipher, the proposer of RGB++: RGB++, UTXO and BTCFi in my eyes. For more information, please follow other related articles on the PHP Chinese website!