ポピュラーサイエンス: データの可用性の問題
画像の説明
-はい...そのガス料金で取引を完了するには数日かかります-
Ethercat は、大規模な成功を収めた最初の分散アプリケーションです。しかし、それ (および他のアプリケーション) はイーサリアム ネットワークのすべてのリソースを奪い、チェーンのメモリプールが前例のない速度で増大する原因となりました。一夜にして、人々はスケーリング問題の解決策としてプラズマとステートチャネルについて話し始めました。しかし、議論と興奮にもかかわらず、これらのソリューションの開発は苦戦しており、一部のコミュニティメンバーはその実現可能性を疑問視しています。しかし現在、これらのソリューションが徐々にオンラインになるにつれて、人々は長い間開発者を悩ませてきた本当の問題は明白なデータ可用性の問題であることに気づきました。
副題
データの可用性の問題
Vitalik が以前に説明したように、データ可用性の問題の原因は、悪意のあるマイナーがブロック ヘッダーを持つブロックを公開しようとしたものの、データの一部またはすべてがチェーンに失われてしまうことにあります。この攻撃により、次のような結果が生じる可能性があります。
ネットワークをだまして無効なブロックを受け入れさせますが、ブロックの無効性を証明する方法はありません。
ノードが現在の状態を取得できないようにします。
証明を構築するための対応する情報が欠如しているため、ノードがブロックを作成したり資金を送金したりできないようにします。
しかし、データの可用性はブロック データを隠すことだけではありません。一般に、一部のデータが一部のアクター (レビュー メカニズムとも呼ばれる) によるアクセスから隠蔽されている限り、それはデータの可用性の問題と呼ぶことができます。私たちが知る限り、これはメインネットでは問題ではありませんが、非常に高価でもあります。実際、過去 18 か月間で、各イーサリアム ノードに保存される状態の量が 6.5 倍に増加しました (高速同期をオンにした geth ソフトウェアを使用)。
明らかに、これは真の分散型 Web にとって持続可能ではありません。ブロックチェーンのサイズが拡大し続けるにつれて、ネットワークに参加してノードとして機能できるコンピューターの数は減少し続けます。では、この状況にどう対処すればよいのでしょうか?
例例
ポーカーをするためにカジノに行くとします。最初に、ドルをポーカー チップに交換するためにカウンターに行きます (このプロセスはオンチェーン トランザクションであると考えてください)。その後、テーブルに座ってポーカーを何時間もプレイし始めます (これらはオフチェーン トランザクションと呼ばれます)。お金を勝ち取ることもあれば、お金を失うこともあります。ビッグハンドで勝った後、チップを現金化したいことをハウスに伝えます。
しかし、起きた後、誰かがあなたの頭の後ろに樹液を与えます - あなたはぼんやりとした記憶で目覚め、ポーカーハンドの詳細を思い出せません（それは「データが利用できません」です）。あなたがそこにいないとき、ポーカー テーブルは最後のハンドが起こらなかったふりをして、そのハンドに至るまでの瞬間にプレイを続けることを決定します。つまり、あなたが勝てるはずだったお金を騙し取ることです。
副題
実際には
Plasma では、各参加者は、暗号資産が各 Plasma ブロックで取引されたかどうかを証明するために、完全な取引履歴と十分な証人データを保持する必要があります。これにより、各参加者はプラズマ システムのノードになりますが、独自のトランザクション データのみが保存されます。この要件は、Plasma では誰でもチェーンの運営者と共謀し、無効なトランザクションを送信して他人の資産を盗むことができるためです。参加者がこれを防ぐ唯一の方法は、すべての資産の完全かつ有効な取引履歴を確実に保持することです。
状態チャネルでは、すべての参加者が状態の更新 (トランザクションなど) ではなく、現在の状態についてのみ合意するため、データ要件が低くなります。これにより、取引履歴を再計算することなく、一度の取引だけで契約を決済することができます。また、各状態には自動インクリメントされるナンスがあり、スマート コントラクトは双方が署名しない限りそれを有効な状態とはみなさないため、参加者は最新の状態を保存するだけで済みます。
解決
解決
現在、関係チームは、クライアントが維持する必要があるデータ、または ZK-SNARKS や RSA アキュムレータなどを介してメインネットに送信する必要があるデータが占めるスペースを削減するためにできる限りのことを行っています。これは大きな改善ですが、それはできません。データの可用性の問題を修正できません。実際、単一のクライアントに対してこの問題を実際に解決することはできません。そのためには、そのクライアントが 100% 常にオンラインであり、そこに保存されているデータを決して失わないことが必要になるからです (ブロックチェーンによく似ていますね。 ?) 。
しかし、それを行うことができるハードウェアが存在しないことを考えると、データ可用性の問題の解決策は、奨励された監視塔ネットワーク (PISA など) または同様の構造であると広く信じられています。これらのインセンティブ付きネットワークは、実際には、料金を支払っているユーザーのデータをバックアップし、ユーザーが異議を唱えることができない（つまり、オフラインになっている）場合に、ユーザーに代わって疑わしい取引に異議を申し立てる、杭打ち監視塔のグループです。一定の時間内にチャレンジに異議を唱えられなかった場合、その賭け金は失われ、その賭け金はチャレンジに参加したネットワーク内の新しい監視塔に与えられます (実際にチャレンジを提出したと仮定します)。このバグ/予約プロトコルには複数の層があるため、ユーザーはオフラインになったり、トランザクション/状態履歴が失われたりした場合でもだまされないことを確信できます。
副題
SKALEのソリューション
SKALE の弾性サイドチェーンは、ブロック提案プロセスを通じてデータ可用性の問題を解決します。バリデーターはブロック提案を作成した後、以下で説明するデータ可用性プロトコルを使用して他のバリデーターにそれを通信します。このプロトコルは、ブロック提案がバリデーターの過半数 (>2/3) に送信されることを保証します。
5 段階のプロトコルは次のように説明されます。
ブロックを送信するバリデーター A は、ブロックの提案と、提案 P を構成するすべてのトランザクションのハッシュをすべてのピアに送信します。
P と関連するハッシュ値を受信した後、対応する各ノードは、パッケージ化されるローカル トランザクション キュー内の転送とハッシュ値を照合して、P を再構築します。キュー内に転送が見つからない場合、ノードは転送を送信したバリデーター A に検索リクエストを送信します。次に、送信側バリデーター A は、これらのトランザクションの本体を受信側バリデーターに送信し、ピアがブロック提案を再構築し、それを提案ストレージ データベース PD に追加できるようにします。
その後、ノードはしきい値署名付きの受領書を A に送信します。
ノード (A 自体を含む) からノードの絶対多数 (3 分の 2 以上) の署名を収集した後、A は絶対多数の署名 S を作成します。この署名は、検証者の大多数が P を所有していることの証明として機能します。
A は、この絶対多数署名 S を他のすべての検証者にブロードキャストします。
注: 各バリデータは、BLS 秘密キー スライス PKS[I] を所有します。キー スライスの初期状態は、フェデレーテッド フェルドマン分散キー生成 (DKG) アルゴリズムを使用して実行されます。このアルゴリズムは、エラスティック サイドチェーンが作成されるとき、およびバリデーターがランダムに交換されるたびに実行されます。詳細については、BLS と DKG に関する記事をご覧ください。
要約する
要約する
全体として、過去 18 か月間、実行層のソリューションに取り組んでいる開発者が何をしていたのか疑問に思っているなら、彼らの時間のほとんどは最初はこの問題の解決に費やされた可能性があります。すべてのスケーリング問題に対する完璧な解決策はまだありませんが、多くの新しくてエキサイティングな取り組みが進行中であり、私たちは将来何を達成できるかについて非常に自信を持っています。
