州
ブロックチェーン ネットワーク内のすべてのフル ノードは、ネットワーク内で一定期間実行された後、ローカル ストレージにデータを残しますが、履歴と現在に従って 2 つのカテゴリに分類できます。
履歴 — ブロック データとトランザクション データは両方とも履歴であり、履歴はジェネシスから現在の状態までのパスです。
ステータス (つまり、現在) - ノードは Genesis からの処理を終了しました
現在の高さまでのすべてのブロックとトランザクションの後に形成された最終結果。状態はブロックの追加によって常に変化しており、その変化の原因となるのがトランザクションです。
コンセンサス プロトコルの役割は、一連のメッセージ交換を通じて各ノードから見える現在の状態が同じであることを保証することであり、この目標を達成する方法は、各ノードから見える履歴が同じであることを保証することです。履歴が同じである限り (つまり、すべてのトランザクションの順序が同じである限り)、トランザクションの処理方法も同じであり (同じ決定論的な仮想マシンでトランザクションを実行する)、最後に見られる現在の状態も同じです。同じです。 「ブロックチェーンが不変である」というのは、ブロックチェーンの歴史は改ざんできないという意味であり、逆に状態は常に変化しているということです。
興味深いことに、異なるブロックチェーンは異なる方法で履歴と状態を保存し、その違いにより異なるブロックチェーンが独自の特性を形成します。この記事で説明するトピックは状態であり、状態に影響を与える履歴データは主に (ブロック ヘッダーではなく) トランザクションであるため、履歴に関する次の説明は次のとおりです。トランザクションに焦点を当てる副題
例: ビットコインの歴史と現状
ビットコインの状態とは、ビットコイン台帳の現在の状態を指します。ビットコインの状態は UTXO (まだ使用されていないトランザクション出力) で構成され、各 UTXO は一定量のビットコインを表し、各 UTXO には名前 (scriptPubkey) が書き込まれ、この UTXO の所有者が誰であるかを記録します。たとえるなら、ビットコインの現状は、所有者の名前が刻まれた金貨が詰まった袋のようなものです。
ビットコインの歴史は一連のトランザクションで構成されており、トランザクション内の主な構造は入力と出力です。トランザクションは、現在の状態に含まれる一部の UTXO (トランザクション入力によって参照されるもの) を使用済みとしてマークし、それらを UTXO セットから削除し、いくつかの新しい UTXO (このトランザクションの出力) を UTXO セットに追加することによって状態を変更します。
ビットコイン トランザクションの出力 (TXO、トランザクション出力) はまさに上記の UTXO であり、UTXO は特別な段階 (まだ使用されていない) の TXO にすぎないことがわかります。なぜなら、ビットコインの状態（UTXO）を構成するコンポーネントは、トランザクション（TXO）を構成するコンポーネントでもあるからです。したがって、ビットコインには次のような素晴らしい特性があります。いかなる瞬間における状態も歴史の一部です、履歴とステータスに含まれるデータ型は同じ次元です。トランザクションの履歴 (すべてのパッケージ化されたトランザクションのコレクション、つまり、生成されたすべての TXO のコレクション) は状態の履歴 (各ブロックに対応する UTXO のコレクション。これは、生成されたすべての TXO のコレクションでもあります) です。ビットコインの歴史 トランザクションのみが含まれます。
ビットコイン ネットワークでは、各ブロックと各 UTXO がノードのストレージ スペースを占有し続けます。現在のところビットコインの歴史全体のサイズ（すべてのブロックを合計したサイズ）は約200G、そして状態のサイズはわずか約 3G (約 5,000 万個の UTXO で構成される)副題
別の例: イーサリアムの歴史と状態
「世界状態」としても知られるイーサリアムの状態は、イーサリアム台帳の現在の状態を指します。イーサリアムの状態はアカウント（アカウントは葉）から構成されるマークルツリーであり、アカウントには残高（一定量のイーサを表す）が記録されるだけでなく、契約のデータ（暗号化された各猫のデータなど）も記録されます）。イーサリアムの状態は大きな台帳とみなすことができ、台帳の 1 列目は名前、2 列目は残高、3 列目は契約データです。
イーサリアムの歴史もトランザクションで構成されており、トランザクション内の主な構造は次のとおりです。
to - トランザクションの送信者を表す別のアカウント
value - トランザクションによって運ばれるイーサの量
data - トランザクションによって運ばれる任意の情報
トランザクションの状態が変化する方法は、EVM がトランザクションの送信先のアカウントを見つけることです。
1. 取引額に応じて対象口座の新しい残高を計算します。
2. トランザクションによって運ばれるデータをパラメータとしてターゲットアカウントのスマートコントラクトに渡し、スマートコントラクトのロジックを実行し、操作中にアカウントの内部状態を変更して新しい状態を生成する可能性があります。
3. 新しいリーフを構築して新しい状態を保存し、状態のマークル ツリーを更新します。
イーサリアムの歴史と取引構造はビットコインと比べて大きく異なることがわかります。イーサリアムの状態はアカウントで構成され、トランザクションはアカウントの変更をトリガーする情報で構成されます。状態とトランザクションはまったく異なる種類のデータを記録します。両者の間にはスーパーセットとサブセットの関係はありません。履歴とステータスに含まれるデータ型は 2 次元です、トランザクション履歴のサイズと状態のサイズの間には必要な関係はありません。トランザクションが状態を変更すると、新しい状態 (図の実線ボックス内) が生成されるだけでなく、古い状態 (図内点線ボックス内) も履歴状態として残されます。イーサリアムの歴史にはトランザクションだけでなく、過去の状態も含まれます。履歴と状態は異なる次元に属しているため、イーサリアム ブロック ヘッダーにはトランザクションのマークル ルートが含まれるだけでなく、状態のマークル ルートも明示的に含まれる必要があります。 (考えられる質問: EOS はイーサリアムに似たアカウント モデルを使用していますが、ブロック ヘッダーに状態マークル ツリー ルートが含まれていません。これは良いことですか、それとも悪いことですか?)
Ethereum のすべてのブロックとすべてのアカウントは、引き続きノードのストレージ領域を占有します。 Ethereum ノードには同期時に複数のモードがあります。アーカイブ モードでは、すべての履歴と状態が保存されます。履歴には、履歴トランザクションと履歴状態が含まれます。すべてのデータの合計サイズが 2TB を超える; デフォルト モードでは、履歴状態はトリミングされ、履歴トランザクションと現在の状態のみがローカルに保持されます。すべてのデータを合計すると約 170G になります、でトランザクション履歴のサイズは 150G、現在の状態のサイズは 10G。イーサリアムのすべてのオーバーヘッド管理はガス課金モデルに統一されており、トランザクションのサイズには対応するガスを消費する必要があり、各 EVM 命令によって消費されるガスには、コンピューティング オーバーヘッドだけでなく、ストレージ オーバーヘッドも考慮されます。各ブロックのガス制限を通じて、履歴と状態の成長率が間接的に制限されます。
ps. よくある誤解は、イーサリアムの「ブロックチェーンサイズ」が1Tを超えているということです。上記の分析から、「ブロックチェーンのサイズ」は非常に曖昧な定義であることがわかります。履歴状態を含めるとそれを超えますが、すべてのノードについて履歴状態を削除しても問題はありません。 Genesis とトランザクション履歴があり、いつでも履歴状態を再計算できます (計算に必要な時間に関係なく)。本当に意味のあるデータは、フルノードに必要なデータのサイズです。ビットコインは 200G、イーサリアムは 170G、この 2 つは基本的に同じであり、平均的に構成されたクラウド ホストにインストールできます。ノードの削減は、次のような理由によるものではありません。ストレージの増加 (根本的な原因は同期中の計算オーバーヘッドですが、ここでは詳しく説明しません)。イーサリアムの歴史の長さ (現在のブロックのタイムスタンプから生成時のタイムスタンプを引いたもの) がビットコインの半分未満であることを考慮すると、イーサリアムの歴史と状態のサイズがより速く成長していることがわかります。
（ストレージ）コモンズの悲劇: コモンズの悲劇のブロックチェーン版
コモンズの悲劇とは、有限な共有資源が、その使用に何の制限もなく人々によって過剰に消費される状況を指します。履歴と状態を保存するためにブロックチェーン ノードによって支払われるストレージは、まさにそのような共有リソースです。
トランザクションを処理するためにブロックチェーン ノードが消費するリソースには、CPU、ストレージ、ネットワーク帯域幅の 3 種類があります。 CPU と帯域幅は、各ブロックで更新されるリソースです。各ブロック間隔で利用できる CPU と帯域幅は同じ量であると考えることができます。前のブロックで消費された CPU と帯域幅によって、次のブロックの CPU が減少することはありません。チャンクに利用可能な帯域幅。更新可能なリソースについては、トランザクション手数料の 1 回限りの支払いでノードを補うことができます。
CPU や帯域幅とは異なり、ストレージは占有されたリソースであり、ブロック内で占有されていたストレージは、ユーザーが積極的に解放しない限り、後続のブロックで他のユーザーが使用することはできません。ノードはストレージの料金を継続的に支払う必要がありますが、ユーザーはストレージの料金を継続的に支払う必要はありません (トランザクション料金を支払う必要があるのは 1 回だけであることに注意してください)。ユーザーは、ブロックチェーンにデータを書き込むときに少額の料金を支払うだけで済み、Amazon S3 を超える可用性を持つストレージを永続的に使用できます。また、その無限の永続ストレージのコストは、ブロックチェーン ネットワーク内のすべてのフル ノードが負担する必要があります。
イーサリアム上にはさまざまなDAppsが存在するため、（ストレージ）コモンズの悲劇は比較的深刻です。たとえば、ブロック 5700001 (2018 年 5 月 30 日) では、最も使用されている州との 5 つの契約はい：
1.EtherDelta, 5.09%
2.IDEX, 4.17%
3.CryptoKitties, 3.05%
4.ENS, 1.92%
5.EOS Sale, 1.73%
さらに興味深いのは最後の EOS セールです。 EOS クラウドファンディングは完了し、EOS トークンは EOS チェーン上で流通しましたが、EOS クラウドファンディングの記録はイーサリアム ノード上に永久に残り、イーサリアム ノード全体のストレージ リソースを消費します。
管理がなければ、ブロックチェーンのストレージ リソースが意図的または非意図的に乱用されることがわかります。適切に設計された経済モデルでは、ユーザーはストレージ占有のコストを負担しなければなりません。副題。
状態爆発
履歴データと状態データはどちらもストレージ リソースを消費します。ビットコインとイーサリアム（他のブロックチェーンの状態モデルは基本的にこの 2 つのうちの 1 つとして要約できます）の上記の分析を通じて、それらは歴史と状態の成長を管理するものの、全体的な歴史と状態を制御できないことがわかります。これらのデータは際限なく蓄積され続けるため、完全なノードを実行するために必要なストレージ リソースがますます大きくなります。フルノードの動作しきい値を上げると、ネットワークの分散性がますます低下しますが、これは望ましくないことです。
ハードウェアの平均レベルの向上が、歴史やステータスの蓄積速度を超える可能性はあるのでしょうか？私の答えは非常にありそうにありません。
このグラフから、イーサリアム ネットワークが発展するにつれて、蓄積される状態データの量が指数関数的に増加していることがわかります。ビットコインのステータスデータが0から3Gまで蓄積するのに10年かかった、イーサリアムのステータスデータが0から10Gまで蓄積するのに4年かかった、これはスケーラビリティの問題が解決される前のことであり、ブロックチェーンはまだニッチなテクノロジーのケースの成長率。スケーラビリティの問題を解決し、ブロックチェーンが実際に大量に採用され、DApp とユーザーの数が爆発的に増加したとき、ブロックチェーンの履歴とステータス データはどのくらいの速度で蓄積されるでしょうか?
これは状態爆発問題であり、スケーラビリティ問題を解決すると非常に明らかになるため、スケーラビリティ後の問題として分類されます。私たちがこの問題に初めて気づいたのは、ライセンス チェーン シナリオを実装したときでした。許可型チェーンのパフォーマンスはパブリック チェーンのパフォーマンスよりもはるかに高い、ちょうどポストスケーラビリティの段階にあります。 (考えられる質問: 権限チェーンは状態爆発の問題をどのように解決しますか?)
履歴データの蓄積は比較的扱いが簡単です。将来的には、分散型チェックポイントやゼロ知識証明などのテクノロジーによって圧縮できるようになります。それ以前は、フル ノードは履歴を直接破棄して正常に動作することもできます。状態データの蓄積は、フルノードの動作に必要なデータであるため、非常に面倒です。
多くのブロックチェーン プロジェクトがこの問題を認識し、いくつかの解決策を提案しています。 EOS RAM は、状態爆発の問題を解決するための有用な試みです。RAM は、アカウント、コントラクト状態、コードのいずれであっても、スーパー ノード サーバーが利用できるメモリ リソースを表し、実行するには一定量の RAM を占有する必要があります。 RAM の設計にも多くの問題があります。内蔵取引市場を通じて購入する必要があります。譲渡不可でレンタルもできません。契約実行中の短期メモリ要件と長期ストレージ要件が混在しています。決定されたルールは、コンセンサススペースのコストよりも、スーパーノードが耐えられるハードウェア構成に依存します。
イーサリアム コミュニティもこの問題を認識し、次のように尋ねました。Storage Rent のソリューション: ユーザーは、ストレージ リソースの使用に対して事前にレンタル料を支払う必要があります。ストレージ リソースを占有すると、継続的にこのレンタル料が消費されます。占有時間が長いほど、ユーザーはより多くのレンタル料を支払う必要があります。ストレージレンタルスキームには 2 つの問題があります。
1. 前払い家賃はいつか使い切ってしまいますが、この時の入居状況はどうすればよいですか？この問題を解決するには、Storage Rent には回復などの補完メカニズムが必要ですが、これにより設計が複雑になり、スマート コントラクトの不変性が大幅に低下し、ユーザー エクスペリエンスにも問題が生じます。
2. イーサリアムの状態モデルは共有状態のモデルであり、そうではありません。First-class State。 ERC20トークンを例にとると、すべてのユーザー資産記録は単一のERC20契約のストレージに保存されますが、この場合、誰が家賃を支払うべきでしょうか?
元のリンク:
元のリンク:https://talk.nervos.org/t/top...
IOS
Android