イーサネット・サプライチェーンの未来：主流提案の説明

Author:Jon Charbonneau, DBA Associates  Source:X, @jon_charb Translated by Good Oba, Golden Finance

- 立会人の役割を提案者の役割から分離する、一般的な市場構造の設計コンセプト。現在のイーサリアムのプローバは、現在両方を行っています。

Design Objectives

ここで理解すべき重要な点は、これらの提案は、Exのような複数の別々の目標を持つということです。

1) 時限ゲームの分離: イーサ検証者は、時限ゲームに参加するインセンティブを与えられます。">今日行っている。PBSがブロック構築/トランザクションのシーケンスの複雑さを経験豊富な参加者に隔離するのと同じように、バリデーターを経験豊富な参加者に隔離することが目標です。目標は、バリデータを分散化された状態に保つことである。

2）MEVの破壊: MEVの破壊は、まさにこれらのデザインを完璧に体現しており、以前のMEV破壊のアイデアよりもはるかにクリーンです。はっきりさせるために、私は個人的に、これを行う能力は、これらの提案の動機というよりは、潜在的な副産物だと考えています。

また、事前のコンフィギュレーションをとても気にする人もいて、EAはその点ではずっと優れています（私は個人的にはあまり気にしていません）。

スロット時間と時間制ゲーム

時間制ゲームでは、集中化に対するスロットの長さの相殺効果があります。相殺効果の大きさは、異なる仮定に依存するため、分析が複雑になります。

• タイムスロットが短いと、MEVがタイムスロットの長さに応じて超線形に成長するため、集中化のインセンティブが減少し、MEVが減少します（例えば、LVRが減少します）。

• タイムスロットが短いと、タイミングゲームの効果が増幅され、集中化インセンティブが高まります。これは、存在するトレードの種類に関係なく当てはまります（例えば、スロットの最後まで存在しないトレードをより多く含めることができます）。  

APSとマルチブロックMEV

マルチブロックMEVとは、複数のスロットをコントロールすることを意味します。ブロックMEVとは、複数のスロットを連続してコントロールすることで、超直線的な報酬が得られることを意味します。(例えば、ブロックNとN+1を連続して提案した場合の報酬と、ブロックNを単独で提案した場合の報酬＋ブロックN+1を単独で提案した場合の報酬）。

今日、このようなことは実際には起こりません。単にLidoやCoinbaseのような会社が良い人たちだからです。なぜなら、リドやコインベースのような会社はいい人たちだからです。彼らは、数ブロックの予言マシンを不正に操作したりはしないでしょう（たとえ彼らが大きなステークを持っていて、そのため常に多くの連続したブロックにアクセスできるとしても）。同様に、彼らは同じ理由で、契約外のビルダーにそれらの権利を売らないだろう。

しかし、誰でも多くの連続したスロットを買うことができるマーケットプレイスを明示的に作れば、誰でも簡単に安価にマルチブロックMEVを行うことができるようになります。彼らは、そうする気がない誰よりも高い価格で入札することができるだろう。私たちはその決定を、整列した大きなバリデーターではなく、利益を最大化する人たちに委ね、それが簡単にできるようにしています。

包含リスト

マルチブロックMEVを防ぐために包含リストを使うことはできますか？まあ、そんなところですが、実際にはそうではありません。もしこれらが今日想定されている限定的なILであれば、特定のトランザクションのサブセットのみを含むことを余儀なくされ、トランザクションを含むことはできても並べ替えることはできないだろう。

ILをより堅牢にし、マルチブロックMEVを防止するには、ILを各IL委員がメモリプールの完全かつ現在のビュー（しばらくの間レビュー中と思われる一握りのトランザクションではなく）にすることができます。また、単に含めるだけでなく、並べ替えを強制することもできる（例えば、優先順位コストで）。ブロックを作成するには、これらのリストをマージする必要がある。さて、これでILは、バッチ内の優先度コストによるソートを持つ、オールブロックのマルチブロック提案者スキームとなった。(同じものを作っていると言う人もいるかもしれない)。

タイムスロットを逃した場合により大きなペナルティを適用することで、マルチブロックMEVを緩和することもできますが、これはまだ不完全です。ですから、基本的に、これらの問題が現実的に解決可能であるかどうかは、まったく明らかではありません。

さらに、提案者がILをまったく使わないという懸念も残っています。私たちは、誰もがILを使用する動機付けを与えるような設計が必要であり、また、ILに何が含まれているかについてもっともらしい否認が可能な設計が必要である。これは言うは易く行うは難しである。もし提案者がILによってCRを強制することができない/しないのであれば、なぜ本当に多くのバリデータが必要なのか、あまり明確ではありません。