新着：HeliusがLight Protocolを買収
Constellation：Solanaにおける複数同時リーダー向けプロポーザー
ブログ/リサーチ

Constellation：SolanaにおけるMCPの提案

Developer Experience EngineerXの0xIchigoLinkedInの0xIchigoGitHubの0xIchigo
読了時間：56分
目次

本稿の初期版をレビューしてくださったMatt、Nick、Alessandro、Brennan、Maxに深く感謝します。

実践的なポイント

  • Constellationは、大規模な本番ブロックチェーンにMultiple Concurrent Proposers（MCP）を実装する、初の正式なプロトコルレベルの提案です。
  • Constellationは、ブロック構築に関するリーダーの裁量を制約する2つの新しい役割（プロポーザーとアテスター）を導入します。約16のプロポーザーが50ms周期で同時に動作し、トランザクションを消失訂正符号化されたpsliceにまとめ、256のアテスターへ配布します。アテステーション記録は、リーダーが含めるトランザクションの集合を暗号学的に拘束します。十分な数のアテスターがpsliceを証明した場合、リーダーはネットワークに拒否される無効なブロックを生成しない限り、そのトランザクションを除外できません。
  • Constellationには選択的な検閲耐性があります。各周期において、手数料面で競争力のあるトランザクションはすべて含まれるか、1つも含まれないかのいずれかです。
  • 内容が可視化された状態での順序操作攻撃とタイミング操作攻撃は、依然として未解決です。Constellation上のトランザクションは、送信時にそのトランザクションを受信したすべてのプロポーザーから見えます。MCPのマルチプロポーザー構成により、これらの攻撃対象領域は狭まるどころか、むしろ広がる可能性があります。時間差を利用したレイテンシ競争は、現行設計では罰することができないと認識されています。
  • Constellationは既存の手数料を再構成します。包含手数料は現在の基本手数料に、順序付け手数料は既存の優先手数料に対応します。より重要な経済的変化は、現在プロトコル外のランディングサービスやオフチェーンの手数料契約を経由しているアクティビティが、プロトコルへ戻ると見込まれる点です。ステーク加重による役割選定では既存の集中傾向が引き継がれます。また、Constellationの最終的なSIMDが公開されるまで、個々のバリデーターへの正味の影響はモデル化できません。
  • MCPは順序確定までのレイテンシを増やしますが、包含レイテンシを減らします。アテスターラウンド、50msの周期ウィンドウ、バッチ組み立てのすべてが、現在の直接的なTPU送信経路と比べて時間を追加します。現在は、TPUトランザクションを即座に詰め込むバリデーターではレイテンシが高く、遅延させるバリデーターでは低くなります。Constellationでは、有効なトランザクションに対し、プロトコルによって強制される期限付きの包含保証が提供されます。
  • Constellationは、Proposer-Builder Separation（PBS）モデルと明確に互換性がありません。アテステーション記録によってリーダーの裁量が制約されると、専門ビルダーが販売できるものは残りません。このアプローチは、Ethereumが現在採用しているMEVへのアプローチとは根本的に異なる思想を表しています。
  • 現実的なネットワーク条件下での実証的なベンチマークは、まだ存在しません。Anzaが提供できる最も重要なデータは、現行プロトコルにおける200msスロットと、Constellationにおける200msスロットのレイテンシ予測の比較です。このデータが得られるまで、コミュニティは定量化できないトレードオフについて議論することになります。
  • ConstellationはAlpenglowの上に構築されます。Alpenglowは2026年第3四半期のメインネット公開を目指しています。

はじめに

驚くほどAgaveの植物が見当たらない中、AnzaのCEOであるBrennan Wattは、SolanaにMultiple Concurrent Proposers（MCP）を導入する提案であるConstellationを発表するため、カリフォルニアの砂漠へ向かいました。これは、構造面で最も野心的なアップグレードであり、おそらく本番ブロックチェーンがこれまで提示した中で最も重大なプロトコルレベルのMCP提案です。トランザクションの順序付けに対するリーダーの一時的な独占と、そこから生まれる抽出可能な価値の解消を目指しています。Constellationは、Solanaのブロックスペースを民主化します。

本稿では、Constellationを批判的に分析します。Constellationが解決する問題、意図的に先送りする問題、そして真に未解決の問題を取り上げます。検閲耐性を評価するための3層フレームワークを提示し、現在のMCPの状況とConstellationを比較したうえで、導入されるトレードオフがSolanaの築いてきた性能面のアイデンティティと両立するかを検討します。

Alpenglowに関する事前知識があることを前提とします。

Constellationが解決する問題

トランザクションはSolanaの生命線です。トランザクションはまとめられ、ブロックという形でネットワークへ永続的に書き込まれます。しかし、どのトランザクションをどの順序でブロックに含めるかを決めるプロセスは、中立ではありません。

ブロック生成に対するリーダーの独占

ブロック生成はリーダースケジュールに従って交代します。各時間枠では、1つのバリデーターがブロック生成を担当します。

この間、トランザクションはリーダーのTransaction Processing Unit（TPU）へ直接転送され、通常は他の誰よりも先にリーダーが受信します。

リーダーは極めて強い権限を持つ立場にあります。つまり、公開される前に受信中のトランザクションを確認できます。

リーダーは、一部のトランザクションを含めない、任意に並べ替える、または自らのトランザクションを追加するといった判断ができます。

これは、現在の単一リーダー型コンセンサスの構造的な特性であり、今日稼働しているほぼすべてのProof of Stakeブロックチェーンに程度の差こそあれ存在します。

Solanaに公開mempoolがないことは、この非対称性を弱めるのではなく、むしろ強めています。Ethereumの公開mempoolでは、参加者が保留中のトランザクションをある程度確認できます。そのため、トランザクションの順序を利用しようと競争する高度なアクターの間では、ある種の公平な競争環境が生まれます。

Solanaでは、トランザクション転送の性質上、リーダーの情報優位性に対抗することがより困難です。

Maximal Extractable Value（MEV）

通常の状況や誠実なバリデーターのもとでは、この権限の大部分は悪用されません。しかし問題は、バリデーターが合理的な経済主体であることです。Solanaが成熟し、金融活動が拡大し続けるにつれて、リーダーの一時的な独占を利用して得られる利益も増加します。この立場を利用しないバリデーターは、利益をみすみす逃すことになります。正しく動作するノードが経済的に不利になり、自ら参加するシステムの品質を損なうインセンティブを与えられてしまいます。

この抽出可能な利益はMaximal Extractable Value（MEV）と呼ばれます。この用語は、Proof of Stakeネットワークへ適用される以前に、DaianらがFlash Boys 2.0でMiner Extractable Valueとして初めて正式に定義しました。裁定取引やフロントランニングからサンドイッチ攻撃、選択的検閲、さらには処理対象となるユーザーのトランザクションに対するリーダーの情報面・立場上の優位性を利用するあらゆる戦略までを含みます。

業界におけるMEVへの主な対応は、EthereumでMEV-Boostを介して実装されているProposer-Builder Separation（PBS）モデルです。PBSでは、専門のビルダーが抽出可能な価値を最大化するブロックの構築を競い、プロポーザーは生成するブロックとして最も収益性の高いものを選ぶだけです。このモデルはMEVの抽出を不可避と想定しているため、MEVを最も高度なアクターへ集中させるのではなく、MEVへのアクセスを民主化し、その収益をバリデーター集合全体へ再分配するという現実的な問題の捉え直しです。

この捉え方の問題は、PBSがユーザーへの害を減らさない点です。抽出は依然として行われており、受益者が変わっただけです。PBSはネットワークノードに対するMEVの悪影響の一部には対処しますが、ネットワークユーザーへの害は減らしません。

SolanaもMEVとの関係を変化させ続けています。高速なブロック時間、TPUへの直接送信、競争力のあるバリデーター集合の組み合わせにより、スパム、優先手数料オークション、バリデーターレベルのトランザクション並べ替えを特徴とする独自のMEV環境が生まれました。Jitoのブロックエンジンは、MEV-Boostと部分的に類似していると考えられます。サーチャーがトランザクションの順序に入札し、収益をバリデーターとステーカーで分配するオフチェーンのオークション機構を提供するためです。つまり、PBSと同様に、JitoはMEVを完全に排除するのではなく、より民主的な方法で管理し、再分配します。

Constellationは、この問題の解決を目指します。リーダーの独占を受け入れてその影響を管理するのではなく、その独占を構造的に封じ込め、最も有害な形態のMEVが設計上不可能になるようにします。Constellationのホワイトペーパーでは、この目標を「Internet Capital Marketsのインフラストラクチャであり、市場構造が公正であるとユーザーが信頼できる、経済活動のための普遍的な場」と表現しています。

従来の金融市場では、規制と管轄当局の監督を通じて同様の保護を実施しようとしています。こうした保護は事後的で一貫性に欠け、不十分であることが繰り返し示されてきました。Constellationは、回避や選択的な適用ができないよう、プロトコルレベルで公平性を強制することを目指します。そのために、Solanaへ*Multiple Concurrent Proposers（MCP）*を実装します。

Multiple Concurrent Proposers

従来の単一リーダー型ブロックチェーンでは、各ブロックの生成を1つのバリデーターが担当します。このバリデーター、すなわちリーダーは、トランザクションの包含と順序を一時的に独占します。このバリデーターがブロック生成権限を持つ間、ネットワーク内の他の参加者は受動的な観察者となります。どのトランザクションをどの順序で含めるかは、最終的にリーダーが決定します。

この設計はシンプルであるため魅力的です。1つのバリデーターがブロック生成を統括することで、調整のオーバーヘッドがなく、競合する提案を解決する必要もなく、責任の所在も明確になります。しかし、同時に悪用される単一障害点にもなります。リーダーの一時的な独占がMEVの根本原因であり、これまでの主要な緩和策はすべて、この構造を受け入れたうえでその影響を管理しようとしてきました。

Multiple Concurrent Proposers（MCP）は、この独占を構造レベルで解消するプロトコル設計の一種です。ブロック生成権を独占する単一のリーダーへ交代するのではなく、MCPでは複数のノードが同時にトランザクションを提案できます。単一のプロポーザーがトランザクション集合全体を支配することはありません。代わりに、通常は裁量を制限されたアセンブラーの役割によって、プロトコルのルールに従って各提案がまとめられます。

複数のプロポーザーへ同時にトランザクションを送信したユーザーは、単一のノードに依存しなくなります。トランザクションが包含されるまでに、複数の独立した経路を持つためです。トランザクションを除外しようとするリーダーは、他のプロポーザーがすでにそのトランザクションを確認し、アテスターもすでに証明しているという事実に対処しなければなりません。最終ブロックは単一のリーダーが組み立てますが、その裁量は厳しく制限されます。

MCPの主なトレードオフは、調整の複雑さです。複数のノードが同時にトランザクションを提案できるようにすると、単一リーダー型の設計では完全に回避できる問題が生じます。2つのプロポーザーが同じトランザクションを含めた場合、競合をどのように解決するのでしょうか。提案間の順序はどのように決定するのでしょうか。高度なプロポーザーが結合ルールを悪用することを、どのように防ぐのでしょうか。これによりプロトコルは大幅に複雑になります。チームは、新しいノードの役割、スケジューリングロジック、暗号学的な前提、障害モードに関する調整上の課題へ対処する必要があり、そのすべてに厳格なテストが求められます。

ここでは厳密な区別が重要です。MCPという用語は、特性が大きく異なるさまざまな設計を指して、業界全体で曖昧に使われているためです。最も限定的なMCPは、確率的な検閲耐性を提供します。複数のプロポーザーへ送信されたトランザクションを検閲するには複数ノード間の協調が必要になるため、検閲が難しくなります。より強力なMCPは、構造的な検閲耐性を提供できます。十分なクォーラムによって証明されたトランザクションを検閲するブロックをリーダーが生成することは、数学的に不可能になります。Constellationが目指すのは後者です。強い保証を必要とする金融アプリケーションにとって、この違いは極めて重要です。

Constellationの仕組み

Constellationは、SolanaにMCPを実装するためのプロトコルです。Alpenglowを補完するものであり、Alpenglowがコンセンサス、すなわち安全性、活性、ファイナリティを担う一方、Constellationは市場構造を担います。具体的には、誰がトランザクションを提案できるか、その提案をどのように承認するか、リーダーが提案に対して何を許可されるかを定めます。Constellationは、Alpenglowがファイナライズするペイロードを生成します。

アーキテクチャ

ConstellationはSolanaのプロトコルスタックに、それぞれ異なる責務を持つ2つの新しい役割を導入し、同時にリーダーとバリデーターの役割を変更します。

プロポーザーはトランザクションの入口です。任意の時点で約16のプロポーザーが同時に稼働します。プロポーザーはステークに基づいてランダムに選ばれ、32周期ごと、すなわち~1.6秒ごとに交代します。ユーザーは、選択した1つ以上のプロポーザーへトランザクションを直接送信します。プロポーザーは、有効なトランザクションのみ受け入れられるという制約のもとで、任意のトランザクションを自由に受け入れたり拒否したりできます。この段階でトランザクションの包含を強制するプロトコルルールはありません。検閲耐性の保証は、パイプラインの後半で提供されます。各プロポーザーは50ミリ秒周期で動作します。各周期内で、プロポーザーは受け入れたトランザクションをpsliceと呼ばれる構造にまとめます。「p」という接頭辞は発音せず、Alpenglowのsliceと区別するためだけに使用されます。psliceは消失訂正符号化によってpshredと呼ばれる256個の小さな断片に分割され、稼働中の256のアテスターへ1つずつ配布されます。この消失訂正符号化の復元しきい値は64です。つまり、256個のpshredのうち任意の64個があれば、完全なpsliceを復元できます。各pshredには、完全なトランザクションリストに対する暗号学的ハッシュコミットメントが含まれます。これにより、アテスターの承認後にリーダーが別のトランザクションへ差し替えたり、pslice内の順序を変更したりすることはできません。

アテスターはプロポーザーからpshredを受信し、障害や不在に備えて直ちに次の~2人のリーダーへ転送するとともに、受信したpsliceのコミットメントハッシュを記録します。各周期の終了時に、アテスターはアテステーションへ署名します。これは、その周期中に確認したすべてのpsliceコミットメントハッシュを列挙した、暗号学的な拘束力を持つ声明です。このアテステーションはリーダーへ送信され、リーダーが含められるトランザクションを制約する証拠記録として機能します。この記録にはステークによる重み付けと署名があるため、偽造したり、密かに無視したりすることはできません。

ConstellationのリーダーはAlpenglowのリーダーと同じであり、コンセンサスに入る最終ブロックの生成を担当するノードです。Constellationでは、アテステーション記録によってリーダーの裁量が厳しく制限される点が異なります。Constellationは2つの異なるしきい値を強制します。集約アテステーションが有効になるには、アテスターの少なくとも60%が参加する必要があります。このしきい値に達しない場合、ブロック全体がスキップされます。その中で、アテスターの少なくとも40%が証明したpsliceは、リーダーが必ず含めなければなりません。含めなかった場合、無効なブロックが生成され、ネットワークに拒否されます。この2しきい値設計は、ブロックレベルの有効性とプロポーザーごとの包含を分離します。つまり、一部のプロポーザーのデータが十分な数のアテスターへ到達しなかった場合でも、リーダーは有効なブロックを生成できます。しかし、十分に到達したプロポーザーのデータを選択的に除外することはできません。リーダーは証明済みのすべてのpsliceをバッチにまとめると、そのバッチをAlpenglowのRotor経由でバリデーターへ送信します。

バリデーターはRotor経由でリーダーからバッチを受信し、到着に合わせてパイプライン実行を行います。完全なブロックを受信すると、バリデーターはアテステーション記録と照合し、証明されたすべてのpsliceに対応する送信内容がブロック内に存在することを確認します。すべてのチェックに合格した場合に限り、バリデーターはファイナライズへ投票します。チェックに失敗した場合、バリデーターはTrySkipWindow呼び出しを通じて、リーダーの時間枠全体をスキップするよう投票します。

周期とブロック

周期はConstellationにおける時間の基本単位です。Unixナノ秒タイムスタンプを50,000,000で割り、UTCの実時間から導出する50ミリ秒の時間枠です。重要なのは、周期がAlpenglowのスロットと一致していないことです。1つのスロットには複数の周期が含まれ、それらの周期で生成されたバッチがリーダーのブロックのペイロードを構成します。この区別が重要なのは、50ms周期が経済的な刻み、すなわち検閲耐性が強制される時間枠である一方、スロットは引き続きAlpenglowのコンセンサス単位であるためです。

ホワイトペーパーでは、プロポーザーとアテスター間のクロックスキューに対する許容範囲を定め、それに応じてアテステーションの時間枠を調整しています。これが重要である理由を示すため、あるプロポーザーの時計がアテスター集合より5ms進んでいると仮定します。このプロポーザーのpshredは周期境界に対して想定より早くアテスターへ到着する可能性があり、そのpslice内のトランザクションにはアテステーションを集めるための時間がわずかに長く与えられます。反対に、時計が遅れているプロポーザーでは、「時間どおり」に送信した場合でも、pshredの到着が遅れ、アテステーションの時間枠から完全に外れる可能性があります。chronyやGPS受信機などのツールを利用するデータセンター環境では、時刻同期は一般的であり、ずれは通常サブミリ秒です。これはConstellationの許容範囲内に十分収まります。懸念点は、Alpenglowの純粋に論理的な時間モデルには存在しなかった新しい変数をConstellationが導入することです。Constellationの最終的なSIMDでは、この変数の監視範囲を規定する必要があります。

Constellationがエポックの終端へ近づくと、プロポーザーとアテスターは次のエポックが開始したかどうかを一時的に判断できない可能性があります。この時間枠では、Constellationは両方のエポックで同時に動作し、2組のプロポーザーとアテスターが同時に稼働します。どの周期がどのエポックに属するかは、Alpenglowのコンセンサスによって自然に解決されます。

トランザクションのライフサイクルと手数料

トランザクションが実行されるには、4つの関門を通過する必要があります。

  • プロポーザーに受け入れられ、psliceへ含められる必要があります。
  • そのpsliceは、リーダーのバッチへ含められるために十分なアテステーションを集める必要があります。
  • トランザクションの入札額は、バッチのコンピュート上限内で実行対象として選ばれるのに十分な高さである必要があります。
  • そのバッチを含むブロックは、Alpenglowのコンセンサスによって承認される必要があります。

各トランザクションには入札額、すなわちコンピュートユニットあたりの実行手数料が設定され、同じバッチ内での順序が決まります。入札額の高いものから先に実行されます。

Constellationは、トランザクションのコストを2つの異なる手数料に分けます。

  • 包含手数料。
  • 順序付け手数料。

包含手数料は、トランザクションのサイズと署名数に基づく少額の固定料金です。トランザクションをpsliceへ含めたプロポーザーへ支払われ、最終的に実行されるかどうかにかかわらず、トランザクションがアテステーションのしきい値を超えた時点で課金されます。これはSolanaの現行システムにおける基本手数料に似ていますが、重要な注意点があります。ユーザーが冗長性を確保するために同じトランザクションを3つのプロポーザーへ送信すると、各プロポーザーが独立して包含処理を行うため、包含手数料を3回、すなわちプロポーザーごとに1回支払います。したがって、ユーザーが冗長性のために同じトランザクションをn個の異なるプロポーザーへ送信した場合、包含手数料をn回支払います。

順序付け手数料は、優先度に基づくより大きな構成要素であり、トランザクションの総コンピュートユニット数に入札額を掛けたものです。トランザクションは何人のプロポーザーに含められても1回しか実行できないため、この手数料は1回だけ課金されます。たとえば、200,000コンピュートユニットを要求し、コンピュートユニットあたり0.00001 SOLで入札するトランザクションは、2 SOLの順序付け手数料を支払います。同じトランザクションを冗長性のために4つのプロポーザーへ送信した場合、ユーザーは4回の包含手数料と、1回の2 SOLの順序付け手数料を支払います。順序付け手数料は、ノードのステークに比例してエコシステムへ還元されます。この仕組みの設計は、最終的なSIMDに委ねられています。

同時に動作するプロポーザー間での手数料操作を防ぐため、手数料支払者の各アカウントは約0.001 SOLの最低準備残高を維持する必要があります。これにより、複数のプロポーザーが同じアカウントに関係するトランザクションを同時に含めても、包含手数料を必ず支払えるようになります。

ConstellationとAlpenglow

AlpenglowはSolanaのコンセンサスプロトコルです。どのブロックが有効か、どの順序でファイナライズされるか、ネットワークが障害からどのように復旧するかを決定します。VotorとRotorのコンポーネントは、Tower BFTとゴシップベースの投票伝播を置き換え、ファイナリティまでの時間を大幅に短縮します。Alpenglowは、誰がトランザクションを提案するか、ブロック内の順序をどのように決めるかについては何も規定しません。

Constellationは、Alpenglowのリーダーが組み立てるブロックに対して許可される操作を制約する市場構造レイヤーです。誰がトランザクションを提案するか、各ブロック内の順序をどのように決めるかを定義します。Constellationが生成するバッチは、Alpenglowのブロックのペイロードになります。その後、AlpenglowのVotorが事前定義された投票ルールに従って、それらのブロックを公証します。2つのプロトコルは、Alpenglowが安全性と活性を、Constellationが順序の公平性を提供するように構成されています。

この構成可能性により、ConstellationはAlpenglowのセキュリティ上の前提を弱めることなく継承します。ConstellationはAlpenglowの保証には影響を与えません。代わりに、新しい周期ベースのタイミングモデルにおいて、新しいプロポーザーとアテスターの役割、およびUTCの実時間同期に関する新たな保証と前提を導入します。

Constellationは、スケーラブルな本番ブロックチェーンにMCPを実装するための、初の正式なプロトコルレベルの提案です。Solanaへ検閲耐性を導入する重要な追加要素であり、Alpenglowが切り開くプロトコルロードマップの次章です。

検閲耐性に本当に必要なもの

MEVに関する文献は歴史的に、複数の異なる観点からこの問題に取り組んできました。それらを総合すると、あらゆる検閲耐性の提案が実際に解決すべき課題について、より統一的な全体像が見えてきます。Eskandariらによるフロントランニング攻撃の基礎的な分類、GarimidiらによるMCPプロトコルの2つの特性に関する形式的フレームワーク、LandersとMarshによるMCP固有のMEVチャネルの分析を踏まえ、攻撃対象領域を3つの異なるレイヤーに整理することを提案します。それぞれに異なる種類の解決策が必要です。このフレームワークは、Constellationの設計を評価するために、ここで提示する独自の統合です。

レイヤー1：ハード検閲

ハード検閲とは、リーダーまたは提案者が、特定したトランザクションの取り込みを拒否できることを指します。これは最も明白な操作形態であり、Constellationが構造的に解決する問題です。Constellationでは、十分なクォーラムのattesterが証明した、手数料面で競争力のあるトランザクションを除外した有効なブロックをリーダーが生成することは、暗号学的に不可能になります。強制はアーキテクチャによって行われるため、この目的にslashingは必要ありません。

レイヤー2：内容が可視な順序付け

第2のレイヤーへの対処はさらに困難です。提案者は完全な検閲はできませんが、最終的な順序が決まる前にトランザクション内容を確認し、その可視性を悪用しようとすることはできます（たとえば、大口取引に対するサンドイッチ攻撃です）。これはGarimidiらがhiding特性として形式化したものです。敵対者は、トランザクションが確定する前にその内容を確認できてはなりません。Constellationは部分的なhidingを実装しています。つまり、トランザクションを確認できるのは、それを受信した提案者だけであり、すべての提案者ではありません。また、リーダーがトランザクション内容を確認できるのは、サイクルの期限が過ぎた後だけです。これは完全に可視である場合より優れていますが、確定前にトランザクション内容がすべての当事者から不可視であることを求めるGarimidiらのhiding特性を完全には満たしません。受信した提案者は、受け取ったトランザクションの内容を確認し、悪用することが依然として可能です。

Constellationについてさらに懸念されるのは、トランザクションを公開送信するMCPが、内容の可視性を利用した搾取を増幅する可能性があることです。この仕組みでは、各提案者が自ら受信したトランザクションを確認し、その可視性を自身のpslice内で悪用できます。複数の主体がそれぞれ一部を確認できるため、攻撃対象領域は単一リーダーモデルとは異なります。単一の提案者に送信したユーザーは、その提案者だけにトランザクションを開示します。しかし、冗長性を確保するために複数の提案者へ送信すると、開示範囲も比例して広がります。LandersとMarshはこの力学を形式化しています。同時ブロック生成により、タイミングゲーム、同一tick内での重複機会、そして被害者のトランザクションごとに成立し得る価値抽出の試行回数を現在は制限している単一builderのチョークポイントが構造的に失われます。内容の可視性に対処せず提案者集合を分散化すると、MEVの攻撃対象領域は縮小するのではなく拡大します。

LandersとMarshによるMCP固有のMEVチャネルの分析では、Constellationが提供するよりも広範な内容の可視性を前提としています。Constellationの部分的なhidingでは、内容の可視性を利用した搾取の増幅は、アーキテクチャ上の必然ではなく、ユーザーの送信戦略によって決まります。単一の信頼できる提案者に送信するユーザーの内容開示の特性は、現在の単一リーダーモデルとほぼ同じです。ただし、単一提案者への送信では、検閲耐性が依存する冗長性が犠牲になります。 

レイヤー3：タイミングとレイテンシの操作

最も捉えにくく、処罰が難しいレイヤーは、タイミングとレイテンシの操作に関するものです。Constellationでは、提案者がpshredのattesterへの転送をわずかに遅らせ、競合するトランザクションをattestation期間外に追い出したり、UTC時計のずれを悪用して、どのトランザクションが十分なattestationを獲得するかを操作したりできます。この問題はConstellationのホワイトペーパーでも直接認められています。遅いメッセージ配信は、本物のネットワーク遅延と区別できないため、「処罰できない」とされています。slashingが重要になる可能性があるのはこのレイヤーであり、Constellationの最終的なSIMDが対処すべき主要な未解決問題です。 

Constellationの設計を支える基本的な前提は、提案者とユーザーの関係が匿名ではないということです。これは信頼を測定でき、評判が重要になる反復的なやり取りです。常時およそ16の提案者が活動しているため、ある提案者から一貫して不当な扱いを受けるユーザーは、残り15のいずれかへの送信を開始できます。これは悪意ある主体を直接処罰するために利用できるオンチェーン上の痕跡を生みませんが、自らの立場を悪用する提案者に経済的な影響を与えます。この評判による圧力が、slashingのような解決策と比較してタイミング操作を抑止するのに十分かどうかは未解決です。最終的には、提案者の行動が時間とともにユーザーにとってどの程度透明になるかに左右されるでしょう。 

レイヤー攻撃の種類Constellationの対応範囲解決策の種類
ハード検閲（1）抑制攻撃（リーダーまたは提案者がトランザクションを完全にブロックすること）完全に解決（ブロック有効性ルールとvalidatorによる拒否）暗号学的な強制
内容が可視な順序付け（2）フロントランニング／サンドイッチ（提案者がトランザクション内容を確認し、順序を悪用すること）部分的に対処（トランザクション内容は受信した提案者と、期限後のリーダーに表示される）非同期実行またはhiding
タイミングとレイテンシの操作（3）PoAレイテンシのタイミング競争（pshredの意図的な遅延、時計のずれ）未解決（処罰できず、論文でも認識されている）検出可能なケースにはslashing、その他にはhiding

Validatorとユーザーへの影響

Validator

ConstellationはMEVの機会を完全に排除するのではなく、validator間で再配分します。現在リーダーが利用できる、最も明白で直接的に収益化できる手段であるハード検閲は、設計上実行不可能になります。しかし、それに代わるのは、レイテンシ上の優位性、正確な時計同期、pshred転送期間を継続的に悪用する高度な能力を持つvalidatorに有利な、より捉えにくく処罰しにくいタイミングチャネルです。最終的な効果は、価値抽出の対象領域全体が縮小するというより、validatorが価値を抽出する方法が変わることです。ただし、抽出が大幅に難しくなるという点は重要です。

Constellationは、既存の手数料収入を再構成するのであって、本質的に新しい収入源を導入するわけではありません。inclusion feeは現在のbase feeに相当し、ordering feeは既存のpriority feeに対応します。配分は、validatorが現在得ているものと同様になる見込みです。違いは主に運用面にあります。つまり、優れたoperatorは提案者としてより多くのinclusion feeを獲得するため、独立した収益カテゴリーが生まれるのではなく、既存の経済設計内にパフォーマンスに基づく差が生じます。現在の設計では、attesterの役割に個別の報酬はありません。その理由は、現在のTurbineへの参加と同様に、ネットワーク全体にとって純利益になるため実行されることが想定されているからです。より大きな経済的変化は、現在プロトコル外のlandingサービス、市場ベースのオークション、オフチェーンの手数料契約を通じて流れている活動がプロトコル内に戻り、validatorがより直接的に恩恵を受けられるようになることです。ただし、SIMDで正確な仕組みが規定されるまでは、個々のvalidatorへの純経済効果は未解決です。特に小規模validatorでは、stake加重選択によって提案者になる頻度が下がり、インフラのオーバーヘッドによって最低コストが上昇します。

提案者とattesterはstake加重で選ばれます。つまり、validator経済を形作るのと同じ集中化の力学が、これらの役割への参加にも影響します。少数の高stake validatorが提案者選択を支配する場合、検閲耐性の保証は形式上維持されますが、現在のSolanaより改善されているとはいえ（すなわち、n個から1つを選ぶのではなく、n個から16を選びます）、提案者集合の実質的な多様性は狭まります。理論上は成立していても、独立性の前提は実際には弱まり始めます。単一の主体が複数の高stake validatorを運用し得るValidator-as-a-Service（VaaS）サービスが登場していることを考えると、これは注目すべき懸念です。SIMDが集中を防ぐ仕組みや提案者選択のインセンティブを導入するかどうかは、Constellationが掲げる保証の強度に直接影響する設計上の問題です。 

ユーザー

ユーザーにとって、十分な数の提案者に送信された、手数料面で競争力のあるトランザクションは、選択的な除外に対する強力なプロトコル保証によって初めて保護されます。これまで存在しなかった保証を備えた金融アプリケーションを構築できるようになり、Solanaでのみ実現できるものが変わります。 

高頻度かつ価格に敏感なユーザーは、冗長性を確保するため、複数の提案者にトランザクションを送信する必要があります。懸念は、内容の可視性に対処せず提案者集合を分散化すると、サンドイッチ攻撃への露出が増える可能性があることです。各提案者は、自らに送信されたトランザクションを確認して行動できるため、冗長性を得るため複数の提案者へ送信するユーザーは、トランザクション内容を確認できる当事者の数も比例して増やします。これにより単一リーダーのチョークポイントが必然的に失われ、トランザクションの意図がより広範な潜在的敵対者に伝わります。実務上、より高度なユーザーは、冗長性と露出のバランスを取る新しい送信戦略を開発する必要があります。広範な複数送信戦略ではなく、たとえば評判やstakeに基づいて提案者を選択的に指定する方法が考えられます。

特にマーケットメーカーにとって、Constellationの取り込み保証は、インフラが約定品質を左右するという敵対的リスクを排除します。残るのは純粋な情報の非対称性であり、これは現在、最良の従来型取引市場でマーケットメーカーが直面しているものと同じリスク特性です。この収束によって、取り込み促進とレイテンシ削減の議論は、単なる理想ではなく具体的なものになります。この収束については「未解決の問題」セクションでさらに詳しく説明します。

平均的なユーザーが感じる体験の純変化はわずかである可能性が高いものの、取り込み保証は信頼性を有意に改善します。今後のベンチマークを待つ必要がありますが、シーケンスレイテンシへの純影響は、依然として実証が必要な未解決問題です。

全体像：Constellationの比較

Sei Giga

Sei Gigaは、現在のMCP分野においてConstellationに最も近い事例です。つまり、将来の研究目標ではなく、最優先のアーキテクチャ目標としてMCPを追求する本番品質のブロックチェーンです。同じレイヤーで異なるトレードオフを選択しているため、両者の比較は有益です。

Gigaのコンセンサス基盤はAutobahnと呼ばれます。これは、すべてのvalidatorが独自の継続的な提案の「lane」を並列に運用する、複数提案者型のBFTプロトコルです。単一リーダーに依存するのではなく、各nodeが独立したlaneで独自のデータ提案streamを継続的に配布し、コンセンサスレイヤーが定期的に「tip cut」をcommitします。これは各laneから最新の提案を集約したコンパクトなsnapshotです。この仕組みは、選択された約16の提案者が固定された50msサイクルで動作するConstellationのモデルとはアーキテクチャ上異なります。Autobahnのlaneベースモデルでは、ローテーションするstake加重部分集合から選択されるのではなく、任意のvalidatorが継続的な提案laneを維持できるため、ブロック生成への参加が大幅に広がります。

最も重要な違いは、内容が可視な順序付けへの対応です。Autobahnは、トランザクションの順序付けと実行を分離することで非同期実行を可能にします。Constellationでは、この設計判断が先送りされています。次のセクションで説明するように、非同期実行では、提案者が順序付け時点で既知の最終stateに対して実行結果をsimulateできなくなるため、内容が可視な順序付けの攻撃対象領域が狭まります。

Gigaが提供するのは確率的な検閲耐性ですが、Constellationは構造的な保証を提供します。Gigaの根底にある考え方は、複数の提案者に送信されたトランザクションは検閲しにくいというものです。各提案者は不完全な情報で動作し、別の提案者が同じtick内でそのトランザクションを取り込めば、検閲する意味が失われる可能性があるためです。これに対しConstellationでは、十分なattestationを得たトランザクションを除外したリーダーは、無効なブロックを生成することになります。確率的耐性は検閲のコストを引き上げますが、構造的耐性は検閲を暗号学的に不可能にします。両プロトコルが実現しようとしている金融アプリケーションにとって、この違いは重要です。 

2つの設計における目標の違いについて、率直に述べる価値があります。Constellationは、正しさの特性を証明し、fault条件を定義し、クォーラム閾値を規定するプロトコル仕様です。また、数十億ドル規模の価値がstakeされた、拡張性のある本番ネットワークに正式な提案として提出されることを意図しています。Sei Gigaのホワイトペーパーは性質が異なり、throughputの主張とEVM互換性を重視しています。MEVと検閲耐性は、形式的に規定された保証ではなく、複数提案者アーキテクチャから生じる利点として扱われています。非同期実行の方向性は正しいものの、Gigaは、順序付けの制約、attesterクォーラム、fault条件について、Constellationと同水準の形式的保証を提供していません。これはGigaの順序付けの選択に対する批判というより、異なる背景を反映したものです。Constellationは、世界で最もthroughputの高い本番ブロックチェーン上で提案されているため、それに見合う、より高い仕様水準が要求され、実際に提供されています。

学術的な理想形

MCP設計の理論的な基準は、a16z Crypto ResearchのGarimidiとNeu、AnzaのMax Resnickによる2025年の論文、Multiple Concurrent Proposers: Why and Howです。この論文は、検閲耐性を持つ設計が満たすべきだと主張する2つの特性、選択的検閲への耐性とhidingを提供するMCPプロトコルを提案しています。前者は敵対者がトランザクションを選択的に遅延させられないことを保証し、後者は確定前にトランザクション内容が不可視であることを保証します。現在の文献で、両方を同時に形式的に実現している唯一のMCP設計です。

hidingを可能にする仕組みは、HECC（Hiding Erasure-Correcting Code）です。これは、任意のT個のshredからは基礎となるトランザクションbatchについて何の情報も得られず、K + T個のshredがあれば完全に復元できるようにパラメータ化されています。重要なのは、どのbatchが取り込まれるかをコンセンサスが確定した後にのみ、relayが保存したshredをbroadcastすることです。これにより、確定前にトランザクション内容を観察できなくなり、内容が可視な順序付けの攻撃対象領域を情報理論的な保証として完全に排除できます。 

先ほど構築したフレームワークに当てはめると、このプロトコル設計は、レイヤー1を構造的な検閲耐性で、レイヤー2をhidingで解決し、hidingが提供する検閲耐性の保証によってレイヤー3を制限する唯一の設計です。ConstellationもGigaも、これを完全には実現していません。

この比較を特に興味深いものにしているのは、理論的な理想形の共著者であるResnickが、そこから意図的に逸脱するプロトコルであるConstellationの共著者でもあることです。これは、完全なHECCベースの設計はSolana規模の本番ネットワークにはまだ導入できず、構造的な検閲耐性のほうが先に解決すべき緊急性の高い問題だという意図的な判断を反映しています。この論文はConstellationの北極星として機能します。すべてを一度に実現できなくても、プロトコルが目指す方向を示す形式仕様です。 

Ethereum Braid

Braidは、Max Resnickが提案したEthereumの主要なMCP案です。現在は競合するFOCIL inclusion list設計とともに、EthereumのScourgeロードマップの一部として検討されています。ここで取り上げる目的は、技術的な比較よりも背景の提示にあります。業界全体が、異なる出発点から同じ構造的問題に取り組んでいます。

Braidは、同じslot内で複数の提案者が並列chain上に同時にブロックを構築できるようにすることでMCPを実装します。execution layerは、事前に定められたルールに従ってトランザクションを集約、重複排除、sortします。追加のプロトコル上の役割は導入しません。最も重要な違いは、Braidの安全性が暗号化mempoolに大きく依存しており、hidingを先送りするのではなく前提条件としている点です。Braidは未導入の研究提案にとどまり、Ethereumコミュニティでは、FOCILよりBraidを優先すべきかについて、まだ合意に達していません。

Braidが最終的に裏付けるのは、MCPを支持する構造的な議論が、単一のchainを超えて成立するということです。また、このセクションで取り上げた4件のうち3件にResnickが関与している点も注目に値します。これはおそらく、Constellationが、簡単な解決策を拒み続けてきた問題について、複数の背景を横断して継続的かつ学術的に厳密な思考を重ねた成果であることを示す、最も明確な証拠です。

PBSについて

Proposer-Builder Separation（PBS）は、比較可能な設計としてではなく、対照例として触れておく価値があります。このセクションのすべての設計が、リーダーによる一時的な独占を構造的に制約しようとするのに対し、PBSはそれを受け入れ、MEV収益を再配分するためにその独占を中心として最適化します。ConstellationはPBSと明確に両立しません。リーダーの裁量がattestation記録によって制約されれば、専門builderが販売できるものは何も残りません。ユーザーへの被害を何も減らさないにもかかわらず、PBSがEthereumで主要なMEV緩和策になったという事実こそ、MCPが回避するために設計された失敗パターンです。

プロトコル外での先行事例

Constellationのリリース前から、Solanaエコシステムではすでに、MCPの一部がプロトコル外で再現されています。たとえばHarmonicは、複数の独立builderからブロック提案を継続的に収集・評価し、validatorがリアルタイムで競争的に選択できるよう提示する、オープンなブロック構築集約レイヤーです。プロトコルによって強制される検閲耐性、attestationクォーラム、リーダーの裁量に対する暗号学的制約がないため、形式的な意味でMCPではありません。しかし、Harmonicを実行するvalidatorは、すでに複数の同時ブロック提案から選択しており、これはMCPがプロトコルに組み込もうとしている中核的な仕組みです。BAMと合わせて、この2つは、プロトコルレベルの強制を待たずに市場構造の問題を解決しようとするエコシステムの取り組みです。これらのプロトコル外システムは、MCPのような特性に対する需要が現実に存在し、builderがConstellationのリリースを待っていないことを示しています。

未解決の問題

Constellationのホワイトペーパーはプロトコル仕様です。明示された前提のもとで正しさの特性を証明し、それ以外を適切に先送りしています。これはv0.9の提案として妥当です。以下はConstellationの欠点を並べたものではありません。MCPをSolanaに効果的に導入するため、最終的なSIMDと将来のiterationで対処すべき事項を整理したものです。 

これらの問題は、難易度が同じではありません。一部は仕様策定の問題であり、Anzaが通常のSIMDプロセスを通じて解決でき、また解決すべき設計判断です。ほかは、より広いMCP研究コミュニティでもまだ解決されていない真の未解決問題です。しかし、大規模にMCPを実装する最初のブロックチェーンを目指して道を切り開くうえで、認識しておく必要があります。単一のSIMDだけでこれらの問題を解決することはできません。この違いは重要です。両者を混同すると、Constellationの不足を過大評価するか、残る作業量を過小評価するおそれがあります。

比較的明確なSIMD作業には、以下が含まれます。

  • 手数料の分配：priority feeを提案者、attester、より広範なvalidator集合の間でどのように分配するかは説明されていますが、完全には規定されていません。ホワイトペーパーでは、priority feeはstakeに比例してエコシステムへ還元されるとしていますが、提案者、attester、validator間の正確な分配方法は定義されていません。
  • Validator報酬の構造：既存のvalidator報酬と比較して提案者がどのように報酬を得るか、またAlpenglowでvote transaction feeが廃止されることで、小規模validatorの採算計算が変わるかどうかです。
  • 導入の順序：Constellationは、2026年第3四半期に予定されているAlpenglowに依存します。SIMDではこの依存関係を明示し、標準のAlpenglowからConstellation+Alpenglowへの移行期間に何が起きるかに対処する必要があります。先にmainnetへ導入すべき前提SIMDはあるでしょうか。
  • 役割パラメータのガバナンス：提案者数（p ≈ 16）、attester数（q ≈ 256）、サイクル時間（△cycle = 50ms）、およびConstellationホワイトペーパーの表1にあるその他のパラメータは、単なる提案として示されています。SIMDでは、これらのパラメータをどのように設定・管理し、時間とともに変更できるようにするかを規定する必要があります。

より難しい問題（非同期実行、slashing、送信レイヤーのプライバシーなど）は、以下のサブセクションで扱います。MCP研究コミュニティが現在積極的に取り組んでいる問題であり、検討が必要です。Constellationの設計判断によって、将来的な特定の解決策への道筋が狭まることも、広がることもあるためです。

非同期実行

同期実行では、平文のトランザクションを受信した提案者、または単純な送信モデルのもとで早期にdecodeできる提案者は、そのトランザクションの内容を把握し、結果をsimulateできます。提案者は、現在のstateに対してトランザクションを実行し、swap価格、account残高の変化、その後のarbitrage機会を含め、実行結果を正確に計算できます。これにより、サンドイッチ攻撃は機械的かつ正確になります。攻撃者は大口swapを確認し、自らの利益を最大化するため、どの程度の規模でフロントランニングすべきかを計算できます。

非同期実行は、その優位性の後半部分を取り除きますが、MCPと組み合わせた場合に限られます。コンセンサスが実行前にトランザクションの順序をcommitする場合、トランザクション内容を確認できる提案者であっても、既知の最終stateに対して実行結果をsimulateすることはできません。順序付け時点では、そのstateが存在しないためです。情報面の優位性は、「このトランザクションが何を行い、どの順序で実行されるかを把握している」状態から、「このトランザクションが何であるかは把握しているが、最終的に順序付けされた集合との関係で何をもたらすかは分からない」状態へと実質的に狭まります。この利点は、提案者が最終的な順序を制御しないことに依存します。単一リーダーモデルでは、非同期実行だけではこの保護を提供できません。リーダーは依然として順序付けについて完全な裁量を持ち、実行時点に関係なく、自身のトランザクションを有利な位置に配置できるためです。攻撃対象領域を狭めるのは、制約された順序付けと遅延実行の組み合わせです。

非同期実行だけでは、レイヤー2を完全には解消できない点に注意が必要です。高度な提案者は、依然としてカテゴリーに基づく推測が可能です。たとえば、トランザクションが特定のliquidity poolにアクセスすることを確認し、正確な結果が分からなくても、おおよその方向を推測できます。それでも、最も機械的で収益性の高い搾取形態に対するハードルを大きく引き上げます。また、コンセンサスレイヤーで暗号学的なhidingを必要とせずにレイヤー2を狭める、最も明確なアーキテクチャ上の道筋です。特に、Sei Gigaはこのアプローチを選択し、MCPと並んで非同期実行を最優先のアーキテクチャ目標として追求しています。

ここで、じっくり考える価値のある自然な疑問が生まれます。なぜ非同期実行を先に追求しなかったのでしょうか。非同期実行はレイヤー2を狭めます。また理論上は、MCPがもたらす追加のプロトコル複雑性（新しいnodeの役割、UTC時計同期要件、未解決のslashing設計、2倍になるshreddingオーバーヘッド）を導入せず、execution layer内に限定された変更として追求できた可能性があります。 

この順序を支持する最も強い根拠は、非同期実行とMCPが異なる問題を解決することです。MCPは、非同期実行だけでは実現できない構造的な順序制約を提供します。実行結果をsimulateできなくてもトランザクション内容を確認できるvalidatorは、プロトコルが許可する期間内で順序に対する裁量を行使できます。MCPを先に追求する理由は、構造レベルでレイヤー1を制約でき、レイヤー1のほうがより明白で経済的に差し迫った脅威だからです。Solanaの既存の同期実行モデルに非同期実行を後付けするのは、そのcomposabilityの前提とprogramアーキテクチャを考慮すると、新しいchainへゼロから組み込むより難しいエンジニアリング上の問題です。Sei Gigaは初日から非同期実行を前提に設計できますが、Solanaにはその余裕がありません。MCPが先に追求された理由を説明するうえで、この実務的な非対称性は、理論上の優先順位に関する議論と同じくらい重要かもしれません。また、Alpenglowのアーキテクチャによって、Tower BFTのもとよりもMCPを実現しやすくなります。これについては、次のプロトコル複雑性に関するサブセクションで検討します。

この順序が正しいかどうかは、妥当な未解決問題です。Constellationはレイヤー2をそのまま残しますが、MCPがレイヤー3に新しい攻撃経路を導入することを考えると、これは問題です。そして2つの攻撃対象領域は相互補完的であるため、レイヤー2の攻撃がより収益性の高いものになる可能性があります。たとえば、大口DEXトランザクションを確認できる提案者は、そのpshredを遅延させて現在のbatch期間から追い出しつつ、同じ期間内で自らのトランザクションを使ってフロントランニングできます。レイヤー2の可視性とレイヤー3のタイミングゲームは、同じ攻撃対象領域における一体的な武器であり、Solanaの成熟に伴ってさらに高度化していくでしょう。

Slashing

暗号学的な強制は、主体の不正行為が検証可能な痕跡を生成する場合に有効です（署名の競合、有効性チェックの失敗、明らかに不正なcommitmentなどです）。Constellationがレイヤー1の検閲耐性に関する懸念を明快に解決できるのは、attestationを得たトランザクションを除外したリーダーが無効なブロックを生成し、その無効性を数学的に証明できるためです。タイミングゲームとレイテンシ操作は、このような痕跡を残しません。難しいのは、その種の不正行為が、個々の行為の水準では正当なネットワーク遅延と区別できないことです。不正行為は不在として現れるため、暗号学的に証明できません。利用できる唯一の手段は経済的抑止であり、それにはslashingが必要です。 

slashingの課題は、従来、証明可能な違反を必要とすることです。Constellationのfault witnessの仕組みにより、競合する2つのpshredに署名した提案者は特定され、除外されます。しかし、戦略的なレイテンシ操作はfault witnessを生成しません。equivocationも、二重署名も、オンチェーン上のfingerprintもありません。pshredの転送を数ミリ秒だけ、継続的かつ選択的に遅らせる提案者は、slashingの根拠を何も残しません。 

提案者のpshredが、多数のサイクルにわたり、その提案者自身の送信と競合するトランザクションについて、サイクル期間の最後の数ミリ秒に一貫してattesterへ到着する場合、適切に規定されたslashingの仕組みであれば、証明可能な悪意ある単一の行為がなくても、このパターンを組織的な操作の証拠として扱える可能性があります。従来のslashingでは、これに直接対処できません。標準的なslashingには、曖昧さのない自己完結した証明が必要ですが、転送を数ミリ秒遅らせただけの提案者について、そのような証明は存在しません。違いが現れるのはパターンです。

ここでは、レイテンシに基づく操作に対する規制当局の手法について、従来型金融が分散型金融の参考になる可能性があります。たとえば、Dodd-Frank法に基づくspoofingの取締りでは、個々の注文について意図を証明する代わりに、統計的パターン（cancel-to-fill比率、cancelタイミングの分布、価格への影響の相関など）を検出します。単一の事例については、意図的であったと証明できません。しかし、パターンは証明できます。個々の行為が客観的でなくても、統計的な規則性は客観的であるため、同じ論理が当てはまります。また、操作の経済的インセンティブは、従来型金融の高頻度トレーダーと同様に、permissionlessな提案者集合にも存在します。この類比が成立しなくなるのは、執行方法です。Dodd-Frank法は召喚権を持つ規制当局に依存しますが、trustlessな環境では、検出と罰則の仕組みをプロトコル自体に組み込む必要があります。

この問題に対処する仕組みの候補として、fisherman nodeを応用することを提案します。もともとVitalikによるデータ可用性の研究で導入されたfisherman nodeは、多数のサイクルにわたってattestationデータを監視し、統計的なfraud proofを組み込み済みのarbitrationプロトコルへ提出するobserverの一種として応用できます。個々の遅延到着は主観的です。しかし、nサイクルにわたって決定論的に算出されたパターンは客観的です。これはoptimistic rollupのfraud proofの基礎となる発想と同じですが、state transitionではなくタイミング動作に適用します。また、統計的なfraud proofのための組み込み済みarbitrationプロトコルは、現在開発中の新しいガバナンスツールと種類が根本的に異なるものではありません。そのツールにより、将来のガバナンス提案では、stakerが自身のvalidatorによるvoteを上書きできるようになります。Solanaがstakerによるvoteの上書きを可能にするインフラを用意するのであれば、fishermanベースのarbitrationシステムに必要な技術基盤は、見かけより近いところにあるかもしれません。

fisherman nodeに関するこの検討は、単一のオンチェーンfingerprintを残さない行為に標準的なslashingを拡張するより、信頼性の高い方向性です。また、現在進められているガバナンスインフラの開発によって、プロトコルがすでに支援できる態勢にある可能性もあります。 とはいえ、具体的な仕様では3つの制約に対処する必要があります。第1に、数千サイクルにわたるattestationのタイミングデータを統計的に分析するのは容易ではなく、validatorのハードウェア要件を簡単に引き上げる可能性があります。これは運用コストを増加させ、fraud検出の役割が一部の高度な主体に集中する可能性を生みます。第2に、閾値の仕様は、過度に保守的になってfalse positiveを生むことなく、正当なネットワーク変動と戦略的操作を区別できるほど堅牢でなければなりません。第3に、arbitrationプロトコル自体が新たな攻撃対象領域を導入し、協調的な報告によってこの新しいfishermanベースのシステムが悪用される可能性があります。arbitrationプロトコルの設計では、小規模参加者でもfishermanの運用を成立させるインセンティブの仕組みや、fisherman集合全体にcomputeを分散する集約方式などを通じて、これに対処する必要があります。

ここで提示する具体的な研究課題は次のとおりです。閾値パラメータを定義し、ネットワーク変動を考慮し、罰則の拡大方法を定める統計的なfraud proofフレームワークを、組織的なレイテンシ操作を抑止できるほど堅牢でありながら、正当な変動を処罰しないほど保守的で、さらに高度なoperatorによる敵対的な悪用に耐えられるほど単純なものとして規定できるでしょうか。これはMCP文献において最も技術的に難しい未解決問題の一つであり、より広い研究コミュニティでもまだ解決されていません。

Hiding

slashingは、タイミングとレイテンシの操作ゲームに対する唯一の解決策ではありません。hidingは、内容が可視な順序付けと、タイミングおよびレイテンシ操作の両方に対処します。非同期実行とslashingは、それぞれ単独では両方に対処できません。Constellationは部分的なhidingを実装しています（トランザクション内容は受信した提案者と、サイクル期限後のリーダーだけに表示されます）が、完全なhiding特性は実現していません。攻撃対象領域は、ユーザーが送信先として選ぶ提案者の数に応じて拡大します。この部分的なhidingは、完全に可視な場合と比較して攻撃対象領域を狭めますが、完全には閉じません。確定前にいずれの当事者もトランザクション内容を確認できない完全なhidingは、Constellationにとって未解決問題です。

理論上の理想形は、Garimidiらが示したアプローチであり、Hiding Erasure-Correcting Code（HECC）をprimitiveとして使用します。Constellationの標準的なReed-Solomonとは異なり、HECCは、閾値未満のshredを収集した敵対者がトランザクション内容について何も知ることができないという、情報理論的な保証を提供します。Constellationは、現在Solana上でTurbineを通じて稼働しているerasure codingを継続して使用することを選択しました。

最近の最も重要な進展は、JitoのBlock Assembly Marketplace（BAM）です。Trusted Execution Environment（TEE）を使用して暗号化mempoolを作成し、トランザクションを実行時まで非公開に保ちます。BAMは、Solanaにおける内容のプライバシーに対する実質的な需要が高まっていることを示しています。しかし、TEEベースのhidingにも制約があります。信頼の前提をハードウェアメーカーへ移すため、trustlessな運用を目指すプロトコルにとって重大な制約になります。より原則的な代替手段を提供するためthreshold encryptionを使用する道筋を、十分に検討すべきです。

BAMが重要なのは、Constellationが先送りしている内容の可視性の問題を、プロトコル外で解決しようとする試みだからです。Jitoは運用面で、Constellationがリリースされるより前に、BAMを通じて大規模なトランザクションプライバシーを提供できる立場にあります。これにより、application layerの解決策ですでに提供できるなら、プロトコルレベルのhidingに緊急性が残るのかという疑問が生じます。その答えは、信頼の前提と、プロトコルが理論上保証できるものと比較して、ハードウェアメーカーを「十分に」信頼できるかどうかに全面的に依存します。それでも、これを恒久的な解決策として扱うことはできません。短期的にはBAMがプライバシーを提供し、将来的なConstellationのiterationでは、長期的な代替手段としてthreshold encryptionが検討される可能性が高いでしょう。

Internet Capital Marketsのインフラを目指すプロトコルにとって、部分的なhidingは意味のある前進ですが、到達点ではありません。残る隔たりは、公正な市場構造と、現在存在するものより多少不公平さが軽減されたにすぎない市場構造との差です。 

プロトコルの複雑性

Constellationは、Solanaの誕生以来提案されてきた中で、構造面で最も野心的なアップグレードです。3つの新しいnodeの役割、UTC実時間の同期に依存する新しいタイミングモデル、新しいerasure coding処理、新しいメッセージ種別、新しいfailure modeを導入します。しかも、それらすべてが、まだmainnetで稼働していないAlpenglowの上に重ねられます。今がこの複雑性を引き受ける適切な時期なのかという問題は、単なる楽観論以上の検討を要する重大なものです。

Solanaは過去、2021年から2022年にかけてネットワークを苦しめた複数の停止障害によって、悪名高い評判を得ました。これらの障害には共通点があります。新しくthroughputの高いプロトコルを実環境の負荷下で運用する際、edge caseを推論することが本質的に難しかったために発生しました。その後、ネットワークが最近達成した2年以上の連続稼働は、反復改善の苦しい過程によって築かれた真の節目です。この実績は、Solanaの成熟度に対する信頼を裏付けます。 

現在、Constellation規模のプロトコルレベルの変更には、AgaveとFiredancerの両方での同時実装が必要です。そのため、互いに独立した2つの開発チームが、双方にとって新しいプロトコルsemantics、edge case、タイミングの前提について足並みをそろえる必要があります。Alpenglowだけでもこれを実現する複雑性はすでに大きく、Constellationによってさらに増大します。これは前進に反対する議論ではありません。むしろ、Constellationの最終的なSIMDに、複数clientでの実装に向けた明確な計画を含めるべきだという主張です。

金融機関はオンチェーンへの参入を始めています。大規模な停止障害がもたらす影響は、評判面でも経済面でも、2021年よりはるかに大きくなっています。コミュニティとして、Constellationがもたらす複雑性に率直に向き合う必要があります。最終的なSIMDには、グローバル金融システムにふさわしい厳密さで取り組まなければなりません。 

当然ながら、なぜ今なのかという疑問が生じます。本当にこのようなアップグレードのリスクを引き受けたいのでしょうか。この変化を緩和するため、時間をかけて段階的に実施できるアップグレードはないのでしょうか。前述の非同期実行とslashingの検討は、たとえば段階的な代替案が可能であることを示唆します。エコシステムが、相互補完的な複数のアップグレードを段階的に導入することで恩恵を受けるConstellationロードマップも可能です。これを慎重と見るか、減速主義的と見るかは、技術上の問題であると同時に価値観の問題でもあり、合理的な人々の間でも意見が分かれます。私たちは金融のためのシステムを構築すると同時に、意味の体系も構築しています。

これはすでに実際に進んでいます。Anzaは、200msのslotと2 slotのleader windowをConstellationより先にリリースすると確認しています。つまりSolanaでは、MCPの完全な複雑性を必要とせず、コミュニティが提起してきたシーケンスレイテンシの懸念の一部に対処する、有意なパフォーマンス改善が実現します。これについては次のセクションで説明します。200msのslotによってSolanaの確定経路がConstellationの予測オーバーヘッドに十分近づき、MCPの限界コストが小さくなれば、政治的な合意は大幅に得やすくなります。しかし、既存の主要な取引主体が200msを「十分に良い」と見なせば、Constellationの緊急性は低下します。200msのslotのみの場合と、200msのslotにConstellationを組み合わせた場合のレイテンシ予測を比較して提示すれば、コミュニティは追加コストと追加保証を比較評価できます。もちろん、Constellationの最終的なSIMDと提案される実装を待つ必要があります。

前進を支持する最も強い根拠は、Alpenglowが生み出す機会です。ConstellationはAlpenglowのセキュリティモデルを継承し、データ配布レイヤーとしてRotorを使用し、Tower BFTの複雑性が取り除かれる恩恵を受けます。Alpenglow上にMCPを追加する限界コストは、将来のコンセンサス設計でゼロから始めるコストより低くなります。競合がMCPのオンチェーン導入を検討していることに加え、検閲耐性を将来のアップグレードサイクルまで先送りすれば、必然的に独自の複雑性と政治的逆風が生じるため、待つことにもコストがあります。

今でなければ、いつでしょうか。

この複雑性は正当化できますが、その正当性は、厳密な仕様、段階的な導入、そして現在コミュニティが理論だけに基づいて議論しているレイテンシと帯域幅に関する主張の実証的検証によって示されなければなりません。 

ConstellationはIBRLに整合しているか？

シーケンスレイテンシとインクルージョンレイテンシ

控えめに言っても、Constellationに対するSolanaコミュニティの当初の反応は二極化しています。この反応によって、外交的ではなく明確な回答に値する重要な議論が表面化しました。最も鋭い形で示したのはCaveyの投稿で、「MCPとIBRLは根本的に両立しない」と述べています。市場構造を改善しようとして、MCPは直接的かつ疑いなく帯域幅を減らし、レイテンシを増加させると主張しています。これに対するTolyの回答も同様に直接的でした。「あなたは間違っている。MCPなしにインクルージョンレイテンシを短縮する方法はない」と述べています。

技術的には、どちらも正しいです。測定しているものが異なります。

MCPはインクルージョンレイテンシを短縮し、シーケンスレイテンシを増加させます。この2つは同じ特性ではなく、両者の混同が現在の議論における混乱の大部分を生んでいます。

シーケンスレイテンシは、トランザクションが送信されてから実行されるまでの時間です。MCPでは、attester round、50msのサイクル期間、batch assemblyの工程が、協力的なリーダーへの現在のTPU送信経路にはない時間を追加するため、必然的に増加します。合理的な主体が複数の提案者へ送信すると、より多くの帯域幅を消費するという批判は正しいです。coalesce期間がレイテンシを追加するという指摘も正しいです。これらはすべて現実のコストであり、ハード検閲を取り除くためのトレードオフとして測定し、コミュニティに提示すべきです。

インクルージョンレイテンシは、有効で手数料面において競争力のあるトランザクションが取り込まれることを保証する時間枠です。現在の単一リーダーモデルでは、この保証は実質的に上限がありません。つまり、特定のトランザクションを遅延または除外したいリーダーはそれを実行でき、阻止するプロトコル上の仕組みはありません。ユーザーがすでに経験しているレイテンシには、保留、スケジューリング、タイミングゲームから生じるすべての摩擦に加え、リーダーによる選択的な順序付けも含まれます。現実世界の確定時間にはこれらのゲームから生じるレイテンシも含まれるため、ユーザー体験全体は改善し得るという反論は、この捉え方では方向性として正しく、現在Xで進んでいるコミュニティの議論にも裏付けられています。 

本当の問題は、どちらのレイテンシを最適化すべきかです。

FIFOとFCFSとFBO

どちらのレイテンシを最適化すべきかを検討する前に、コミュニティが同時に議論してきた関連テーマ、つまりMCPがFIFOと両立するかどうかを理解しておく価値があります。

FIFO（First In, First Out）は、トランザクションを到着順に処理する一般的な順序付けの原則です。Umbertoは、この問いに対する答えには本質的に微妙なニュアンスがあると詳しく論じています。MCPは「確率的FIFO」と呼ばれるものを実現できますが、それには特定のインフラ条件が必要です。要するに、ユーザーが検閲を回避できるだけの数の提案者に地理的に近く、さらにそれらの提案者がアテスターに十分近いため、確実な取り込みに必要な40%のアテステーション閾値へ迅速に到達できる場合、ユーザーは実質的にFIFOによる取り込みを体験できます。つまり、競合者がそのトランザクションを観測して反応する前に、ユーザーのトランザクションが取り込まれます。競争は実行時ではなく、取り込み時に決着します。MCPは、そのような条件下でFIFOをプロトコルルールとしてではなく、創発的な性質として近似します。

問題は、Solanaの現在のインフラがこれらの条件を満たしていないことです。ステークは少数の地域に集中しています。そのため、クォーラム形成はステークが密集する地域へ到達する必要性によってボトルネックになります。この集中により、「地理的に有利な」観測者が送信中のトランザクションをフロントランできる時間的余地が生まれます。Constellationのデプロイに、確率的FIFOに必要な地理的分散とアテスター密度が伴うかどうかは、プロトコル設計そのものと同じくらい重要です。検閲耐性を保証しても、インフラの配置が疎であるためにレイテンシベースのフロントランニングを許すプロトコルでは、ホワイトペーパーが約束する市場の公平性は実現できません。

関連はありますが別の論点として、ConstellationはFCFSを実装できたものの、あえて実装しなかったのかという疑問があります。FIFOがインフラから創発する性質であるのに対し、FCFS（First Come, First Served）は、最初に到着したトランザクションが決定論的に処理されることを保証する特定のプロトコルルールです。Constellationも決定論的な順序付けを行う点には注意が必要です。トランザクションは各バッチ内で優先手数料順に並べられます。したがって、問題は順序付けがプロトコルによって強制されるかどうかではなく、優先手数料との関係において到着時刻がその順序を決めるべきかどうかです。

最近の議論では、当初提起されたものより根本的な反論が浮上しています。FCFSはトラストレスな環境ではまったく強制できない可能性があります。バリデータはオンチェーン上に証拠を一切残さず、トランザクションの到着順を偽って報告できます。これは、従来の意味ではタイミング操作をスラッシングできない原因となる「証拠の不在」の問題と同じであり、より創造的な解決策が必要になる可能性があります（例：スラッシングの小節で示した統計的パターン検出アプローチ）。誠実なバリデータは従う一方、不誠実なバリデータは密かに無視できるプロトコルルールでは、意味のある保証になりません。これにより、ConstellationがFCFSを採用しなかったことは、説明を要する設計上の選好ではなく、パーミッションレスなバリデータセットでは、少なくとも現在の前提のもとでFCFSをSolanaの厳格なプロトコル特性として実装すること自体がまだ不可能かもしれないという認識へと捉え直されます。現在の前提のもとで、パーミッションレスなバリデータセットにおいてFCFSを本当に強制できないのであれば、SIMDの役割はこの制約を明示し、優先手数料による順序付けが適切な設計上のデフォルトである理由を示すことです。FCFSを実装不可能かもしれない特性として位置付けず、Constellationが実装しないことを選んだ実行可能な代替案であるかのようにコミュニティで議論させれば、コミュニティ内にさらに大きな摩擦が生じます。

固定された時間枠内で優先手数料に基づいて順序付けすることは、目新しい妥協案ではありません。これは頻回バッチオークション（FBA）として知られ、学術的にも強く支持されている市場マイクロストラクチャ設計です。たとえばBudish、Cramton、Shimは、高速取引の軍拡競争：市場設計による対応としての頻回バッチオークション（2015年）で、統一清算価格を採用した離散時間バッチオークションは、連続時間市場が生み出す速度をめぐる軍拡競争を解消すると論じています。これにより、レイテンシベースの競争は価格ベースの競争に置き換わります。Constellationはこの考え方を取り入れ、優先手数料に基づく固定バッチ順序付け（FBO）を導入します。つまり、Constellationの50msサイクルはこの仕組みを具現化しています。各バッチ内ではトランザクションが到着時刻ではなく手数料で競い、同じバッチ内のすべてのトランザクションが同一の順序付け処理を受けます。これはまさに、先ほどSolana上でまだ大規模に存在していないと指摘したアプリケーションの種類です。

FIFO、FCFS、FBOをめぐる議論は、その大部分が同じ根本的な懸念に関するものです。すなわち、検閲耐性が保証された後に誰が順序付けを制御するのか、そしてConstellationが作ろうとしている市場構造は本当に公平なのか、それとも現在存在するものより不公平さが軽減されるにすぎないのかという問題です。Constellationは、最も明白な形態の操作を封じます。その代わりに何が生じるかは、ホワイトペーパーがSIMDでの決定に委ねている選択肢次第です。

では、何を最適化すべきでしょうか？

既存の取引アプリケーション（AMM、プロップデスク、CLOBなど）にとって最も重要なのは、シーケンスレイテンシです。これらのアプリケーションは、最も速く、手数料面で最も競争力のある者が勝つという前提で設計され、それに合わせてインフラを構築しています。取引を制約するのは物理法則だけであるべきであり、それによってSolana上で比類のないユーザー体験を提供できます。こうしたユーザーの一部にとって、Constellationは最も重要な指標において後退です。懸念されるのは、SolanaがかつてEthereumが犯したのと同じ致命的な過ちを犯す可能性があることです。つまり、パフォーマンスより市場構造を優先し、その結果として実行がチェーン外へ流出するおそれがあります。これは議論に値する正当なリスクです。

Constellationが実現を目指す金融アプリケーション（オンチェーンオークション、信頼できる取り込み保証を備えたオーダーブック、検閲耐性のあるDeFiプロトコルなど）にとって、適切な指標はインクルージョンレイテンシです。名目上の確認がどれほど速くても、フロントランや選択的な遅延が可能な指値注文は、取引所形式の注文より保証が弱くなります。Solanaは今や、統一清算価格を採用し、シーケンスが約定価格に影響すべきではないバッチオークション型の取引アプリケーションをサポートできます。これは現在のSolanaにはほとんど存在しない種類のアプリケーションであり、その理由はまさに取り込み保証が利用できないことにあります。Constellationは、Solana上にまだ大規模には存在しないユーザー向けに最適化された設計を、既存ユーザーを犠牲にして過度に重視しているとも言えます。この主張はすでにコアコントリビューターからも提起されています。

シーケンスレイテンシへの懸念は、現在Solanaが無期限先物取引でHyperliquidに大きく後れを取りつつあるという事実を踏まえて考える必要があります。Hyperliquidは、専用に構築された中央集権型シーケンサーを採用する無期限先物取引所であり、分散化を装うことなく、高度なトレーダーやアプリケーションが必要とする魅力的なサブミリ秒の実行体験を提供します。Hyperliquidは、暗号資産を真に「暗号資産」たらしめる中核原則を犠牲にしてでも、プロが実際に使いたいプロダクトを構築するという意図的な選択をしました。Constellationに内在するリスクは、確認経路へ通信オーバーヘッドとアテステーションラウンドを追加することが、Hyperliquidと同じトレードオフを逆方向に行うことになる点です。批判者は、トレードオフを正当化する金融アプリケーションがまだ存在しないにもかかわらず、現在Solanaが中央集権型の取引アプリケーションと競争できている潜在的なパフォーマンス上の優位性を犠牲にすることを否定的に捉えており、その声を強く上げています。

これは簡単に退けるべき懸念ではありません。シーケンスレイテンシとインクルージョンレイテンシのどちらを最適化すべきかという先ほどの問いは、現在の競争相手を踏まえたとき、Solanaがそのトレードオフを受け入れられるのかという問いに置き換えられます。

ただし、ここにはさらに深い問題があります。Hyperliquidとの比較から、IBRLの意味が時間とともに変化した可能性が明らかになります。TolyとRajがSolanaを構築した当初の動機は、検閲耐性でした。「DeFiプロダクトが数十億のユーザーとデバイスを引き付けられるようにするには、検閲耐性をスケールさせる必要があります……。これは解決すべき最も重要な問題であり、Solanaを構築する動機のすべてです。」IBRLはかなり後になって、その使命をエンジニアリングの言葉で表現したものとして登場しました。つまり、重要な指標で分散型ネットワークが中央集権型インフラに勝てるほど高速に構築するということです。それ以来、IBRLは独自のテクノオプティミズム的な意味を帯び、Solanaの文化的な時代精神に広く浸透しました。それは、エンジニアリング上の絶対命令であり、文化的な合言葉であり、世俗的な祈りでもあります。多くの人にとって、IBRLは手段ではなく目標となり、それが本来果たすべき検閲耐性という目的から切り離され、シーケンスレイテンシの最小化そのものが目的になっています。

この変質が起きているのであれば、実際にそう見えますが、Constellationは強固な文化的抵抗に直面します。コミュニティが、ガバナンス投票で可決に至らなかった議論の多いインフレ抑制案であるSIMD-228を否決したことを考えれば、これは新しい力学ではありません。広範な利益をもたらす提案であっても、コミュニティに深く根付いた先入観と衝突すれば否決される可能性があります。Constellationは、帯域幅とレイテンシのコストが現実に存在するため、より複雑です。しかし、それらがユーザー体験にもたらす正味の影響は定量化されていません。データがないまま、どちらかの方向へ確固たる結論を出すのは時期尚早です。コミュニティに欠けており、Anzaが説得力のあるSIMDのために提供する必要があるのは、現実的なネットワーク条件下で確認経路がどのようになるかを示す実証データです。AlpenglowはIBRLと整合していたため、この問題に直面しませんでした。トランザクションのファイナリティまでの時間を100分の1に短縮し、コンセンサスを合理化したからです。Constellationの妥当性は直感的には伝えにくいものの、今後のベンチマークが裏付けるのであれば、同じように現実的なものです。

コミュニティは、検閲耐性を高めるアップグレードを、それが最適化するよう設計されていないパフォーマンス指標で評価することになりそうです。より建設的な問いは、そのトレードオフに見合う価値があるかどうかです。現実に測定可能なコストがあります。リーダーがトランザクションを選択的に排除できないという、プロトコルによって強制される厳格な保証と引き換えに、シーケンスレイテンシと帯域幅が多少増加します。これは、Solanaが現在誘致しようとしている金融アプリケーションの前提条件です。

私たちの見解では、IBRLが常に目指してきたものを正しく解釈するなら、ConstellationはIBRLと整合しています。コミュニティが同じ結論に至るかどうかは、技術的な優位性よりも、実証的な根拠が示され、設計上の選択が説明されるかどうかに左右されます。

結論

Constellationは、MCPを本番ブロックチェーンへ大規模に導入する初の正式なプロトコルレベルの提案です。十分なクォーラムによってアテステーションされ、手数料面で競争力のあるトランザクションを有効なブロックから排除できないようにすることで、ハードな検閲を構造的に解決します。この暗号学的保証によって、Solana上で構築できるものが変わります。

Constellationが意図的に先送りしている事項も、同じように重要です。内容を可視化できる状態での順序操作はConstellationの送信モデルによって部分的に軽減されます。このモデルでは、トランザクションの内容を確認できるのは受信した提案者だけですが、残る攻撃対象領域はユーザーが送信する提案者の数に応じて拡大します。タイミングとレイテンシの操作は、現在の設計では処罰できない最大の未解決問題として残ります。今後考えられる道筋（非同期実行、スラッシング、秘匿化など）は示されていますが、詳細は定められておらず、それぞれに固有の複雑さがあります。Constellationのホワイトペーパーは、こうした境界について率直に記しており、最終的なSIMDも同様であるべきです。

Constellationが投げかける最も難しい問いは、それがもたらすトレードオフをSolanaが受け入れられるかどうかです。シーケンスレイテンシと帯域幅には現実に測定可能なコストがありますが、まだ定量化されていません。同様に、取り込み保証には現実の、まだ測定されていない利点がありますが、それを大規模に正当化できるアプリケーション基盤はまだ存在しません。コミュニティは、現在Solana上にほとんど存在しない金融アプリケーションのためのインフラへ、既存の取引アプリケーションを犠牲にする可能性を受け入れて投資するよう求められています。これが先見的なのか時期尚早なのかは、コミュニティがまだ持っていないデータによって決まります。

Constellationの妥当性は最終的に、現実的な条件下で今後実施される実証ベンチマークによって証明されるか、覆されることになります。200msのスロットだけを使用した場合と、Constellationのもとで200msのスロットを使用した場合で確認経路がどう変わるかは、Anzaが提供できる最も重要な数値です。それまでは、コミュニティは定量化できないトレードオフについて議論することになります。

私たちの見解では、ConstellationはAlpenglowが切り開いたプロトコルロードマップにおける正しい次の一歩です。Solanaが当初実現しようとしていたIBRLの解釈に基づけば、IBRLと整合しています。ただし、この見解は、グローバル金融システムにふさわしい厳密さをSIMDが備えることを前提としています。仕様、段階的なデプロイ、テスト、そして採用を求めるコミュニティへ提示する実証的な根拠のすべてにおいてです。

参考資料

関連記事

Heliusを購読

Solana開発の最新情報や新しい記事の公開通知を受け取れます

拡大画像