モジュラーブロックチェーン: 実行、データ、決済のトレース
モジュール式ブロックチェーンは、1 つのシステムにすべてのタスクの実行を依頼するのではなく、コンポーネント間で責任を分割します。そのため、ネットワークの説明は単純に聞こえるかもしれません。実行はここで行われ、データはそこに送信され、決済は別の場所で行われます。重要な問題は、各コンポーネントが実際に何を保証するかということです。
この記事では、トークンの価格やプロジェクトのランキングではなく、アーキテクチャ上の役割を比較します。モジュラー設計は、実装全体でリスクの低下、投資収益の向上、または同一のセキュリティを自動的に意味するものではありません。
システムを比較する前に役割を分離してください
実行ではトランザクション ルールが適用され、提案された状態変更が計算されます。データの可用性は、システムを検証するために必要な情報が利用可能になっているかどうかに関係します。決済は、特定のプロトコルに基づいて状態コミットメント（state commitment）、証明、または紛争がどのように受け入れられるかに関係します。コンセンサスは、システム内で合意された順序または受け入れられた履歴を決定します。
これらの役割は、重複したり、さまざまな方法で分散したりできます。プロジェクトのラベルだけでは十分ではありません。ネットワークは、シーケンサー、アップグレード キー、またはデータ委員会で重要な制御を保持しながら、自らをモジュラーと呼ぶ場合があります。すべてのモジュラー ネットワークが 1 つの信頼モデルを共有すると仮定するのではなく、実際の依存関係マップを描画します。
イーサリアムのデータ可用性ドキュメント では、検証がトランザクション データへのアクセスに依存する理由と、ライト クライアントとロールアップに適切な保証が必要な理由が説明されています。データ アクセスは、実行された計算が正しいかどうかとは別の問題です。
仮想トランザクションを追跡する
ユーザーがトランザクションを実行ネットワークに送信すると想像してください。シーケンサーはそれをバッチに組み込みます。システムは、選択したデータ層を使用して必要なデータを利用可能にし、その設計で必要とされる検証メカニズムを備えた状態のコミットメントを決済層に送信します。
ユーザーは、各段階が最終ステータスに達する前に、早期の確認を確認できます。各ステータスの意味を記録します: 受領、順序付け、実行、データの公開、証明の受理、または紛争期間の完了。プロトコルがその解釈をサポートしない限り、最も早い確認応答を最終決済としてラベル付けしないでください。
この例では、1 つの普遍的なシーケンスを規定するのではなく、役割について説明します。異なるロールアップおよびモジュラー システムでは、ステージを組み合わせたり、異なるプルーフおよびファイナリティの取り決めを使用したりする場合があります。
コンポーネントに障害が発生した場合に何が起こるかを尋ねる
シーケンサーが停止した場合、ユーザーは別の方法で、どのような条件でトランザクションを送信できますか?データ サービスが情報を保留している場合、誰がそれを検出し、ユーザーは何を確認できるのでしょうか?決済層が混雑している場合、コミットメントや出金はどのような影響を受けますか?
緊急手順や管理制御など、現在の文書からこれらの質問に答えてください。ロードマップに記載されているフォールバックは、必ずしも機能するとは限りません。残高を表示し続けるネットワークでは、取引を受け付けたり引き出しを完了したりする能力が低下している可能性があります。
ブリッジの依存関係を個別に確認します。 2 つのネットワークにトークンが表示されても、転送ルートが両方のチェーンのすべてのセキュリティ プロパティを継承することを意味するわけではありません。
全体的なコストとユーザー エクスペリエンスを比較する
低額の約定手数料は取引コストの一部にすぎません。データの公開、決済、ブリッジおよび引き出しの操作では、料金が追加されたり、遅延が発生したりする場合があります。同じ期間の同等の行動を比較し、誰がどのコストを負担するかを説明します。
ユーザーに関連する完全なルート (エントリ、実行、確認、引き出し、および目的の資産またはネットワークへの戻り) を測定します。 1 つのステージのみをカバーするベンチマークを往復全体の料金として提示すべきではありません。コスト削減は、需要とデータ層の条件によっても異なります。
依存関係チェックリストを使用する
システムごとに、実行ルール、発注権限、データの場所、検証メカニズム、決済先、アップグレード制御、終了手順を記録します。どの申し立てが有効で、どの申し立てが計画されているかをマークします。アーキテクチャの設定は変更される可能性があるため、ソースとチェックした日付を含めてください。
関連するが別個の問題については、クロスチェーン メッセージの比較 を読んでください。このガイドはアーキテクチャ内の作業の分割に従っていますが、このガイドはチェーン間の指示に従います。
プロトコルのエンジニアリング設計とそのトークンの経済的権利は、別個の研究課題です。スケーリングの主張を取引の結論として扱うのではなく、公式ドキュメントと OrangeX マーケット ページ を通じて、トークンのユーティリティと実際の市場の可用性を個別に確認してください。
