RGB++の提唱者Cipherとの対談：私の目に映るRGB++、UTXO、BTCFi

2024 年 7 月 22 日、Geek Web3 は幸運にも CKB の共同作成者であり RGB++ の提案者である Cipher を招待し、RGB++ と UTXO システム、CKB 自体、およびビットコイン エコシステムに関する一連の交換を実施しました。この期間中、Cipher He は自身の過去の経験、BTCFi に対する RGB++ レイヤーと UTXO モデルの独自の重要性、CKB とビットコインのエコロジーに関するいくつかの問題と意見について話しました。このインタビューで取り上げられる具体的な質問は次のとおりです:

1. Cipher の個人的な経験

2. UTXO スタックと RGB++ レイヤー間の関係

3. ビットコインと BTCFi の第 2 レイヤーに関する見解

4. EVM システムと比較した RGB++ レイヤーの独自のシナリオと開発コンセプト

5. CKB 独自の設計哲学の解釈

6. Defi エコロジカル構築における UTXO モデルのいくつかの欠点を解決する方法

7. RISC-V および関連する契約開発言語の選択を選択します

8. ビットコインとイーサリアムのエコロジーにおける分散化問題に関する見解

以下はこのインタビューのテキスト版です。ぜひ注意深くお読みください。

ファウスト: まず、サイファーに自己紹介をしてもらいますか?

Cipher: 私が初めてブロックチェーンに触れたのは、2013 年にビットコインのマイニングに参加したときでした。そのため、初めてマイニングマシンを購入したときに、怪しいメーカーに遭遇しました。 。 2014年か2015年にビットコインの価格が大きく変動したため、コインを自動的に投機するプログラムを書いて少し儲けました。 2015年末に弱気相場が到来し、私はその時はまだ何の信念も確立しておらず、ただ投機をしていました。

2016年、私はブロックチェーン業界に正式に参入し、システム内のブロックチェーン研究機関に入り、プロダクトリーダーの立場で中央銀行のデジタル通貨とアライアンスチェーンの開発に参加しました。この期間中に、いくつかのホワイト ペーパー、業界における初期のプライバシー保護文書、デジタル財産権に関連する特許も執筆しました。

18 年間で、私はアライアンス チェーンが間違った方向であることに完全に気づきました。すべてのアライアンスにはアライアンス リーダーが存在し、プレフィックス付きのアライアンス チェーンであればブロックチェーンを使用する必要はありません。 「国」なんて、さらに意味不明になる、ただのリーダーの言葉だ。その後、許可を必要としないパブリック チェーンに焦点を当てました。偶然にも、私と数人のパートナーが CKB の初期構築に参加し、製品と研究作業の一部を担当しました。

2021年頃、私はCKB Foundationから徐々に独立し、JoyIDなどCKBエコシステム内の周辺プロジェクトを行うために自分の会社を設立します。 JoyID には現在 500,000 人以上のユーザーがおり、業界で最も完成度の高い Passkey ウォレットであると言えます。Passkey 自体にはデバイスの互換性に制限がありますが、それでも非常に使いやすく、携帯電話番号の必要性を直接排除できます。 、電子メールアドレスとニーモニック セキュリティモデルの観点から見ると、この言葉は非保管ウォレットです。

2023年の碑文の夏までに、ビットコインエコシステム全体が回復し始め、ルネサンスさえ見られます。今年の2月中旬、私はビットコインのセキュリティを失うことなくBTCFiのネイティブスマートコントラクト環境を構築するというビジョンを持って、RGB++というコンセプトを提案しました。私たちはすぐに専用グループを設立し、今年 4 月のビットコインの半減期の前に RGB++ プロトコルを開始しましたが、結果はかなり良好でした。同時に、CKBエコシステム内のDEX、Launch Pad、Suanwenなどのプロジェクトも次々と立ち上げられています。全体として、RGB++ エコシステムは急成長段階にあります。

BTCの機能拡張の問題を解決した後、拡張などに注力してきました。 4月に、私たちはUTXOパブリックチェーンまたはビットコインの第2層UTXOスタックを立ち上げるための特別な会社を設立しました。なぜ UTXO モデルを選択したかというと、中心となるのは、ビットコイン自体が UTXO モデルであり、ビットコイン上でレイヤー 2 を行う場合、状態遷移の証明、クロスチェーンをどのように実装するかということです。資産強制引き出しやDAなどの部分は？イーサリアムのアカウントモデルやRollupの考え方を真似しても、良い結果を得るのは難しいでしょう。これは私の一貫した見解でもあります。イーサリアムのアイデアをビットコインにコピーしても、うまくいくことはほとんどありません。

UTXO スタックは現在、第 1 ラウンドの資金調達を完了しており、第 2 ラウンドの資金調達も進行中です。最近ではビットコイン エコシステムの人気が低下していますが、私たちは依然として非常に自信を持っており、旗を掲げて近い将来を構築することに意欲を持っています。 -BTCFi 機能拡張とプログラム可能なエコロジーのためのネイティブ ソリューション。現在、私たちは市場レベルとビジネスレベルでさらなる取り組みを行っており、この分野でのいくつかの環境関連活動が今後も進展することを期待していただけます。

Wuyue: UTXO スタックと RGB++Layer の関係は何ですか?どうやら二人の間には部下の関係があるようで？この点についてうまく紹介してもらえますか？

サイファー: 2人の関係は2つの観点から紹介できます。ブランドの観点から見ると、RGB++Layer は UTXO Stack ブランドの製品であり、技術的な観点から見ると、RGB++Layer は同型バインディングを使用してスマート コントラクト実行レイヤーを BTCFi に追加します。同型バインディングは、UTXO に関連する限り、BTC や CKB だけでなく、Cardano、Fuel、Sui などの広大なパブリック チェーン エコシステムにも適用できます。

UTXO スタックに関しては、OP スタックに似ており、BTC Layer2 を迅速に開始するために使用できます。これには、Leap を介したトランザクションのためにメインネットワークの BTCFi アセットを Layer2 に転送できる同形バインディング機能が直接付属しています。 OPスタックのスマートコントラクトはイーサリアム上で動作し、UTXOスタックのスマートコントラクトはRGB++レイヤー上で動作します。

2 つの最終的な所属と優先順位に戻りますが、これには論理的な問題が含まれます。すべての L2 の確立の前提は、基本的に、L1 がすでに十分に混雑しているか、L1 の機能が制限されており、ユーザーのニーズを満たすことができないということです。

現在、ビットコイン + RGB++レイヤーで構成されるスマートコントラクトレイヤーに登場するアセットやアプリケーションはそれほど多くありません。そのため、新しい開発者とユーザーを最初にRGB++レイヤーに誘導し、Defiアプリケーション、取引プラットフォームを開発できるようにしたいと考えていますおよび資産発行では、まず BTCFi エコシステムを開発し、次に L2 の作業をさらに深く進めます。 BTCFi 自体の人気が十分に高まった場合にのみ、BTC の拡大が現実的な需要となる可能性があります。現時点では、UTXO スタックの立ち上げは当然のことになります。

ファウスト: ここでBTCの第2層について言及しましたが、私たちがいくつかのチャネルから受け取った最近のニュースでも、BTC層2が周期的な底に達し、より多くの人々や機関がBTCFiに注目していると考えられています。しかし、多くのBTCFiは単なるWBTCモデルであり、ビットコインを他のパブリックチェーンまたはビットコインサイドチェーンに橋渡しするものであり、BTCネイティブではまったくありません。 BTCFi と WBTC のようなものの本当の違いは何だと思いますか?

暗号: 私の一貫した見解は、EVM システムの BTC レイヤー 2 の上限が非常に低いということです。その理由は非常に単純で、ビットコインのエコシステムを拡張するためではなく、他のエコシステムに BTC を導入するためです。ビットコインのメインネットにスマート コントラクトを実装するのは難しく、TPS を高くすることはできないことはわかっています。非常に簡単な方法があります。それは、ビットコインを他の場所にブリッジすることです。これは問題を解決しているように見えますが、実際には核心的なことを回避しています:

このように、ビットコイン自体の生態系はまったく開発されておらず、ビットコインマイナーやチェーン上のデータなどには収入がありません。変更があったとしても、最も単純なアセットをブリッジするだけです。ブリッジが外された後は、新しいストーリーや新しいシーンを取得できますか?明らかに違います。なぜなら、あなたが行うことはすべて WBTC とイーサリアム エコシステムによって非常に早くから行われているためです。イノベーションはなく、追加の BTC ブリッジ資産が作成されるだけです。それで、あなたの存在の意味は何ですか？

EVMも同様ですが、イーサリアム上の既存のDeFiシステムをまだ超えることができますか？ EVMベースのビットコインの第2層は、エアドロップへの期待により短期的には偽りの繁栄を生み出す可能性があるが、その長期的な発展は容易に制限される可能性がある。ビットコインのエコシステムに長期的な影響を与え、力を与えることができるのは、よりネイティブな UTXO ベースのレイヤー 2 でなければなりません。

いわゆるネイティブ BTC 第 2 層。その魅力的な点はその正当性ではなく、この「ネイティブ」がビットコイン エコシステムにさらに興味深いシナリオをもたらすことができることです。たとえば、RGB++ にはブリッジレス クロスチェーン リープと呼ばれるテクノロジーがあり、BTCFi アセットは L1 から L2 または L2 の間を行き来でき、従来のクロスチェーン ブリッジの Lock-Mint パラダイムに依存する必要がなく、回避できます。従来のクロスチェーンブリッジには多くのリスクがありますが、クロスチェーンの応答速度と流動性の集約において大きな利点もあり、Defiエコシステムに大きな利便性をもたらします。 Leap機能は4月からオンライン化されており、多くのユーザーがこの技術による利便性を享受しています。これは、ビットコイン ネイティブ ソリューションによってもたらされるイノベーションの 1 つです。

さらに、BTCのネイティブ属性があるかどうかも視聴者に影響します。たとえば、多くのBTC保有者はメタマスクの使用さえ好まず、BTCエコシステムの既存の主流ウォレットを使用することを好みます。ビットコインウォレットがEVMアプリケーション層でアカウントを抽象化できるようにするいわゆるAAソリューションがいくつかありますが、このアプローチにはBTC保有者の参入を妨げるさまざまな問題があります。私たちのような UTXO ベースの 2 層ソリューションは、ビットコイン ウォレットとの対話を直接サポートしており、その AA 実装は最下層に近いため、ユーザーはこれに気付かないかもしれません。これは非常に便利で、より簡単で、より使いやすくなっています。

さらに、UTXO モデルは「オフチェーン計算、オンチェーン検証」であることがわかっており、このモデルはインテント駆動型のトランザクション シナリオに特に適しています。いわゆる意図は、私のトランザクションは、私が支払う意思と何を取得する必要があるかをシステムに伝えるだけですが、スマートコントラクトの呼び出し方法や関数パラメータの設定方法などについて心配する必要はありません。欲しい入力結果と出力結果をチェーンに乗せて検証するだけです。 Ethereum でインテント シナリオを実行したい場合、Operator や Aggregator などの一連のコンポーネントが必要になる可能性があり、これらは比較的肥大化しますが、UTXO の世界では非常にシンプルです。これは、EVM の第 2 層と比較した UTXO の第 2 層の特徴でもあります。つまり、私たちはUTXOがレイヤー2に生み出すことができる新しいDeFiシーンについて楽観的です。

ファウスト: RGB++Layer と BTC の統合の主なポイントは何ですか? どのシナリオが最も重要ですか? RGB++ と CKB の次の中核となるエコロジカル レイアウトとロードマップには何が含まれますか?

暗号: この 2 つの組み合わせは、主にさまざまなアプリケーション シナリオにあります。いくつかのシナリオについて説明しましたが、ここではいくつかの例を示します。フラッシュ ローンはイーサリアム エコシステムに非常に多く存在しており、トランザクション内で一連の契約を継続的に呼び出し、トランザクション結果を取得して融資プラットフォームに表示することができます。つまり、私があなたに貸した資産と利息をあなたに返すことができることを私たちは知っています。すぐにあなた。オンチェーンのフラッシュ ローンを使用して、さまざまな金融活動を迅速に実行できますが、UTXO の世界にはフラッシュ ローンはありませんが、他のものもあります。

たとえば、UTXO には、一連のトランザクションを継続的に生成できるコントラクト スクリプトのネスト メカニズムがあり、前のトランザクションの出力結果を次のトランザクションの入力パラメーターとして直接使用できます。つまり、最初から最後まで接続された取引命令のバッチを迅速に生成できます。たとえば、クロスチェーン DeFi を作成したい場合、まずチェーン A からチェーン B に資産をクロスさせ、その半分を DEX で売却し、売れ残った部分で LP ペアを形成します。トークンを流動性プールに入れます。これらの 4 ステップの操作は、前述のコントラクト スクリプトのネスト方法を使用して、ワンクリックで RGB++Layer のスマート コントラクト フレームワークに実装されます。これは、ユーザーが上記の一連のプロセスを一度操作するだけで済み、残りは分散型スマートコントラクトによって自動的に完了できることを意味します。

ビットコインを通じて資金調達を行う IB0 という明確な統合ポイントもあります。もちろん、これは新しいことではありません。初期の頃、イーサリアムは 1 ビットコインを 10,000 イーサリアムと交換できました。しかし、過去のIB0の問題点は、IC0と同じ資金調達でありながら、資産調達後のゲームプレイがなかったことです。たとえば、最初の 100 ～ 200 ブロックの後、購入価格は段階的に上昇または下降する必要がある場合があります。最後に購入した人は 3 か月間ロックインする必要があるかもしれません。別の例としては、もう 1 か月間ロックして 50% 多くのコインを与える、1 年間ロックして 100% 多く与えるなど、さまざまな方法があります。

以前は、この種の特別なルールは IB0 に実装できませんでしたが、RGB++ レイヤーを通じてこれを変更できます。ビットコイン資産の主な問題は、プログラム可能性がないことです。これは、スマート コントラクトと組み合わせることができれば、資産に権限を与えることができることを意味します。これらのことが解決されて初めて、プロジェクトはビットコインエコシステムを構築する意欲を持つようになります。

BTCFi またはその他の Fi の場合、前提条件は資産とそれに対応する豊富なシナリオがあることです。この資産が BTC 自体に限定されている場合、多くの場合、本当に必要な場合は、リモート ステーキングやクロスチェーンなどの単一のシナリオにしか関与できません。生態系を繁栄させるためには、百の花を咲かせるためにさまざまな資産を発行する必要があります。現在のイーサリアムの世界では、ERC-20 資産と ETH 自体の市場価値は同等であるはずであり、後者は前者よりも高くなる可能性さえありますが、ビットコイン エコシステム内の非 BTC 資産は市場価値の 1% にも満たない可能性があります。 BTCの市場価値。したがって、BTCエコシステムで新しい資産をどのように作成するかが開発の鍵となります。

したがって、RGB++ レイヤーとビットコインの最大の組み合わせは、RGB++ レイヤーのプログラマビリティを利用して、ビットコインを真に強化する分散型アセット クラスを作成することだと思います。ただし、これは、Memecoin か集中型アセットのどちらかでは起こりませんでした。要約すると、私たちはスマート コントラクト層を使用してビットコイン エコシステムの新しい資産を作成する可能性について非常に楽観的です。

ファウスト: 2018年から2019年にかけてCKBは自らを「レイヤー2専用に設計されたレイヤー1」と位置づけ、レイヤー2のステータス決済などのシナリオをサポートする設計を多く行ってきました。ロールアップ。一元的な検証レイヤー。この点に関して、通常のパブリックチェーンと比較したCKBの主な利点は何だと思いますか?

暗号: ビットコインエコシステムのレイヤー 1 とレイヤー 2 を定義するのは実際には困難です。 CKB や RGB++Layer は、ある第 2 層の検証と確定を前提としたものではないと思います。 UXTO チェーンとして、CKB はチェーン上で直接計算を実行するのではなく、オフチェーンの計算結果を検証することに長けています。これは、CKB が設立された当初にチーフアーキテクトとして Jan が主張していた点です。ブロックチェーンのコンピューティング リソース、ストレージ リソース、帯域幅リソースは非常に貴重であり、複雑な作業を行うために使用されるべきではなく、最も単純な作業を行う必要があります。

実際には、レイヤー 2 であってもレイヤー 1 であっても、ステータスの変更について合意に達する必要があります。合意を得るには 2 つの方法しかありません。1 つはステータスの変更を実行するコントラクトを取得することであり、全員がそれを再計算できます。合意に達するために、これがアカウント モデルのロジックです。2 つ目は、オフチェーンでステータス変更を完了し、その有効性を証明する証拠を私に送信して、私が確認するだけです。元のコンテンツを自分で計算する必要はありません。これは実際にはロールアップのアイデアです。

私たちが 2018 年に 2 番目の方法を提案したとき、誰もがそれを一度計算して再度検証するのは同じことであるように見えましたが、実際には違うと言いました。たとえば、並べ替えアルゴリズムでは、結果を検証する複雑さは、直接計算する複雑さよりもはるかに少なくなります。当時、多くの人は通常の ERC-20 資産移転にこれを行う必要はないと感じていましたが、ZK であろうとロールアップであろうと、これはオフチェーン コンピューティングとオンチェーンのパラダイムであることは誰もが知っています。検証。そうして初めて、2 番目の方法がより効果的で価値があることがわかります。

UTXO モデルには、並列コンピューティングにも多くの利点があります。イーサリアムが最近並列 EVM について言及したことは知っていますが、いくつかのルートを通じて、いわゆる並列 EVM が実際に使用されると、並列度が 2 度にさえ達しないことがよくあることを知りました。 UTXO は本質的に並列コンピューティングをサポートしており、CPU コアの数と同じだけ多くのスレッドを並列に実行できます。この効率は EVM ベースのものとは比較できません。

Nous empruntons la voie UTXO depuis 5 ans. Dans certains des scénarios que nous venons de décrire, UTXO présente naturellement plus d'avantages que le modèle de compte. De plus, nous et Bitcoin sommes tous deux UTXO, qui peut prendre en charge la liaison isomorphe, simplifiant encore davantage certaines fonctions. Je pense donc que le principal avantage réside dans l’architecture. Il sera certainement plus efficace pour nous d’utiliser l’architecture UTXO pour nous connecter à Bitcoin.

Faust : Certaines personnes pensent qu'UTXO n'est pas propice au support de DeFi. Par exemple, il n'y a aucun moyen de s'appeler mutuellement entre les différents UTXO. Ils pensent même que RGB++ et CKB rencontreront de la résistance s'ils développent directement l'écosystème Defi sur. la première couche. Que pensez-vous de ces points de vue ? Et quelles solutions avez-vous introduites pour résoudre ces problèmes ?

Cipher : Tout d'abord, ces points de vue sont raisonnables dans une certaine mesure, car le modèle de compte est plus intuitif que le programme autonome précédent, il est acceptable d'envisager certains scénarios d'attaque. Le modèle UTXO n'est pas le cas. Le contrat que vous écrivez sur la chaîne est un validateur, et un calculateur spécial doit être construit à partir de la chaîne. Nous l'appelons généralement un agrégateur ou un générateur. Le générateur est chargé de calculer l'état hors chaîne, de le générer, puis de le jeter sur la chaîne pour vérification, ce qui est relativement compliqué.

S'il s'agit d'une plateforme DEX basée sur UTXO comme UTXOSwap, il vous est difficile de connaître le résultat lorsque vous lancez une transaction, car il peut y avoir 100 personnes soumettant l'opération en même temps, mais les attributs spéciaux d'UTXO le feront exiger que parmi 100 personnes, seules 100 personnes puissent soumettre l'opération en même temps. Si une personne peut réécrire son statut, des problèmes de contention surgiront. Si ces demandes de transaction conflictuelles ne sont pas traitées, seule une transaction sur 100 peut réussir et les 99 transactions restantes peuvent toutes échouer. Ce problème constitue un énorme défi pour la conception des produits, c'est pourquoi tout le monde dit que le modèle UTXO n'est pas propice à la DeFi.

Mais nous avons également constaté que même au cours des deux dernières années, de nouvelles chaînes UTXO sont apparues, comme Fuel. Pourquoi les gens continuent-ils à utiliser le modèle UTXO malgré toutes sortes de problèmes ? Parce qu’il présente de nombreux avantages, que j’ai déjà évoqués. Alors, avec le recul, comment pouvons-nous surmonter ces problèmes ? Après cinq ans de peaufinage, nous disposons déjà d'une solution très mature capable d'implémenter des fonctions de type Uniswap sur la chaîne UTXO. UTXOSwap dans l'écosystème a également été lancé sur le réseau principal il n'y a pas si longtemps, et de nombreuses personnes ajoutent déjà des LP et des paires de trading. Si vous en faites vraiment l'expérience, vous constaterez que ce n'est presque pas différent d'Uniswap.

En fait, la conception d'UTXOSwap est également très simple. Nous divisons chaque transaction en deux étapes. La première étape consiste pour l'utilisateur à soumettre son intention à la chaîne. La deuxième étape consiste pour l'agrégateur à regrouper l'intention de chacun et à l'initier. une transaction après la fusion. Une transaction interagit avec le pool de liquidité. Le pool de liquidité peut satisfaire ces intentions d’un seul coup et générer un UTXO final pour le résultat.

Il peut y avoir un problème de retard de bloc ici, car dans la première étape, l'utilisateur doit d'abord envoyer son intention individuelle à la chaîne, puis l'agrégateur/séquenceur la conditionnera et la traitera, puis passera à l'étape suivante sur le dernière chaîne. Cependant, en fonctionnement réel, les utilisateurs peuvent envoyer directement les intentions de transaction à l'agrégateur hors chaîne, et ce dernier les traitera par lots. Cela peut résoudre le problème du délai de réponse. En fait, c'est similaire au Rollup. Nous disposons déjà de solutions très matures à ces problèmes d'UTXO, et CKB travaille également sur certaines solutions pour mettre en œuvre les processus mentionnés ci-dessus.

Il y a un autre aspect, UTXO est très approprié pour prendre en charge le modèle du carnet de commandes. Dans le passé, il existait un modèle de carnet de commandes DEX sur Ethereum, mais il a disparu plus tard. Il y a de nombreuses raisons à cela. La raison principale est que le carnet de commandes DEX n'est pas adapté pour fonctionner sur le modèle de compte, car chaque commande en attente et. La commande annulée sera perdue même si elle n'est pas terminée. Il y a des frais de traitement, ce qui est inabordable pour PMF, c'est pourquoi le modèle AMM est apparu plus tard. Mais ce sera différent dans le modèle UTXO. Par exemple, 100 commandes peuvent être passées en même temps. Dans le monde UTXO, il est facile et peu coûteux d'associer une transaction à 100 UTXO. . Par conséquent, dans le modèle UTXO, le carnet de commandes DEX sera plus utile.

De plus, nous disposons également de la technologie de signature partielle PSBT. La transaction de commande en attente n'a même pas besoin d'être soumise à la chaîne. Vous pouvez simplement envoyer une signature concise qui regroupera les signatures de plusieurs parties et activera la transaction. la chaîne ensemble. De cette façon, le modèle de carnet de commandes sera plus adapté au modèle UTXO. En incluant AMM, vous pouvez utiliser des prix à intervalles comme UniswapV3 pour fournir de la liquidité virtuelle, en plaçant différentes actions de liquidité à des prix différents au lieu d'une courbe lisse.

Ce sont des scénarios DeFi uniques dans l'environnement UTXO, et ce sont tous des innovations d'assez haut niveau. Il est peu probable que ce niveau d'innovation soit réalisé sur une chaîne EVM. Les chaînes EVM sont pour la plupart des projets copiés sans aucune idée innovante. Nous voulons vraiment attirer les développeurs natifs de l’écosystème Bitcoin, ou les développeurs qui aiment le modèle UTXO. Ces développeurs ont souvent de fortes capacités et une volonté d’innovation. Nous sommes également très optimistes quant à la possibilité d’un nouveau paradigme BTCFi sous ce modèle.

Faust : CKB utilise le jeu d'instructions RISC-V et peut prendre en charge plusieurs langages de programmation. Cependant, certaines personnes pensent que prendre en charge trop de langages de programmation n'est pas une bonne chose et rendra l'écosystème de développeurs d'une chaîne publique confus et fragmenté. À cet égard, quel est selon vous le langage préféré pour le développement sur CKB ?

Cipher : Actuellement, Rust est le premier choix, suivi de C, qui ont tous deux un support relativement complet. RISC-V est désormais une architecture CPU grand public et devrait surpasser ARM d'ici 5 à 10 ans. Il prend également en charge de nombreux compilateurs. Mais actuellement, CKB prend officiellement en charge davantage de Rust et de C, ainsi que certains langages de script. Nous avons également créé nous-mêmes certains environnements d'exécution pour prendre en charge LUA et Javascript, mais la perte de performances sera énorme et, à l'extrême, il peut s'agir d'un ralentissement de 30 à 300 %. Par conséquent, s'il s'agit d'une entreprise à forte intensité d'algorithmes, il est toujours recommandé de l'écrire en Rust ou en C, et il n'y aura pas trop de langages de programmation​​pour fragmenter l'écosystème des développeurs.

Je veux en fait parler des avantages de RISC-V lui-même. Lorsque nous avons lancé CKB pour la première fois en 2018, nous étions les seuls au monde à choisir d'utiliser RISC-V comme machine virtuelle à chaîne publique. simple. RISC-V convient aux périphériques matériels. Le jeu d'instructions est conçu avec deux caractéristiques : simplicité et prudence. Étant donné que le jeu d'instructions est conçu pour le matériel, il est souvent relativement stable et n'augmente ou ne diminue pas les instructions chaque année comme EVM. Ce type de prudence est exactement ce qu'exigent les protocoles open source.

Deuxièmement, pour les plateformes de contrats intelligents ou les blockchains, nous pensons qu'il est préférable de ressembler à Bitcoin, avec ses fonctions de base tendant à être corrigées, sinon il sera trop facile de causer des problèmes en ajoutant ou en soustrayant du contenu tous les trois jours. On peut dire que toute notre réflexion est différente de celle d’Ethereum. EVM itère essentiellement les opcodes chaque année, et cela a été le cas ces dernières années. Cela aura un impact sur la compatibilité et la stabilité du programme, et nous faisons de notre mieux pour éviter cela. C'est donc sur la base de cette idée que nous avons adopté le jeu d'instructions RISC-V, qui s'est avéré très avant-gardiste.

Maintenant que ZK devient populaire, vous constaterez que de nombreux projets utilisent RISC-V comme machines virtuelles au niveau inférieur. En tant que chaîne publique basée sur RISC-V, il nous est très facile d'être compatible avec le nouveau ZK. Au niveau de l'instruction, aucune traduction n'est requise et l'efficacité est évidemment bien supérieure à l'exécution de RISC-V sur l'EVM.

Faust : Du point de vue de CKB, que pensez-vous de l'écosystème Bitcoin ? Par exemple, pensez-vous qu’il existe une organisation centralisée similaire à la Fondation Ethereum dans l’écosystème Bitcoin actuel ? Certaines personnes ont pensé que BlockStream était un peu arbitraire. CKB a-t-il sa propre opinion à ce sujet ?

Cipher : Je pense que la structure de l’écosystème Bitcoin est complètement différente de celle de l’écosystème Ethereum. La Fondation Ethereum a une voix très forte. En regardant le monde Bitcoin, on peut dire que les principaux développeurs derrière elle sont une organisation avec une influence relativement forte. Cependant, l’écosystème Bitcoin a des freins et contrepoids évidents de la part de plusieurs parties. Il existe une forte relation concurrentielle entre les pools miniers, les développeurs et les principaux acteurs du Bitcoin. Cela ne signifie pas que les mineurs accepteront inconditionnellement tout ce que les développeurs proposent. Si la proposition est excessive, les mineurs et les pools miniers s'y opposeront directement.

Je pense que ce point est différent d'Ethereum. Des choses comme Ethereum POW to POS et EIP-1159 étaient très controversées à l'époque, mais la Fondation Ethereum ou Vitalik lui-même ont largement couvert le ciel d'une seule main. D’un autre côté, l’écosystème Ethereum est désormais très vaste, avec de nombreux actifs émis de manière centralisée, tels que les RWA, les stablecoins, etc. Une fois qu’un véritable fork se produit, ce sont ces actifs centralisés qui détermineront véritablement l’orientation future de l’émetteur.

Ainsi, que ce soit subjectivement ou objectivement, les forces centralisées dirigées par EF dans l'écosystème Ethereum ont une voix beaucoup plus forte que les différentes organisations de l'écosystème Bitcoin. Un autre point est qu'il n'y a pas de valeurs particulièrement unifiées dans l'écosystème Bitcoin. Par exemple, les développeurs principaux sont plus proches du maximalisme du Bitcoin et résistent à des choses comme OP_CAT ou des inscriptions. Ils espèrent que Bitcoin n'apportera pas trop de changements aux développeurs périphériques. enclin à soutenir le passage d'OP_CAT ou similaire. Sur la couche externe, des équipes telles que Lightning Network et RGB sont plus enclines aux nouveautés que les deux premières. Ensuite, il y a des gens comme nous qui sont non seulement plus disposés à accepter de nouvelles choses, mais qui prennent également l'initiative de rechercher l'innovation et le changement. La dernière couche est la deuxième couche du pont multi-signature et du système EVM.

Parce qu'il existe toutes sortes de personnes d'origines différentes, l'écosystème Bitcoin est très tolérant. Il n'y a pas lieu de craindre qu'une certaine couche ou une certaine personne se trompe. Ses erreurs biaiseront l'ensemble de l'écosystème. Il y a tellement de groupes de personnes, du moment qu'un groupe a raison à la fin. Bien que le modèle d'Ethereum soit plus rapide en surface, le modèle de Bitcoin est plus stable. Il n'y a pas lieu de s'inquiéter d'une mauvaise décision d'une petite personne qui entraînera l'ensemble de l'écosystème dans l'abîme. De ce point de vue, nous sommes très optimistes quant à l’écosystème Bitcoin, car il ressemble à un creuset et possède de fortes capacités d’inclusivité et de correction d’erreurs.

Prenons à nouveau la deuxième couche de BTC comme exemple. J'ai vu que votre site Web BTCEden résume diverses solutions avec différentes idées, y compris des modes de vérification client tels que Lightning Network et RGB, ainsi que des chaînes latérales et même sur Ethereum sur la seconde. étage de Fangfang et Bitcoin, bref, une centaine de fleurs s'épanouissent, chacune montrant ses capacités. Et si vous regardez Ethereum, personne n'a fait Sharding, et personne n'a rien fait concernant les canaux d'état et Plasma. Il n'y a presque qu'une seule route du système Rollup. Alors bien sûr nous préférons l’écosystème Bitcoin, plus libre et plus stable.

La Fondation CKB tente également de décentraliser la prise de décision. Bien sûr, je ne fais pas partie de la fondation pour le moment et je n’ai pas mon mot à dire, mais je vois de plus en plus de rôles devenir progressivement plus axés sur la communauté. La taille globale de CKB est encore relativement petite et la demande de prise de décision décentralisée n'est pas si forte. Les attentes de chacun à l'égard de CKB pourraient être plus rapides. Mais autant que je sache, les principaux décideurs de CKB sont très ouverts d’esprit et ne prendront pas trop de pouvoir. Ils trouveront certainement le bon moment pour achever la décentralisation.

以上がRGB++の提唱者Cipherとの対談：私の目に映るRGB++、UTXO、BTCFiの詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。