ブロックチェーンの状態爆発のジレンマ

副題

レイヤ 1 は状態に焦点を当てる必要があります

ブロックチェーンの階層化が将来の開発の方向性であると信じる場合、最初から上位層のプロトコルと階層化されたネットワークのニーズを考慮し、階層化されたフレームワークでブロックチェーン プロトコルを設計する必要があります。

言い換えれば、階層的な観点から見ると、既存のブロックチェーン設計は時代遅れです。既存のブロックチェーンは、特定の機能 (支払いや DApps の実行など) を念頭に置いて設計されており、一定期間の運用後に上位層のプロトコルが適応することを期待しています。しかし、インターネットの歴史を読めば、今日のインターネットのプロトコル階層化はこのように修正されたものではなく、過去の経験を吸収した後に行われていることがわかります。これが、ブロックチェーンが本来的にレイヤー 1 ではなく、レイヤー 1 を設計する必要がある理由です。

レイヤ 1 が何に焦点を当てるべきかを理解するには、まずレイヤ 1 と上位レイヤ プロトコルの違いを理解する必要があります。レイヤー 2 の起源は、パブリック チェーン (ここではパーミッションレス ブロックチェーンを指します) のパフォーマンスが不十分であり、暗号化経済全体のニーズを満たすように拡張することが難しいという発見に関連しています。決済チャネル、プラズマなど、ブロックチェーンで保護できる 2 つのプロトコル

これらのプロトコルの共通の特徴は、パフォーマンスと引き換えにコンセンサス範囲を犠牲にすることです。パブリック チェーンの最も驚くべき点は、オープン ネットワークを通じて世界中をカバーする中断のないサービスを提供していることです。これは、世界的なコンセンサスと低パフォーマンスを意味します。

この問題を解決する最善の方法は、ほとんどのトランザクションを、コンセンサス範囲は小さいがパフォーマンスが高い上位層プロトコルに転送し、上位層プロトコルの参加者がいつでもブロックチェーンに戻って問題を解決できるようにすることです。不満がある場合、コストは時間コストだけです。

副題

ステータスは何ですか

ブロックチェーン ネットワーク内のすべてのフル ノードは、ネットワーク内で一定期間実行された後、ローカル ストレージにデータを残しますが、履歴と現在に従って 2 つのカテゴリに分類できます。

ブロックチェーン ネットワーク内のすべてのフル ノードは、ネットワーク内で一定期間実行された後、ローカル ストレージにデータを残しますが、履歴と現在に従って 2 つのカテゴリに分類できます。

履歴: ブロック データとトランザクション データは両方とも履歴であり、履歴はジェネシスから現在の状態までのパスです。

状態 (つまり、現在): ジェネシスから現在の高さまでのすべてのブロックとトランザクションを処理した後にノードによって形成される最終結果。状態はブロックの追加によって常に変化しており、その変化の原因となるのがトランザクションです。

コンセンサス プロトコルの役割は、一連のメッセージ交換を通じて各ノードから見える現在の状態が同じであることを保証することであり、この目標を達成する方法は、各ノードから見える履歴が同じであることを保証することです。履歴が同じである限り (つまり、すべてのトランザクションの順序が同じである限り)、トランザクションの処理方法も同じであり (同じ決定論的な仮想マシンでトランザクションを実行する)、最後に見られる現在の状態も同じです。同じです。 「ブロックチェーンが不変である」というのは、ブロックチェーンの歴史は改ざんできない、逆に状態は常に変化しているということを意味します。

副題

例: ビットコインの歴史と現状

ビットコインの状態とは、ビットコイン台帳の現在の状態を指します。ビットコインの状態は UTXO (まだ使用されていないトランザクション出力) で構成され、各 UTXO は一定量のビットコインを表し、この UTXO の所有者が誰であるかを記録するために名前 (scriptPubkey) が各 UTXO に書き込まれます。たとえるなら、ビットコインの現状は、所有者の名前が刻まれた金貨が詰まった袋のようなものです。

ビットコインの歴史は一連のトランザクションで構成されており、トランザクション内の主な構造は入力と出力です。トランザクションは、現在の状態に含まれる一部の UTXO (トランザクション入力によって参照されるもの) を使用済みとしてマークし、それらを UTXO セットから削除し、いくつかの新しい UTXO (このトランザクションの出力) を UTXO セットに追加することによって状態を変更します。

ビットコイン トランザクションの出力 (TXO、トランザクション出力) はまさに上記の UTXO であり、UTXO は特別な段階 (まだ使用されていない) の TXO にすぎないことがわかります。なぜなら、ビットコインの状態（UTXO）を構成するコンポーネントは、トランザクション（TXO）を構成するコンポーネントでもあるからです。

したがって、ビットコインには素晴らしい特性があります。つまり、いつでも状態は履歴のサブセットであり、履歴と状態に含まれるデータ型は同じ次元です。トランザクションの履歴 (すべてのパッケージ化されたトランザクションのコレクション、つまり、生成されたすべての TXO のコレクション) は状態の履歴 (各ブロックに対応する UTXO のコレクション。これは、生成されたすべての TXO のコレクションでもあります) です。ビットコインの歴史 トランザクションのみが含まれます。

副題

別の例: イーサリアムの歴史と現状

「世界の状態」としても知られるイーサリアムの状態は、イーサリアム台帳の現在の状態を指します。イーサリアムの状態はアカウント（アカウントは葉）から構成されるマークルツリーであり、アカウントには残高（一定量のイーサを表す）だけでなく、契約データ（暗号化された各猫のデータなど）も記録されます。イーサリアムの状態は大きな台帳とみなすことができ、台帳の 1 列目は名前、2 列目は残高、3 列目は契約データです。

イーサリアムの歴史もトランザクションで構成されており、トランザクション内の主な構造は次のとおりです。

to: トランザクションの送信者を表す別のアカウント

value: トランザクションによって運ばれるイーサの量

データ: トランザクションによって運ばれるあらゆる情報

トランザクションの状態が変化する方法は、EVM がトランザクションの送信先のターゲット アカウントを見つけることです。

1. 取引額に応じて対象口座の新しい残高を計算します。

2. トランザクションによって運ばれるデータをパラメータとしてターゲットアカウントのスマートコントラクトに渡し、スマートコントラクトのロジックを実行し、操作中にアカウントの内部状態を変更して新しい状態を生成する可能性があります。

3. 新しいリーフを構築して新しい状態を保存し、状態のマークル ツリーを更新します。

イーサリアムの歴史と取引構造はビットコインと比べて大きく異なることがわかります。イーサリアムの状態はアカウントで構成され、トランザクションはアカウントの変更をトリガーする情報で構成されます。状態とトランザクションはまったく異なる種類のデータを記録します。両者の間にはスーパーセットとサブセットの関係はありません。履歴と状態には次のデータ型が含まれます。は 2 次元であり、トランザクション履歴のサイズと状態のサイズの間には必然的な関係はありません。

トランザクションが状態を変更すると、新しい状態 (図の実線ボックス内) が生成されるだけでなく、古い状態 (図内点線ボックス内) も履歴状態として残されます。イーサリアムの歴史にはトランザクションだけでなく、過去の状態も含まれます。

履歴と状態は異なる次元に属しているため、イーサリアム ブロック ヘッダーにはトランザクションのマークル ルートが含まれるだけでなく、状態のマークル ルートも明示的に含まれる必要があります。

Ethereum のすべてのブロックとすべてのアカウントは、引き続きノードのストレージ領域を占有します。 Ethereum ノードには同期時に複数のモードがあります。アーカイブ モードでは、履歴トランザクションと履歴ステータスを含むすべての履歴とステータスが保存されます。すべてのデータの合計サイズは 2TB を超えます。デフォルト モードでは、履歴ステータスは切断されます。トランザクション履歴と現在の状態のみがローカルに保持され、データの総量は約 170G、そのうちトランザクション履歴のサイズは 150G、現在の状態のサイズは 10G です。

イーサリアムのすべてのオーバーヘッド管理はガス課金モデルに統一されており、トランザクションのサイズには対応するガスを消費する必要があり、各 EVM 命令によって消費されるガスには、コンピューティング オーバーヘッドだけでなく、ストレージ オーバーヘッドも考慮されます。各ブロックのガス制限を通じて、履歴と状態の成長率が間接的に制限されます。

ps. よくある誤解は、イーサリアムの「ブロックチェーンサイズ」が1Tを超えているということです。上記の分析から、「ブロックチェーンのサイズ」という定義は非常に曖昧であることがわかります。履歴状態をカウントすると確かに超過しますが、すべてのノードについて、履歴状態を削除しても問題はありません。 Genesis とトランザクション履歴があり、いつでも履歴状態を再計算できます (計算に必要な時間に関係なく)。

本当に意味のあるデータとは、フルノードに必要なデータのサイズです。ビットコインは 200G、イーサリアムは 170G です。この 2 つは基本的に同じであり、平均的に構成されたクラウド ホストにインストールできます。削減はストレージの増加によるものではありません。 (根本的な原因は同期時の計算オーバーヘッドです)。

副題

（ストレージ）コモンズの悲劇: コモンズの悲劇のブロックチェーン版

コモンズの悲劇とは、限られた共有資源が人々によって無制限に使用され過剰に消費される状況を指します。履歴と状態を保存するためにブロックチェーン ノードによって支払われるストレージは、まさにそのような共有リソースです。

トランザクションを処理するためにブロックチェーン ノードが消費するリソースには、CPU、ストレージ、ネットワーク帯域幅の 3 種類があります。 CPU と帯域幅は両方ともブロックごとに更新されるリソースです。各ブロック間隔で使用できる CPU と帯域幅は同じ量であると考えることができます。前のブロックで消費された CPU と帯域幅によって、次のブロックがそれより少なくなることはありません。ブロックに利用可能な CPU と帯域幅。更新可能なリソースの場合、トランザクション手数料の 1 回限りの支払いを通じてノードを補償できます (手数料と計算の複雑さおよびトランザクション サイズの相関関係については、RFC0015 付録を参照してください)。

CPU や帯域幅とは異なり、ストレージは占有されたリソースであり、ブロック内で占有されているストレージは、ユーザーが積極的に解放しない限り、後続のブロックで他のユーザーが使用することはできません。ノードはストレージの料金を継続的に支払う必要がありますが、ユーザーはストレージの料金を継続的に支払う必要はありません (トランザクション料金を支払う必要があるのは 1 回だけであることに注意してください)。

ユーザーは、ブロックチェーンにデータを書き込むときに少額の料金を支払うだけで、Amazon S3 を超える可用性を持つストレージを永続的に使用できます。その無限の永続ストレージのコストは、ブロックチェーン ネットワーク内のすべてのフル ノードが負担する必要があります。

イーサリアム上にはさまざまなDAppsが存在するため、（ストレージ）コモンズの悲劇は比較的深刻です。たとえば、ブロック 5700001 (2018 年 5 月 30 日) の時点で、最も使用されている 5 つの契約は次のとおりです。

• EtherDelta,     5.09%

• IDEX,     4.17%

• CryptoKitties,     3.05%

• ENS,     1.92%

• EOS Sale, 1.73%

さらに興味深いのは最後の EOS セールです。 EOS クラウドファンディングは完了し、EOS トークンは EOS チェーン上で流通しましたが、EOS クラウドファンディングの記録はイーサリアム ノード上に永久に残り、イーサリアム ノード全体のストレージ リソースを消費します。

状態爆発

状態爆発

ハードウェアの平均レベルの向上が、歴史やステータスの蓄積速度を超える可能性はあるのでしょうか？私の答えは非常にありそうにありません。

ハードウェアの平均レベルの向上が、歴史やステータスの蓄積速度を超える可能性はあるのでしょうか？私の答えは非常にありそうにありません。

このグラフから、イーサリアム ネットワークが発展するにつれて、蓄積される状態データの量が指数関数的に増加していることがわかります。ビットコインのステータスデータが0から3Gまで蓄積するのに10年かかった、イーサリアムのステータスデータが0から10Gまで蓄積するのに4年かかった、これはスケーラビリティの問題が解決される前のことであり、ブロックチェーンはまだニッチなテクノロジーのケースの成長率。

スケーラビリティの問題を解決すると、ブロックチェーンが実際に大量に採用され、DApps とユーザーの数が爆発的に増加します。ブロックチェーンの履歴とステータス データはどのくらいの速度で蓄積されるでしょうか?

これは状態爆発問題であり、スケーラビリティ問題を解決すると非常に明らかになるため、スケーラビリティ後の問題として分類されます。私たちがこの問題に初めて気づいたのは、ライセンス チェーンのシナリオに取り組んでいたときでした。ライセンス チェーンのパフォーマンスはパブリック チェーンのパフォーマンスよりもはるかに高く、ちょうどスケーラビリティ後の段階にあるためです。

履歴データの蓄積は比較的扱いが簡単です。将来的には、分散型チェックポイントやゼロ知識証明などのテクノロジーによって圧縮できるようになります。それ以前は、フル ノードは履歴を直接破棄して正常に動作することもできます。状態データの蓄積は、フルノードの動作に必要なデータであるため、非常に面倒です。

多くのブロックチェーン プロジェクトがこの問題を認識し、いくつかの解決策を提案しています。 EOS RAM は、状態爆発の問題を解決するための有用な試みです。RAM は、アカウント、コントラクト状態、コードのいずれであっても、スーパー ノード サーバーが利用できるメモリ リソースを表し、実行するには一定量の RAM を占有する必要があります。

RAM の設計にも多くの問題があります。内蔵取引市場を通じて購入する必要があります。譲渡不可でレンタルもできません。契約実行中の短期メモリ要件と長期ストレージ要件が混在しています。コントラクト状態の影響を受け、RAM の総量が設定されますが、明確なルールはなく、コンセンサス スペースのコストよりも、スーパーノードが許容できるハードウェア構成に依存します。

イーサリアム コミュニティもこの問題を認識し、ストレージ レント ソリューションを提案しました: ユーザーは、ストレージ リソースの使用に対して前払いでレントを支払う必要があります。ストレージ リソースを占有すると、このレントが消費され続けます。占有時間が長くなるにつれて、レントは消費されます。ユーザーはもっと支払う必要があります。 Storage Rent ソリューションには 2 つの問題があります。

1. 前払い家賃はいつか使い切ってしまいますが、この時の入居状況はどうすればよいですか？この問題を解決するには、Storage Rent にはリカバリなどのメカニズムが必要ですが、これにより設計が複雑になり、スマート コントラクトの不変性が大幅に低下し、ユーザー エクスペリエンスに問題が生じます。

2. イーサリアムの状態モデルは共有状態モデルであり、ファーストクラス状態ではありません。 ERC20Token を例にとると、すべてのユーザー資産記録は単一の ERC20 契約のストレージに保存されますが、この場合、誰が家賃を支払うべきでしょうか?

状態爆発の問題を解決することも Nervos CKB の設計目標の 1 つであるため、私たちはまったく異なる、より根本的な変更の道を選択しました。つまり、Nervos CKB では、トークンはストレージ容量の単位を表し、経済モデルの設計を通じて、世界国家の規模を制限し、市場手段を使用して国家ストレージの需要と供給を調整し、継続的に提供します。手数料は、長期的な安全性と永続的な安定性を達成するために、エコロジー内のすべての関係者の利益を調整するために使用されます。