複数の同時提案者(MCP)の長所と短所。

著者:Maven11; 翻訳:ゴールデンファイナンスシャオゾウ

MCP(Multiple Concurrent Proposers)は、複数の提案者が同時にアクティブにできるメカニズムであり(Multi Context ProtocolやSecure Multi-Party Computation MPCと混同しないでください)、検閲問題に対する革新的な解決策です。 この記事では、ブロック提案に単一の提案者ではなく複数の提案者を持つことが、ブロックチェーンメカニズムの設計を改善するための重要な要素である理由を探ります。これには、ブロックチェーンメカニズムの仕組みや実装の意味などが含まれます。

MCPの核となる概念は比較的理解しやすい一方で、実際にその仕組みを採用しているブロックチェーンは現状でほとんどありません。 しかし、ある意味では、ビットコインのマイニングプールは、複数の同時提案者と同様に動作し、ビットコインのフルノードを実行している人は誰でも、オンチェーンでパッケージ化されたトランザクションを取得することができます。

! xoZWXtWoJyweT8MeGgBugxwm51IfcxfkToqRw1dr.png

一方、Solanaのマルチコンカレントビルダーメカニズムは、完全なMCPの実装と共通点がいくつかあり、少なくとも複数の異なる参加者がブロックビルディングに参加するという考えを反映しています(ただし、ブロックの提案ではありません)。 イーサリアムでは、ブロックの約95%がMEV-Boostによって構築されています。 同時に複数のアクティブなビルダーが存在しますが、オークションごとに勝者は1人しかいないため、Solanaが複数の同時ビルダーを通じて達成する利点はここでは維持されません。 実際、現在、複数の提案者がいつでもブロックを提案する権利を持つことができるチェーンはありません。

MCPを理解する最も直感的な方法は、それを2つのレベルに分解することです：複数の提案者が同時にブロックを提供し、これらのサブブロックの最終的な統合。

! UgLFVd0gPFQlFly7IsDhalymLrME44Xqp1yaA0W7.png

これらの提案者のグループは、すべてのバリデーターが関与することは現実的ではないため、サブカウンシル(イーサリアムの既存のメカニズムと同様)である可能性が高いです。 これは、個々の小委員会がステーキングプールに独占されないようにすることが重要であることも意味します。そうしないと、検閲や共謀の問題が発生する可能性があります。 さらに、伝説的なホームステーカーは技術的な能力が限られていることが多いことに注意することが重要です - MCPはシステムの複雑さを大幅に増やします。

以下はMCPが採用されるべき核心的な利点です：

複数の同時提案者をサポートする理由：

--検閲耐性の強化（現在のボトルネックにおいて特に重要）

--外部ソリューションに依存するのではなく、基礎プロトコル層で拡張する

--分散MEV（もはや単一の提案者やビルダーが取引のパッケージ化を決定することはありません）

MCP の実装によって直接明らかになる問題:

--取引の順序（パッキングと順序）における競争の激化（PGA現象の発生を引き起こす可能性は？）

--無効な取引によるシミュレーションの課題

--ハードウェア要件の向上

--無効なトランザクションのデータ可用性の問題

--最終性ツールを導入する必要があります

これらの特徴を項目ごとに分析しましょう。まずは利点から始め、その後、潜在的な問題が技術的に負担の大きいパブリックブロックチェーンの実施に障害をもたらすかどうかを評価します。

1. MCPの利点

(1)検閲耐性の強化

今日のブロックチェーンのほとんどは、決定論的なファイナリティメカニズムを使用しており、そのコンセンサスプロセスは、ブロックの内容を決定するために単一のリーダーに依存しています(わずかな違いはあります)。 ブロックがブロードキャストされた後、バリデーターの大多数はコンセンサスに達し、それを正規のチェーンに組み込みます。 イーサリアムは、小委員会のメカニズムを通じてブロックの生成を加速します(ただし、バリデーターの全セットがコンセンサスに達するには時間がかかります)。 MCPフレームワークでは、複数の提案者がそれぞれ独自のブロックを構築し、最終的にマージするため、ブロックエントリは単一のプリンシパル(提案者/ビルダー/リピータ、これらの役割はMCPによって破棄されるのが理想的です)からマルチチャネルモデルに移行します。 これにより、レビューがはるかに困難になります。 複数の包装体がある場合、システムの検閲耐性は大幅に強化されます。

現在のボトルネックの中心にあるのは(Flashbotsのようなチームが現状を改善していることに注意)、1人のビルダーがオークションを通じて1人の提案者からブロックビルディングの権利を受け取り、オークショニアとしての(信頼できる)リレイヤーが中央集権化をさらに悪化させることです。 イーサリアムのコアプロトコルは分散化されていますが、既存のオンチェーン取引プロセスは分散化されていません。 Solanaはまた、Jitoリレー/ビルダーの集中化に直面しており、リステーキングソリューション(最初のリアルイールドリステーキング「AVS」!)でそれを解決しようとしています。 ）。 ビットコインのユーザーは、フルノードを実行することで自律的に(低コストで)問題を解決することができますが、これはファイナリティを犠牲にしています - ビットコインは確率的なファイナリティを使用し、最長のチェーンルールに依存するMCPを実装するために必要な「ファイナリティツール」を欠いています。

（2）基礎プロトコルレイヤーの拡張

多くの場合、多くの開発がサードパーティのチームにアウトソーシングされ、L1(イーサリアムに限らない)の固有の設計上の欠陥を修正して、コアプロトコルの問題を解決します。 MCPを実装するということは、オフチェーンソリューションによって解決/引き起こされる問題に直接対処することを意味します。 これにより、ハードウェア要件が増加します(一方で検閲耐性は向上します)が、プロトコルユーザーによる分散化の必要性によっては、価値のあるトレードオフになる可能性があります。 特にSolanaは、Jitoの中央集権化に対処するためにこのアプローチを使用する可能性があります。 さらに、ブロック構築の作業が複数の関係者に分散されるため、ネットワーク全体の帯域幅需要は最終的に増加します。

(3)分散MEV**

MCPの最もユニークな効果は、特定のブロックのMEVを(単一の提案者またはビルダーによって独占されるのではなく)複数のアクティブな提案者間で共有できるようにすることで、元の「MEV宝くじ」モデルを変更することです。 バリデーター(主に法人)は安定した収益の流れを好み、このメカニズムは、トランザクションの再配置を通じてMEV(現状維持)の一方的な搾取を防ぐのにも効果的です。 この機能は、検閲に強い目標と相乗効果を発揮します。

注：もし過去の記事を読んだことがあるなら、CAP定理という用語に馴染みがあるかもしれません：これは分散システムが正常に機能するために満たさなければならない三つの基本的な特性です。

**C：**一貫性（consistency）を示し、ユーザー体験はすべてのユーザー間で統一されるべきであり、システムを使用するたびに単一のデータベースと対話しているように感じるべきです。

A: 可用性とは、私たちがよく「活性」と呼ぶもので、すべてのメッセージをシステムノードで処理し、後続のブロック/クエリに反映し、すべての命令を実行する必要があることを意味します。

**P：**はパーティション耐障害性（partition tolerance、または検閲耐性）を表し、システムは攻撃を受けたり、ノードネットワークが分裂しても、一貫性と可用性を維持する必要があることを意味します。

MCPはCAP定理の重要な要素（特に検閲耐性）を実現するための最良の方法の一つです——これらの要素はしばしば単純にゲーム理論の問題として分類されます。覚えておいてください：プロトコル自体を信頼し、ゲーム理論を信頼しないこと。

しかし、利点にはコストが伴い、CAP定理の運用は、優れた成果には常に対応する欠陥が伴うことを示しています - すべての特性を考慮に入れることはほとんど不可能です。 では、MCPの実装から生じる可能性のある問題を見てみましょう。

2、MCPが解決すべき課題

主な問題は、MCPがある程度、ブロック内での二重競争段階を引き起こすことです。まずは取引パッキング手数料、次に順序手数料です。順序手数料の処理は特に厄介です。なぜなら、第一段階では、ローカルプロデューサーは全体のビューではなく部分的なブロックビューしか持っていないからです。これは特定のブロック位置における最適入札を正確に計算することが非常に困難であることを意味します。

! ch8ILlNsaae7gXUMsXRIibmRDzmECCY1A73W5FDF.png

これは操作が難しいだけでなく、（オークションメカニズムの下で）私たちを優先Gasオークション（PGA）時代に戻すことになります。検閲耐性がより強化されている一方で、実質的にはMEV-Boostが解決しようとした問題を復活させることになります——競争的なブロックの高Gas料金の中央値、パッキング段階の排他的な価格設定などの現象。

ローカルビューとグローバルビューのソートの問題に加えて、トランザクション関連の課題は他にもあります。 これは特に、ブロックのローカルグローバルビューの伝播中に無効なトランザクションによって引き起こされた問題を指します。 フェーズの開始時(サブブロックが複数の提案者の共同構築ブロックにマージされる前)に、他の提案者のトランザクションに対する状態変更の影響を予測することは不可能であることを考えると、提案者が無効なトランザクションを互いに渡す場合があるかもしれません(これらのトランザクションがデータ可用性コンテンツとしてチェーンにアップロードされると、問題は悪化します)。 また、現在のMCPセットのバリデータがパラメータ制限に違反する可能性もあります(たとえば、最大ガス値を破るなど)。 これは、データ可用性の開示後に同じ状態変化を持つ低価格の取引を手数料ごとにフィルタリングできるアービター(またはプロトコル組み込みルール)を導入することで解決できますが、これにより、解決されたPGAのジレンマに戻ります。 しかし、オークションのような仕組みを全く使わずに、検索者やビルダーがブロックの場所をコントロールできるようにすると、スパム取引が殺到し、レイテンシーギャンブルが悪化することになり、これらすべてがプレコンポジションの可能性を損なうことになります。 イーサリアム(Pectraアップグレード後)とSolanaには追加の考慮事項があります:イーサリアムの提案7702は、ナンスによるトランザクションの無効化をもはや行わないようにし、Solanaにはトランザクションノンスがありません(アカウントのノンスはまだ存在します)。 これにより、トランザクションの有効性を判断するのがはるかに難しくなり、基本的にすべての組み合わせをシミュレートして正しい順序を決定する必要があり、ネットワークの帯域幅に大きな負担をかける可能性があります。 Solanaはハードウェアの参入障壁が高いため扱いやすいかもしれませんが、Ethereumは間違いなくハードウェアのアップグレードが必要になります。 しかし、イーサリアムの潜在的な解決策は、サブブロックマージフェーズ中に実行クライアント(ビルダー+リピーターではない)が実際に順序を計算することであり、ハードウェアのアップグレードの必要性を再確認しています。

! x7UlHJpjjdPKvjjZ3KnsdNRxm1Y0Ci2Zg34ezx9w.png

データの可用性(DA)に関しては、前述のように、これらの無効なトランザクションがチェーン上でリークされる(本質的に無料のトランザクションになる)可能性があることも重要な問題です。 これにより、コンセンサス前のフェーズで言及されたシミュレーション計算の負担がさらに悪化しますが、マージフェーズで無効なトランザクションを除外することはできます。 FOCILの既存の実装の一部(完全なトランザクションではなく送信アドレス)は再利用できます(ただし、シミュレーション検証のみに依存している場合を除くが、プロトコルルールではなく人間の介入により、他のトランザクションが無効になることでシミュレーションプロセスが妨げられる可能性があります)。

前述のように、MCPの実装には、同期の問題に対処するためのファイナリティツールが必要になる可能性が高く、これは上記のコンセンサス前の順序付けシミュレーションのセクションで示唆されていることです。 これはまた、ブロック提案のタイムゲームを遅らせる問題(MEV-Boostオークションで見られる現象)を引き起こし、提案者が自分のブロックを構築する前に他のブロックを見て、他の人の取引を無効にするトランザクションを意図的に送信する可能性があります(特に検索者にとって有益です)。 アンチタイムゲームのルールが厳しすぎると、より貧弱なバリデーターが排除されます(つまり、欠落しているブロックが増えます)。

タイムゲームの可能な解決策は、非同期実行(遅延実行)メカニズムを使用するMonadなどのチェーンの改良から借りることができます。 たとえば、1 つの期間におけるすべてのアクティブな提案者のトランザクション セットの完全な効果は、すべてのセットがビルドされるまで待機する必要があるというルールを設定できます。 これにより、複数の提案者に同じトランザクションが含まれる可能性が高いため、スループットが大幅に制限されます。 遅延実行とは、トランザクションがサブブロックに「含まれる」場合でも、最終的なマージブロックに到達せず、「含まれるがロールバックされる」トランザクションになる可能性があることも意味します(冒頭で述べた二重包含の問題と似ています)。 これには、このような操作 (ブロックの実行、伝播、ファイナライゼーションなど) を実行するために特定のファイナリティ ツールが必要になる場合があることに注意してください。

! Idvyka85De1Y0RFlDGYtAavBV04lPdP3OkgpJ9zA.png

私たちは主にイーサリアムに焦点を当てていますが、SolanaがMCPを積極的に推進していることは注目に値します。 この傾向は、Max Resnick が Anza に加わり、Anatoly が実装を公に支持したことで、さらに明らかになりました。 Anatolyの最近の記事では、次の主要な懸念事項を扱っています。

--異なるバリデーターからのブロックの到着時間が異なる場合はどうしますか（これは時間ゲームの可能性もあります）

--取引を統合する方法（前述の通り）

-- 帯域幅を最大化するためにバリデータ間でブロックサイズ(最大ガス制限)を分配する方法

--リソースの無駄遣いの問題（同じ取引が複数のサブブロックに含まれること、前述の問題にも言及されている）

SolanaにおけるMCPの実施に関する多くの問題は、通常Ethereumが直面している問題と呼応しています。しかし、Solanaは帯域幅とパフォーマンスの最適化により重点を置いているため、コンセンサスの堅牢性を確保しながら、ブロックリソース管理とブロックの統合がより重要になります。

この記事の冒頭で述べたもう一つの重要なポイントは、MCPはプロトコルを強化するだけでなく、プロトコルの拡張にも使用できるということです。 また、ソートメカニズムを通じて、アプリケーション固有のシリアル化(ASS)をプロトコル層に組み込むこともできます。 将来的には、XYZトランザクションの提案者になる代わりに、アプリケーション自体が提案者として機能し、独自のニーズに応じてトランザクションのセットをソートするシナリオ(Project Deltaが目指しているもの)や、逆に、アプリケーションが提案者にトランザクションの照合を提供するシナリオがあるかもしれません。 MEV税をアプリケーションパーティ(トランザクションイニシエーター)に移転し、それをMCPと組み合わせるオプションも検討されていることは注目に値します(これは、単一の提案者によって制御されなくなったため、実装が容易になります)。

最近の投稿で、MaxとAnatolyは、MCPは専用のシリアル化(分散型NASDAQの概念)を適用することで、より狭いビッドアスクスプレッドを実現できると主張しました。 現在の環境では、前述のように、ブロックを提案できるのは 1 人のリーダーだけです。 これは、価格が変動すると、オーダーブックのクォートパーティが特定のクォートを逆にしようとすることを意味します。 Solanaの単一提案者モデルでは、提案者が権力を独占しているため、Jitoオークションを通じてのみ行うことができます。 理想的には、Hyperliquidが示すように、マーケットメーカーがよりタイトなスプレッドを維持できるように、チャージバックリクエストを優先すべきです。 したがって、これはアプリケーションとしてのASSを通じて達成されることが望まれます-彼らはシングルリーダーモデルの下でオークションの力を独占しており、MPCを採用することでこの独占をなくすことができます。 ただし、この ASS ソリューションは、状態分離シナリオに限定される可能性があります。 この提案の本質は、アプリ開発者が特定のアカウントに対して優先的なアクション(注文のキャンセルなど)を定義し、特定のアカウントに対して最も優先度の高い取引(必ずしも最もチップの高い取引ではなく、流動性の生命線)を優先できるようにすることです。 核となる考え方は、通常の取引に手数料のしきい値を設定し、特定の優先取引が制限を突破できるようにすることです。

前文で議論されたパッケージ料金とソート料金の問題について、Solanaはすでに対策を講じているようです。パッケージ料金はトランザクションバリデーターに帰属し、ソート料金はプロトコルに支払われ（破棄されます）、複数のサブブロックをマージする際には、事前に設定されたソート料金に従ってマージ後のトランザクションセットをソートして実行するだけです。

! iYPNZnNzqp5tf0XoZCz0g88JRxA3c57RpBWm2aOw.png

上記のメカニズムは、Solanaのブロック伝播メカニズムTurbineと緊密に連携しています。リーダー（MCP）はデータのシャーディング（shreds）を使用し、それをTurbineのツリー構造内の中継ノードに送信します——これらの中継ノードはすべてのリーダーからのシャードを含む必要があります。中継ノードは単一のコンセンサスリーダーにシャード確認メッセージを送信し、そのリーダーは十分な数のメッセージフラグメントを収集した後にブロードキャストしてコンセンサスを達成しなければなりません。

Alpenglowのリリースにより、シングルレイヤーリレーノードアーキテクチャとオンチェーン投票メカニズム(現在は完全にオンチェーン)の排除を考慮して実装が調整される可能性があります。 これらの変更により、バリデータの運用コストが削減され、バリデータの数が増え、技術的に力の弱いプレイヤーを引き付けることが期待されます。 これは分散化には有益ですが、チェーンのパフォーマンスに影響を与える可能性があります。 SolanaがMCPを実装した後、バリデーターの失敗にどのように対応するかを探る価値があります。

**3、**他のエコシステムにおけるMCP実践

CosmosエコシステムはMCPの実施を進めており、著名な機関Informal SystemsがBFTコンセンサスモデルに基づく複数提案者の規範を発表しました。彼らは安全なブロードキャストプロトコルを採用し、投票拡張メカニズムを通じて各バリデーターのサブブロックが他のバリデーターによって確認される必要があることを要求しています。Tendermint/CometBFTのブロック構築モジュールは、その後、これらのサブブロックの集合について合意に達します。これは特定のバリデーターが大量のサブブロックを生成することを意味します。

セイは、セイギガプロジェクトを通じてMCP(最初に実装されるプロジェクトとなることを目指している)を開発していますが、これはアウトバーンの記事(強く推奨)に部分的に触発されています。 中心的な考え方は、データの可用性をソートから切り離し、複数の並列チャネルを通じてデータの可用性を加速し、最終的にグローバルチェーンにソートすることです。 これは、バリデーターが一定期間ブロックを同期するのではなく、ブロックを生成し続けてグローバルビューに統合するというイーサリアムのMCPの概念とは少し異なります。

Commonwareのパトリック・オグレイディも関連するソリューションを探求しています。

最後に、Deltaプロジェクトは検閲耐性の公告板機能を兼ね備えたベースレイヤーを設計し、各アプリケーションが独自の並行ソートを実行し、生成されたブロックが最終的にグローバルステートレイヤーに決済される。