コンパイル：雾月&白丁、极客web3
この記事は、2019年のHBS Blockchain+Crypto Club ConferenceでNervosの共同創設者であるJanが行ったスピーチです。スピーチのテーマは、Layer2とLayer1の関係に焦点を当て、モジュラーブロックチェーンが正しい方向性であると明言し、またブロックチェーンのデータストレージメカニズムの問題についても触れています。また、Janは興味深い話題を提起しています：Layer2の台頭がLayer1の飢餓を引き起こす場合、どのように解決すべきか。
最初のLayer2およびモジュラーブロックチェーンのナレッジをサポートする最初のチームとして、Nervosの主張は18年と19年に非常に先見的であり、その当時のETHコミュニティはシャーディングについて非現実的な幻想を抱いていましたが、高性能なシングルチェーンのナレッジはまだ充分に検証されていませんでした。
しかし、2024年の今日、ETH坊Layer2が直面した問題や、分散化と信頼性に関する問題に対するSolanaなどの「高性能なパブリックチェーン」の欠点を見ると、Janが5年前に持っていた洞察力は非常に優れていると言わざるを得ません。レイヤー2に興味があるため、「Geekweb3」はJanの講義をテキスト形式で整理し、Nervos、ETH坊、BTCコミュニティのレイヤー2愛好家たちが一緒に学び、議論することを歓迎します。
以下はJanの講演の原文です。
これは私のL1とL2（セカンドレイヤーネットワーク）の定義です、図参照。
まず、Nerovsは分散化経済ニーズを満たすためのブロックチェーンネットワークであり、「すべての問題を解決する」責任はありません。私たちの理解では、**Layer1とLayer2の違いは、コンセンサスの強さにあります。L1ネットワークは、いわゆる「グローバルコンセンサス」として最も広範なコンセンサスを持つ必要があります。**許可なく参加できるグローバルコンセンサスにより、世界中の誰でもL1のコンセンサスプロセスに参加でき、最終的にLayer1は分散化経済の「アンカー」として機能することができます。この観点から、L1を「コンセンサスレイヤー」と呼ぶことができます。
相対的に、L2ネットワークのコンセンサス範囲は少し小さくなる可能性があります。その参加者は特定の国、あるいは特定の業界、さらには特定の企業や機関、または非常に小さなコミュニティから来るかもしれません。L2のコンセンサス範囲での犠牲は進歩の一形態であり、例えばより高いTPS、より低いレイテンシー、より良い拡張性などをもたらします。L2を「プロトコル層」と呼ぶことができ、通常、L1とL2の間はクロスチェーンブリッジを介して接続されます。
必ず強調しなければならないのは、私たちがL2ネットワークを構築する目的は、単にブロックチェーンのスケーラビリティの問題を解決することだけでなく、階層構造が「モジュラーブロックチェーン」を最も容易に実現する方法だからです。」モジュラーブロックチェーン」とは、異なる種類の問題を異なるモジュールに投入して解決することです。
多くの人々がブロックチェーンのコンプライアンスと規制について議論していますが、BTCやETHを既存の規制フレームワークに組み込む方法はありますか？レイヤー構造はその問題に対する1つの解答かもしれません。レイヤー1に直接規制要件に対応するビジネスロジックを追加することは、分散性と中立性を損なう可能性があるため、コンプライアンスに関連するロジックはレイヤー2で独立して実装することができます。
Layer2は特定の規制や基準に基づいてカスタマイズすることができます。例えば、許可制の小規模なブロックチェーンを構築したり、ステートチャネルネットワークなどを作成したりすることができます。これにより、コンプライアンスを実現しながら、Layer1の分散化と中立性に影響を与えることはありません。
また、**セキュリティとユーザーエクスペリエンスの間の衝突を階層構造で解決することもできます。**たとえば、自分の秘密鍵の安全性を確保したい場合、ある程度の利便性を犠牲にする必要がありますが、ブロックチェーンも同様です。ブロックチェーンの絶対的な安全性を確保したい場合、そのチェーンのパフォーマンスなどを犠牲にする必要があります。
しかし、階層構造を使用すると、L1ネットワークで完全なセキュリティを追求し、L2ネットワークでわずかなセキュリティを犠牲にしてより良いユーザーエクスペリエンスを得ることができます。例えば、L2でステートチャネルを使用してネットワークのパフォーマンスを最適化することができ、ドロップレイテンシーを実現できます。つまり、Layer2の設計は、セキュリティとユーザーエクスペリエンスのトレードオフです。
上記の内容は自然な流れで、1つの問題が浮かび上がります：すべてのブロックチェーンがLayer1として機能できるかどうか？
答えは否定的ですが、まず第一に、Layer1ネットワークの分散化とセキュリティはすべてよりも高いです。なぜなら、検閲に対抗するために分散化が必要だからです。Layer1のセキュリティを追求するのは、根本的にはL1がブロックチェーンネットワーク全体の根であり、暗号化経済システム全体のアンカーであるからです。
このような評価基準において、BTCとイーサリアムは間違いなく最もクラシックなL1ネットワークであり、非常に強力なコンセンサス範囲を持っています。これら2つ以外のほとんどのブロックチェーンはL1の基準を満たしておらず、コンセンサスレベルが低いです。たとえば、EOSのコンセンサスは基準を満たしておらず、L2ネットワークとしての役割を果たすことしかできません。また、EOSの一部のルールはEOS自体にしか適用されません。
明確にLayer1の定義を明確にした後、我々は指摘しなければならない、既存のいくつかのL1ネットワークには3つの問題があること、これらの問題はBTCとETHのブロックチェーンにもある程度存在している。
ブロックチェーンを使用する際には、一定の費用が発生しますが、BTCの経済モデルでは手数料の構造設計において、計算コストとネットワーク帯域幅コストのみを考慮しており、データストレージコストは十分に考慮されていません。
例えば、ユーザーはオンチェーンにデータを保存するために一度だけ料金を支払う必要がありますが、保存期間は永久ですので、人々は保存リソースを乱用し、何でも永久にチェーンに上げることができます。結果として、ネットワーク内のフルノードはますます高い保存コストを負担しなければなりません。これは次の問題を引き起こします：ネットワークへの参加コストは、すべてのノードオペレーターに対して最大限に引き上げられます。
あるブロックチェーンの状態/アカウントデータの合計が1TBを超える場合、誰もが完全な状態と取引履歴を簡単に同期できるわけではありません。このような場合、完全な状態に同期できたとしても、対応する取引履歴を自己検証することは非常に困難であり、これによりブロックチェーンの信頼性が低下する可能性があります。信頼性は、ブロックチェーンの最も重要な価値観です。
イーサリアム財団は上記の問題を認識しており、EIP-103にストレージリースの設計を盛り込んでいますが、これは最適な解決策ではないと考えています。
Nervosでは、新しい状態モデルである"Cell"が提案されており、これはUTXOの一種の拡張と見なすことができます。BTCUTXOの状態では、BTCの残高の数値しか保存できませんが、Cellには任意のタイプのデータを保存でき、BTCUTXOのamountとinteger valueを"Capacity"として一般化し、Cellの最大保存容量を指定するために使用されます。
この方法により、私たちはCKB上のネイティブ資産の数量と状態のサイズを結び付けます。任意のセルが占めるスペースは容量制限を超えることはできないため、データ総量は一定範囲内に保たれます。
また、ノードのパフォーマンスに影響を与えないよう、適切なトークンのインフレ率によって状態データのサイズを確保しています。誰でもCKBネットワークに参加できます。彼らは履歴データを検証することも、最終状態の妥当性を検証することもできます。これがブロックチェーンのストレージ問題に対するCKBの解決策です。
もし私たちがLayer2で拡張を行い、そして大量の取引活動をLayer2に移すと、必然的にLayer1での取引量が減少し、Layer1のマイナー/ノード運営者の経済的報酬もそれに応じてドロップします。そのような場合、Layer1のマイナー/ノード運営者の積極性が低下し、最終的にLayer1のセキュリティが低下する可能性があります。これがいわゆるLayer1の餓死問題です。
極端な例を挙げると、すべての取引活動をL2に移すと、その基盤であるL1は持続不可能になります。では、この問題をどのように解決すればよいのでしょうか？
この点を考慮すると、ブロックチェーンネットワークにはどの種類のユーザーがいるかを区別する必要があります。簡単に言えば、Store of Valueユーザー（SoVユーザー、価値の保存に関するユーザー）とUtilityユーザー（ユーティリティユーザー）に分けることができます。
CKBを例に取ると、SoVユーザーはネイティブ資産のCKBトークンを価値の貯蔵手段として使用し、一方でユーティリティユーザーはCellを使用して状態を保存します。SoVユーザーは、CKBトークンのインフレによる価格の希釈を排除し、一方でユーティリティユーザーはマイナーに状態の保管料を支払わなければならず、この料金はデータの保管期間と使用空間に比例します。
**私たちはネットワークで継続的に新しいCKBトークンを発行し、固定のインフレ率を生み出し、それをマイナーに支払います。**これは実質的には、ユーティリティユーザーの手持ちトークン価値の希釈に等しい（これはCKB経済モデルの3つの発行モードの1つである「二次発行」で、この方法では毎年134.4億枚のCKBトークンが固定で発行されます。詳細は「Stable++解読：RGB++ Layer初の安定通貨プロトコルが正式にスタート」をご覧ください）。
このプロセスでは、SoVユーザーの資産も希釈されるため、インフレの損失を相殺するために一定の補助金を提供することができます（これが後のNervosDAOの分配です）。つまり、マイナーがCKBのインフレから得る利益は、実際にはユーティリティユーザーによって支払われます。まもなく、CKBのトークンエコノミクス論文を発行し、関連する問題を詳しく説明します。
このようなトークノミクスの設計に基づいて、CKBチェーン上に取引がなくても、マイナーは報酬を受け取ることができ、その結果、どんな“バリューストレージ層”またはLayer2とも互換性があります。以上より、意図的な固定インフレによってLayer1の飢餓問題を解決します。
ユーザーは異なる暗号化プリミティブを必要とし、異なる暗号化方式や異なる署名アルゴリズム（例：Schnorr、BLSなど）を使用する必要があります。
Layer1ブロックチェーンとして存在するためには、Layer2との相互運用性を考慮する必要があります。 Ethereumコミュニティでは、ZKまたはPlasmaを使用してLayer2を実現する提案がありますが、Layer1での検証をどのように行うのか、ZKに関連するプリミティブがない場合はどうすればよいでしょうか？
また、**Layer1は他のLayer1との相互運用性も考慮する必要があります。**イーサリアムを例にとると、EVM互換のオペコードとしてBlake2bハッシュ関数を事前にコンパイルするようにイーサリアムチームに要求する人もいます。この提案の目的は、Zcashとイーサリアムをブリッジすることで、ユーザーが両者間で取引できるようにすることです。このような提案は2年前に提出されましたが、現在でも実現されていません。その理由は、対応するブリッジング原語が不足しているため、これがLayer1の発展に深刻な障害をもたらしています。
この問題を解決するために、CKBは高度に抽象化された仮想マシン、すなわちCKB-VMを構築しました。これはBTCの仮想マシンやEVMとはまったく異なります。例えば、BTCには専用のOP_CHECKSIGオペコードがあり、secp256k1署名を検証するために使用されます。一方、CKB-VMでは、secp256k1署名を特別な処理する必要はなく、ユーザー定義のスクリプトやスマートコントラクトで検証できます。
CKBは、デフォルトで署名アルゴリズムとしてsecp256k1を使用していますが、ハードコードされた暗号化プリミティブではなく、CKB-VMで実行されています。
CKBの仮想マシンを構築する最初の動機は、EVMなどの他の仮想マシンでの暗号化プリミティブの実行が非常に遅いため、この状況を改善する必要があるためです。単一のsecp256k1署名のEVMでの検証には約9ミリ秒かかりますが、同じアルゴリズムを使用してCKB-VMで計算すると、1ミリ秒しかかかりません。これはほぼ10倍の効率向上です。
そのため、CKB-VMの価値は、ユーザーがカスタム暗号化プリミティブを定義できるようになったことにあります。そして、ほとんどのものがCKB-VMと互換性があります。なぜなら、CKB-VMはRISC-V命令セットを採用しており、GCC（GNU Compiler Collection、広く使用されているコンパイラのセット）でコンパイルされた言語ならばどれもCKB上で実行できるからです。
また、CKB-VMの高い互換性はCKBのセキュリティを向上させています。開発者は常に言います"自分自身で暗号化アルゴリズムのバージョンを実装しないでください、常に間違えるでしょう"。自分で暗号化アルゴリズムを定義すると、予測不能なセキュリティリスクをもたらすことがよくあります。
要納めると、CKBネットワークはさまざまな方法を使用して、私が提起したL1ネットワークが直面する3つの問題を解決しました。これがなぜCKBが適格なLayer1ネットワークと呼ばれる理由です。
304 人気度
21.99K 人気度
1.45K 人気度
1.4K 人気度
2.43K 人気度
CKB共同創設者Jan：L1飢餓問題とは何か、L2とL1はどのように設計すべきか
コンパイル：雾月&白丁、极客web3
この記事は、2019年のHBS Blockchain+Crypto Club ConferenceでNervosの共同創設者であるJanが行ったスピーチです。スピーチのテーマは、Layer2とLayer1の関係に焦点を当て、モジュラーブロックチェーンが正しい方向性であると明言し、またブロックチェーンのデータストレージメカニズムの問題についても触れています。また、Janは興味深い話題を提起しています：Layer2の台頭がLayer1の飢餓を引き起こす場合、どのように解決すべきか。
最初のLayer2およびモジュラーブロックチェーンのナレッジをサポートする最初のチームとして、Nervosの主張は18年と19年に非常に先見的であり、その当時のETHコミュニティはシャーディングについて非現実的な幻想を抱いていましたが、高性能なシングルチェーンのナレッジはまだ充分に検証されていませんでした。
しかし、2024年の今日、ETH坊Layer2が直面した問題や、分散化と信頼性に関する問題に対するSolanaなどの「高性能なパブリックチェーン」の欠点を見ると、Janが5年前に持っていた洞察力は非常に優れていると言わざるを得ません。レイヤー2に興味があるため、「Geekweb3」はJanの講義をテキスト形式で整理し、Nervos、ETH坊、BTCコミュニティのレイヤー2愛好家たちが一緒に学び、議論することを歓迎します。
以下はJanの講演の原文です。
レイヤー1とレイヤー2の定義
これは私のL1とL2（セカンドレイヤーネットワーク）の定義です、図参照。
まず、Nerovsは分散化経済ニーズを満たすためのブロックチェーンネットワークであり、「すべての問題を解決する」責任はありません。私たちの理解では、**Layer1とLayer2の違いは、コンセンサスの強さにあります。L1ネットワークは、いわゆる「グローバルコンセンサス」として最も広範なコンセンサスを持つ必要があります。**許可なく参加できるグローバルコンセンサスにより、世界中の誰でもL1のコンセンサスプロセスに参加でき、最終的にLayer1は分散化経済の「アンカー」として機能することができます。この観点から、L1を「コンセンサスレイヤー」と呼ぶことができます。
相対的に、L2ネットワークのコンセンサス範囲は少し小さくなる可能性があります。その参加者は特定の国、あるいは特定の業界、さらには特定の企業や機関、または非常に小さなコミュニティから来るかもしれません。L2のコンセンサス範囲での犠牲は進歩の一形態であり、例えばより高いTPS、より低いレイテンシー、より良い拡張性などをもたらします。L2を「プロトコル層」と呼ぶことができ、通常、L1とL2の間はクロスチェーンブリッジを介して接続されます。
必ず強調しなければならないのは、私たちがL2ネットワークを構築する目的は、単にブロックチェーンのスケーラビリティの問題を解決することだけでなく、階層構造が「モジュラーブロックチェーン」を最も容易に実現する方法だからです。」モジュラーブロックチェーン」とは、異なる種類の問題を異なるモジュールに投入して解決することです。
多くの人々がブロックチェーンのコンプライアンスと規制について議論していますが、BTCやETHを既存の規制フレームワークに組み込む方法はありますか？レイヤー構造はその問題に対する1つの解答かもしれません。レイヤー1に直接規制要件に対応するビジネスロジックを追加することは、分散性と中立性を損なう可能性があるため、コンプライアンスに関連するロジックはレイヤー2で独立して実装することができます。
Layer2は特定の規制や基準に基づいてカスタマイズすることができます。例えば、許可制の小規模なブロックチェーンを構築したり、ステートチャネルネットワークなどを作成したりすることができます。これにより、コンプライアンスを実現しながら、Layer1の分散化と中立性に影響を与えることはありません。
また、**セキュリティとユーザーエクスペリエンスの間の衝突を階層構造で解決することもできます。**たとえば、自分の秘密鍵の安全性を確保したい場合、ある程度の利便性を犠牲にする必要がありますが、ブロックチェーンも同様です。ブロックチェーンの絶対的な安全性を確保したい場合、そのチェーンのパフォーマンスなどを犠牲にする必要があります。
しかし、階層構造を使用すると、L1ネットワークで完全なセキュリティを追求し、L2ネットワークでわずかなセキュリティを犠牲にしてより良いユーザーエクスペリエンスを得ることができます。例えば、L2でステートチャネルを使用してネットワークのパフォーマンスを最適化することができ、ドロップレイテンシーを実現できます。つまり、Layer2の設計は、セキュリティとユーザーエクスペリエンスのトレードオフです。
上記の内容は自然な流れで、1つの問題が浮かび上がります：すべてのブロックチェーンがLayer1として機能できるかどうか？
答えは否定的ですが、まず第一に、Layer1ネットワークの分散化とセキュリティはすべてよりも高いです。なぜなら、検閲に対抗するために分散化が必要だからです。Layer1のセキュリティを追求するのは、根本的にはL1がブロックチェーンネットワーク全体の根であり、暗号化経済システム全体のアンカーであるからです。
このような評価基準において、BTCとイーサリアムは間違いなく最もクラシックなL1ネットワークであり、非常に強力なコンセンサス範囲を持っています。これら2つ以外のほとんどのブロックチェーンはL1の基準を満たしておらず、コンセンサスレベルが低いです。たとえば、EOSのコンセンサスは基準を満たしておらず、L2ネットワークとしての役割を果たすことしかできません。また、EOSの一部のルールはEOS自体にしか適用されません。
現在のLayer1ネットワークの問題点
明確にLayer1の定義を明確にした後、我々は指摘しなければならない、既存のいくつかのL1ネットワークには3つの問題があること、これらの問題はBTCとETHのブロックチェーンにもある程度存在している。
1.データストレージの共有悲劇問題
ブロックチェーンを使用する際には、一定の費用が発生しますが、BTCの経済モデルでは手数料の構造設計において、計算コストとネットワーク帯域幅コストのみを考慮しており、データストレージコストは十分に考慮されていません。
例えば、ユーザーはオンチェーンにデータを保存するために一度だけ料金を支払う必要がありますが、保存期間は永久ですので、人々は保存リソースを乱用し、何でも永久にチェーンに上げることができます。結果として、ネットワーク内のフルノードはますます高い保存コストを負担しなければなりません。これは次の問題を引き起こします：ネットワークへの参加コストは、すべてのノードオペレーターに対して最大限に引き上げられます。
あるブロックチェーンの状態/アカウントデータの合計が1TBを超える場合、誰もが完全な状態と取引履歴を簡単に同期できるわけではありません。このような場合、完全な状態に同期できたとしても、対応する取引履歴を自己検証することは非常に困難であり、これによりブロックチェーンの信頼性が低下する可能性があります。信頼性は、ブロックチェーンの最も重要な価値観です。
イーサリアム財団は上記の問題を認識しており、EIP-103にストレージリースの設計を盛り込んでいますが、これは最適な解決策ではないと考えています。
Nervosでは、新しい状態モデルである"Cell"が提案されており、これはUTXOの一種の拡張と見なすことができます。BTCUTXOの状態では、BTCの残高の数値しか保存できませんが、Cellには任意のタイプのデータを保存でき、BTCUTXOのamountとinteger valueを"Capacity"として一般化し、Cellの最大保存容量を指定するために使用されます。
この方法により、私たちはCKB上のネイティブ資産の数量と状態のサイズを結び付けます。任意のセルが占めるスペースは容量制限を超えることはできないため、データ総量は一定範囲内に保たれます。
また、ノードのパフォーマンスに影響を与えないよう、適切なトークンのインフレ率によって状態データのサイズを確保しています。誰でもCKBネットワークに参加できます。彼らは履歴データを検証することも、最終状態の妥当性を検証することもできます。これがブロックチェーンのストレージ問題に対するCKBの解決策です。
2.レイヤー1の飢餓問題
もし私たちがLayer2で拡張を行い、そして大量の取引活動をLayer2に移すと、必然的にLayer1での取引量が減少し、Layer1のマイナー/ノード運営者の経済的報酬もそれに応じてドロップします。そのような場合、Layer1のマイナー/ノード運営者の積極性が低下し、最終的にLayer1のセキュリティが低下する可能性があります。これがいわゆるLayer1の餓死問題です。
極端な例を挙げると、すべての取引活動をL2に移すと、その基盤であるL1は持続不可能になります。では、この問題をどのように解決すればよいのでしょうか？
この点を考慮すると、ブロックチェーンネットワークにはどの種類のユーザーがいるかを区別する必要があります。簡単に言えば、Store of Valueユーザー（SoVユーザー、価値の保存に関するユーザー）とUtilityユーザー（ユーティリティユーザー）に分けることができます。
CKBを例に取ると、SoVユーザーはネイティブ資産のCKBトークンを価値の貯蔵手段として使用し、一方でユーティリティユーザーはCellを使用して状態を保存します。SoVユーザーは、CKBトークンのインフレによる価格の希釈を排除し、一方でユーティリティユーザーはマイナーに状態の保管料を支払わなければならず、この料金はデータの保管期間と使用空間に比例します。
**私たちはネットワークで継続的に新しいCKBトークンを発行し、固定のインフレ率を生み出し、それをマイナーに支払います。**これは実質的には、ユーティリティユーザーの手持ちトークン価値の希釈に等しい（これはCKB経済モデルの3つの発行モードの1つである「二次発行」で、この方法では毎年134.4億枚のCKBトークンが固定で発行されます。詳細は「Stable++解読：RGB++ Layer初の安定通貨プロトコルが正式にスタート」をご覧ください）。
このプロセスでは、SoVユーザーの資産も希釈されるため、インフレの損失を相殺するために一定の補助金を提供することができます（これが後のNervosDAOの分配です）。つまり、マイナーがCKBのインフレから得る利益は、実際にはユーティリティユーザーによって支払われます。まもなく、CKBのトークンエコノミクス論文を発行し、関連する問題を詳しく説明します。
このようなトークノミクスの設計に基づいて、CKBチェーン上に取引がなくても、マイナーは報酬を受け取ることができ、その結果、どんな“バリューストレージ層”またはLayer2とも互換性があります。以上より、意図的な固定インフレによってLayer1の飢餓問題を解決します。
3. 暗号プリミティブの欠如
ユーザーは異なる暗号化プリミティブを必要とし、異なる暗号化方式や異なる署名アルゴリズム（例：Schnorr、BLSなど）を使用する必要があります。
Layer1ブロックチェーンとして存在するためには、Layer2との相互運用性を考慮する必要があります。 Ethereumコミュニティでは、ZKまたはPlasmaを使用してLayer2を実現する提案がありますが、Layer1での検証をどのように行うのか、ZKに関連するプリミティブがない場合はどうすればよいでしょうか？
また、**Layer1は他のLayer1との相互運用性も考慮する必要があります。**イーサリアムを例にとると、EVM互換のオペコードとしてBlake2bハッシュ関数を事前にコンパイルするようにイーサリアムチームに要求する人もいます。この提案の目的は、Zcashとイーサリアムをブリッジすることで、ユーザーが両者間で取引できるようにすることです。このような提案は2年前に提出されましたが、現在でも実現されていません。その理由は、対応するブリッジング原語が不足しているため、これがLayer1の発展に深刻な障害をもたらしています。
この問題を解決するために、CKBは高度に抽象化された仮想マシン、すなわちCKB-VMを構築しました。これはBTCの仮想マシンやEVMとはまったく異なります。例えば、BTCには専用のOP_CHECKSIGオペコードがあり、secp256k1署名を検証するために使用されます。一方、CKB-VMでは、secp256k1署名を特別な処理する必要はなく、ユーザー定義のスクリプトやスマートコントラクトで検証できます。
CKBは、デフォルトで署名アルゴリズムとしてsecp256k1を使用していますが、ハードコードされた暗号化プリミティブではなく、CKB-VMで実行されています。
CKBの仮想マシンを構築する最初の動機は、EVMなどの他の仮想マシンでの暗号化プリミティブの実行が非常に遅いため、この状況を改善する必要があるためです。単一のsecp256k1署名のEVMでの検証には約9ミリ秒かかりますが、同じアルゴリズムを使用してCKB-VMで計算すると、1ミリ秒しかかかりません。これはほぼ10倍の効率向上です。
そのため、CKB-VMの価値は、ユーザーがカスタム暗号化プリミティブを定義できるようになったことにあります。そして、ほとんどのものがCKB-VMと互換性があります。なぜなら、CKB-VMはRISC-V命令セットを採用しており、GCC（GNU Compiler Collection、広く使用されているコンパイラのセット）でコンパイルされた言語ならばどれもCKB上で実行できるからです。
また、CKB-VMの高い互換性はCKBのセキュリティを向上させています。開発者は常に言います"自分自身で暗号化アルゴリズムのバージョンを実装しないでください、常に間違えるでしょう"。自分で暗号化アルゴリズムを定義すると、予測不能なセキュリティリスクをもたらすことがよくあります。
要納めると、CKBネットワークはさまざまな方法を使用して、私が提起したL1ネットワークが直面する3つの問題を解決しました。これがなぜCKBが適格なLayer1ネットワークと呼ばれる理由です。