CKB共同クリエーター ヤン：L1飢餓問題とは何か L2とL1はどのようにデザインされるべきか？

この記事は、HBS Blockchain+Crypto Club Conference 2019でのNervosの共同クリエイターJanによるスピーチです。Layer2対Layer1の関係を中心に、モジュール型ブロックチェーンが正しい方向であることを明らかにし、ブロックチェーンのデータ保存メカニズムについて語った。同時にヤン氏は、レイヤー2の台頭によるレイヤー1の飢餓の問題をどう解決するかという興味深い話題も持ち出した。

Layer2とモジュール型ブロックチェーンの物語の最も初期の支持者の一人として、Nervosの主張は、イーサリアムコミュニティがまだシャーディングについて非現実的な幻想を抱いていた18年と19年当時は、非常に先進的であり、高性能なモノリシックチェーンの物語は流動的で、まだ十分に反証されていませんでした。

しかし2024年の今、イーサのLayer2が実際に抱えている問題や、分散化と信頼性という点でのソラナ氏の「高性能パブリックチェーン」の欠点を振り返ってみると、5年前のヤン氏の見解は先見の明があったと言えるでしょう。Layer2自体への興味から、Geek Web 3はヤンの講演のテキスト版をまとめ、イーサリアムとビットコインのコミュニティのNervosとLayer2愛好家が学び、議論できるようにここに公開した。

以下はヤンのトークの原文です。

レイヤー1とレイヤー2の定義

これは私が示したL1とL2（レイヤー2ネットワーク）の定義です。

まず強調しておきたいのは、Nerovsは分散型経済のニーズに応えようとしているブロックチェーンネットワークに過ぎず、「すべての問題」を解決する責任はないということです！".私たちが知っているレイヤー1とレイヤー2の違いは、コンセンサスの強さです。L1ネットワークは、可能な限り幅広いコンセンサス、すなわち「グローバル・コンセンサス」を持たなければなりません。無許可のグローバル・コンセンサスを通じて、世界中の誰もがL1のコンセンサス・プロセスに参加することができ、最終的にLayer1は分散型経済の「アンカー」として機能することができる。この観点から、レイヤー1を「コンセンサスレイヤー」と呼ぶことができる。

対照的に、L2ネットワークは、コンセンサスが小さく、参加者は1つの国、1つの業界、あるいは1つの企業や組織、あるいは非常に小さなコミュニティからしか参加できないかもしれません。L2のコンセンサス範囲の犠牲は、より高いTPS、より低いレイテンシ、より優れたスケーラビリティなど、他の進歩の代償です。私たちはL2を「プロトコル層」と呼ぶことができ、L1とL2はしばしばクロスチェーンブリッジで接続されています。

私たちがL2ネットワークを構築したのは、ブロックチェーンのスケーラビリティの問題を解決するためだけでなく、レイヤーアーキテクチャが「モジュラーブロックチェーン」を軌道に乗せる最も簡単な方法だからだということを強調しておくことが重要です。いわゆるモジュラー型ブロックチェーンとは、さまざまなタイプの問題を解決するために、さまざまなモジュールに入れることだ。

多くの人がブロックチェーンのコンプライアンスや規制について話していますが、ではビットコインやイーサを既存の規制の枠組みにどのように当てはめればいいのでしょうか？レイヤーアーキテクチャは、その問題に対する1つの答えかもしれません。レイヤー1レベルで規制要件に直接対応するビジネスロジックを追加すると、その分散性と中立性が損なわれる可能性があるため、コンプライアンス関連のロジックはレイヤー2で個別に実装することができます。

レイヤー2は、パーミッションベースのシステムに基づく小規模なブロックチェーンの構築や、ステートフルチャネルネットワークのようなものなど、特定の規制や標準に合わせてカスタマイズすることができます。これにより、レイヤー1の非中央集権性と中立性を損なうことなく、コンプライアンスを実現できます。

また、レイヤーアーキテクチャによって、セキュリティとユーザーエクスペリエンスの間の矛盾を解決することができます。同様に、秘密鍵の安全性を保ちたいのであれば、ある程度の利便性を犠牲にしなければなりません。ブロックチェーンも同様で、ブロックチェーンの絶対的な安全性を保証したいのであれば、そのチェーンのパフォーマンスなど、ある程度のものを犠牲にしなければなりません。

しかし、レイヤーアーキテクチャを使えば、L1ネットワークのセキュリティを完全に追求し、L2ネットワークのセキュリティを少し犠牲にして、より良いユーザーエクスペリエンスを得ることができます。たとえば、L2でステートフル・チャネルを使用して、ネットワーク・パフォーマンスを最適化し、待ち時間を減らすことができます。つまり、レイヤー2の設計は、セキュリティとユーザーエクスペリエンスのトレードオフに他ならないのです。

以上のことから、どのブロックチェーンもレイヤー1として使えるというのは本当なのか

という疑問も当然出てきます。まず第一に、Layer1ネットワークの分散化とセキュリティが何よりも重要であることを明確にしなければなりません。L1はブロックチェーン・ネットワーク全体の根源であり、暗号経済システム全体のアンカーであるため、Layer1のセキュリティの追求は基本的なものです。

このような基準の下では、ビットコインとイーサは間違いなく最も古典的なL1ネットワークであり、非常に強力なコンセンサス範囲を持っています。この2つを除けば、ほとんどのブロックチェーンはL1の基準を満たしておらず、コンセンサスの度合いも低い。例えば、EOSはコンセンサスが標準以下であり、L2ネットワークとしてしか機能しない。

現在のレイヤー1ネットワークの問題点

レイヤー1の定義を明確にした後、既存のレイヤー1ネットワークには3つの問題点があることを指摘したいと思います。

1.データストレージのコモンズの悲劇問題

私たちはブロックチェーンを利用する際、一定の手数料を支払う必要がありますが、ビットコインの経済モデルでは、手数料構造の設計は計算コストとネットワーク帯域幅コストしか考慮していません。ネットワーク帯域幅コストしか考慮されておらず、データストレージのコストは考慮されていません。

たとえば、ユーザーはチェーンにデータを保存するために一度だけお金を支払いますが、保存期間は永久なので、人々はチェーンに何でも永久にアップロードすることでストレージリソースを乱用することができ、最終的にネットワーク内の全ノードがストレージの増加コストを負担しなければなりません。これは問題を提示します：そのネットワークに参加したいノードランナーのコストは最大化されます。

あるブロックチェーンの状態/アカウントデータの合計が1テラバイトを超えると仮定すると、誰もが簡単に完全な状態と取引履歴を同期できるわけではありません。この場合、たとえ完全な状態を同期できたとしても、対応する取引履歴を自分で検証することは難しく、ブロックチェーンの最も核となる価値であるトラストフリーの性質が弱まってしまいます。

イーサネット財団はこれらの問題を認識しており、EIP-103にストレージリースの設計を含めていますが、これが最適なソリューションだとは考えていません。

私たちはNervosで「Cell」と呼ばれる新しい状態モデルを提案しますが、これはUTXOの拡張とみなすことができます。拡張である。ビットコインのUTXO状態では、ビットコインの残高値しか保存できませんが、Cellではあらゆるタイプのデータを保存でき、ビットコインのUTXO残高と整数値を「Capacity」に一般化し、Cellの最大保存容量を指定します。

このようにして、CKB上のネイティブアセット数をステートのサイズに結びつけます。どのセルも容量制限以上のスペースを占有できないため、データの総量は一定の範囲内に保たれます。

そして、より適切なトークン・インフレ率によって、状態データのサイズがノード・ランナーに干渉しないようにします。誰でもCKBネットワークに参加することができ、履歴データを検証し、また最終状態が有効であることを検証することができます。これは、ブロックチェーンにおけるストレージ問題に対するCKBの提案する解決策です。

2.レイヤー1の飢餓

レイヤー2を拡張し、レイヤー2に多くのトランザクションを置くと、必然的にレイヤー1のトランザクション数が減少し、レイヤー1のマイナー/ノードランナーの経済的報酬も減少します。それに伴い、レイヤーの経済的報酬も減少する。この場合、レイヤー1のマイナー/ノードランナーのモチベーションは低下し、最終的にレイヤー1のセキュリティの低下につながります。これがいわゆるレイヤー1の飢餓問題です。

極端な例を挙げると、すべての取引活動をL2にシフトすると、その根源であるL1は維持できなくなります。では、どうすればこれを解決できるのか？

そのためには、ブロックチェーンネットワークにどのようなユーザーがいるのかを区別する必要があります。SoVユーザー、Store of Valueユーザー)とユーティリティユーザーに分類されます。

やはりCKBを例にとると、SoVユーザーは価値を保存する手段としてネイティブアセットのCKBトークンを使用するのに対し、ユーティリティユーザーは状態を保存するためにCellを使用します。ストレージの期間とフットプリントは、データの期間とフットプリントに比例します。

私たちはネットワーク内で継続的に新しいCKBトークンを発行し、一定のインフレ率を作り出し、マイナーに支払います。これにより、ユーティリティ・ユーザーの手元にあるトークンの価値は希薄化します（これは、CKBの経済モデルにおける3つの発行モードの1つである「セカンダリー発行」であり、「Stable++を解凍する：RGB++レイヤーのための最初のstablecoinプロトコル」の記事で説明されているように、年間13億4400万CKBトークンの固定発行です。）(詳細は「Stable++：RGB++レイヤー初の安定コイン・プロトコルが出航」を参照）。

このプロセスによってSoVユーザーの資産も希薄化したため、インフレによる損失を相殺するための補助金を与えることができました（これが後のNervosDAOシェアです）。言い換えれば、CKBのインフレによるマイナーの利益は、実際にはユーティリティ・ユーザーによってのみ支払われるのです。まもなく、私たちはCKBのトークンエコノミーペーパーを発表し、関連する問題を詳しく説明する予定です。

このトークンエコノミクスの設計に基づくと、CKBチェーン上で取引活動がない場合でもマイナーに報酬を支払うことができます。要約すると、私たちは意図的にインフレを修正することで、Layer1の飢餓問題を解決しています。

3.暗号プリミティブの欠如

ユーザーは、シュナー、BLSなど、異なる暗号化方式や異なる署名アルゴリズムを使用するために、異なる暗号プリミティブを必要とします。

レイヤー1のブロックチェーンであるためには、レイヤー2とどのように相互運用するかを考えなければなりません。イーサリアムコミュニティの中には、レイヤー2を実装する方法としてZKやPlasmaを使うことを提案している人もいますが、ZK関連のプリミティブがないレイヤー1でどうやって認証を行うのでしょうか？

また、レイヤー1は他のレイヤー1との相互運用性を考慮しなければなりません。まだイーサネットの例を使いますが、イーサネットチームに対して、Blake2bハッシュ関数をEVM互換のオペコードにプリコンパイルするよう要求がありました。この提案の目的は、ZcashとEtherを橋渡しし、ユーザーが両者間で取引できるようにすることである。上記の提案は2年前に行われましたが、対応する暗号プリミティブがないため、Layer1の開発にとって深刻な障害となっており、まだ実現していません。

この問題を解決するために、CKBは高度に抽象化された仮想マシンであるCKB-VMを構築しました。CKB-VMはBitcoin VMやEVMとは大きく異なります。例として、ビットコインには、ビットコイン取引のsecp256k1署名を検証するための特別なOP_CHECKSIGオペコードがあります。一方、CKB-VMでは、secp256k1署名は特別な処理を必要とせず、ユーザー定義のスクリプトまたはスマートコントラクトだけで検証できる。

CKBもデフォルトの署名アルゴリズムとしてsecp256k1を使用していますが、ハードコードされた暗号プリミティブとしてではなく、CKB-VMで実行される点が異なります。

CKBは、EVMのような他のVMで暗号プリミティブを実行すると非常に時間がかかるため、状況を改善することを当初の目的としてVMを構築した。1つのsecp256k1署名の検証に、EVMではおよそ9ミリ秒かかりますが、CKB-VMでは同じアルゴリズムを使って計算しても1ミリ秒しかかかりません。

CKB-VM の価値は、ユーザーが暗号プリミティブをカスタマイズできるようになったことです。CKB-VMはRISC-V命令セットを使用し、GCC（GNU Compiler Collectio、広く使用されているコンパイラ・コレクション）によってコンパイルされた言語はすべてCKB上で動作します。

さらに、CKB-VMの高い互換性はCKBのセキュリティを強化します。開発者がいつも言っているように、「暗号アルゴリズムの独自のバージョンを実装しないでください。

まとめると、CKBネットワークは、私がL1ネットワークについて提案した3つの問題を解決するためにさまざまな方法を使用しています。