MEV-Boost : Relayer

Relayerに関する情報のまとめ

Relayerの問題

①インセンティブがないこと

②運用コストが高いこと

①②にに付随して集権化していること

③blockを検閲できること

Relayの問題の解決策

①②の解決策は、A.Relayerがrevenueを得ること、 B.relayerのcostを下げることが挙げられる

A. revenueを得るの方法としては、MEV関係者の中で分配する方法か、MEV外部から資金を流入させる方法の２つがある

MEV関係者での分配

Yukiさんのpostをみる限りまだ決定だはなさそう

考慮事項：関係者のインセンティブ調整、builder-relayの統合

MEV関係者内からの分配では、relayerのprofitは+にはならない。

ただ、0に近づけることにより、MEV外部の収益を組み合わせて+にすることはできる

MEV外部からの資金流入

low latency propagation と POFにより、bloXrouteは一定の収益を上げることができた

ここに関する議論は少ない

B. Optimistic Relay v2が今の所の最適解

https://scrapbox.io/files/65376ef33e7bd6001b307b76.png

/icons/hr.icon

Post mortem: April 3rd, 2023 mev-boost relay incident and related timing issue

proposerが有効でない署名をrelayに提出し、builderがproposerにblockの中身を渡してblockの中身をunbundleされた

/icons/hr.icon

Analyzing Missed Slot Through The Lens of Relays – A potential path for relay incentivization

Problems with existing proposals

現在のRelayのインセンティブは、bidの一部をrelayerに渡す議論が主流になっている

Competitive Relay : 1番目のbidと2番目の他のrelayのbidのdeltaの数%をrelayer feeとしてもらう

そうなるとCompetitiveRelayにbidが集中し集権化が進む

その際の疑問点

slotミス率はどのようになるか

slotミスのコストはどこくらいになるか

ミス率を軽減する術はあるか

Analysis of Slot Miss Rate via Single Relay Broadcasting

1ヶ月間の統計

single relayのslot miss率 0.21%、cooperative relayは0.067%

4つのslotミスのうち、３つがsingle relayによるものだった

slotミス率は平均して0.2%

single relayのミス率が高い理由

netwotk topology : 地理的に遠いとき通信に時間がかかり逃す可能性

validator registration

Relay operation

builder's bid bias :

timimg game : slotの受け取りを伸ばすほどbidは上がるので、slotの承認を遅らせる

Cost of competitive relays = Cost of proposers missing slots

0.1442ETH per missed slot.

Missed slot = Relay Incentives??

Direct Channel Relay Communication Network (Relay Mesh Network):

低遅延ネットワークを構築しているrelayに対して料金を支払う

Enshrining Missed Slot Penalties (a nice-to-have minimal viable enshrinement for relay incentivization):

slotをミスした際にペナルティーを課す。そうすることでBaaSの重要性がます。

Challenges ahead With Missed Slot Penalties

solo stakerのミス率が4~6%なのに対して、sophisticated stakerのミス率は0.2~0.4%

stakeの上限を上げ、stakeに応じてペナルティーを変動させる

Concludiong thought

データからわかったこと

timimg gameに晒されないため、単一relayではmiss slotの割合が2倍になる

slot missの可能性は、強調するリレーが増えるにつれて指数関数的に減少する

slot missはproposerにとっての機会費用となり、relayの勝利になる

インセンティブの付け方

低遅延メッシュネットワークの構築

slot missに対するペナルティを付与することで、proposerがslot missしないようにする

/icons/hr.icon

Builderelays: Builder-Relay Vertical Integration

builderがrelayを持つことでlatencyを下げることができ、block構築でより優位に立つことができる

Builderelays Are Coming

Titan が Relayを開始した

PEPC-Boost

Ultra Sound Relay Monetisation (for PG)

USに対するbid最高額と他のrelayに対するbidの最高額の差分をpoolに入れる

Staking Yield Maximisation

latencyを下げるほどvalidator payoutsは大きくなる。したがってnode-providerはbuilderelaysに接続したがる

Implications

relayになるためにはvalidatorに登録してもらう必要があり、builderは競争環境が厳しいため、builderelayの参入障壁はかなり高くなっている

Wat do?

Reduce inefficiencies in disintegrated system

現在のrelayをbuilderelayに寄せて、builderelayになるインセンティブを下げる

Multi-relay queries:

複数のrelayからのblockを受け付ける？ことで一つのrelayに密接に関わるインセンティブを下げる

SUAVE

Relayのプログラムはなるべくopen sourceにする

block構築のロジックの一部分をproposerに戻す

builderにstakeとin-protocolを強制する

/icons/hr.icon

The Pursuit of Relay Incentivization

疑問

builderは数が少ないのでvalidatorがtop4のbuilderに繋げばいいのでは？

Relayerの重要性

protocol levelのcensorship riskを軽減する

Validatorの収益機会を均等にする

KZG commitmentなどの負荷を軽減できる

Relayeは引き続き重要で、Relayを改良する際は関係者の利害を一致させることが重要

bloXrouteもlow-latency propagationで収益を上げたが、optimistic relayで優位性はなくなった

この点は、違う意見を持っており、tx incertなのでまだ収益は上げれる。order flow auctionのようなもの。ただbuilderの数は少ないのでそこまで大きな収益ではないのは事実

Relay Union: an attempt to move on from public good via social consensus

Who should pay for the relay cost?

Relay’s leverage over builders:

「cost of operating & developing relay - additional profit from latency advantage in co-locating with relay << cost of paying external relay fee」 の場合はbuilder-relayのintegrationリスクがある

builder-relayのintegrationリスク

実際のbidを隠す可能性がある

ただ、そもそも、新しいrelayに接続しようと思わないし、見えないコストもあるのであまり起こらないであろう

Relay’s leverage over validators:

Payload deliveryが高いrelayは多くのbuilderと繋がっている（特にtop 4）

How should the relay be paid? (e.g. who sets the fee and how?)

If builders pay: Real-time payment

builderからのbidがあった場合、relayerが2番めに高いbidのtxをproposerに渡すことで、1番目のbidと2番目のbidの差分を分配する

問題

deltaを最大化するためにパフォーマンスの高いrelayにbidを集め、よりrelayerの集中化をより促進する可能性がある

If builders pay: Deferred payment

スマートコントラクトで管理できるようにして、そのスマートコントラクトからrelayの使用量を支払う

If validators pay: Real-time payment

fee-recipientの追加, PEPC/EigenLayerで入札額の数%を徴収

If validators pay: Deferred payment

Concluding thoughts

Public good (not charging a fee) will always lead to a race to the bottom

latency-optimizationで優位性をとっても、同じようなことが他のrelayerでも行われたら価値はゼロになる

A social consensus among major neutral relays to pull out of public good is necessary:

Easier to charge builders

validatorよりbuilderの数が少ないので合意形成をとりやすそう

The tug-of-war between relay incentivization and centralization

In devising our relay incentivization scheme, we have to consider the centralization risk of the relays that emerge from latency competition. Ideally, we would want a coopetitive relay market that ensures collaborative payload deliveries for maximum liveness while still allowing monetization, which could be derived from latency advantages.

/icons/hr.icon

Realigning block building incentives and responsibilities - Block Negotiation Layer

背景&概要

MEV-BoostにおいてRelayerは重要な役割であるにもかかわらず、インセンティブがなくリスクしかない

そのため、

また、proposer からblock構築の

Proposer は どのようなblockが欲しいかなどのProposerIntentをオンチェーンで登録する

Curator

MEV-boostのrelayerと同じ立ち位置にいる

Curatorはblock builderからblockを受け取り、Proposer Intentと照らし合わせてテストする。

Curatorが提出したblockのから、最も高いbidを選ぶ。この時点ではfullblockではない。

Curatorの中でblockが選ばれた後、そのブロックを選んだCurator以外のCuratorでcommiteeが形成され、full blockの有効性を検証する。

つまり、今まではProposer-Relayer間でRelayerがblockの不正をしてないかの検証をしていたけど、BNLではCurator間でblockの検証している

Curator staking

信頼性はcuratorにdelegateされたETHの量で測ることができる

Stakingの要件

Cutarotのstake総額は、各関係者からの複合的なbucketであるべき

Curatorはbidする額よりも多くのstakeを持っているべき

validatorが大きな権限を持っているべき

報酬体系

best bitと同じ額？

With the same amount - Block validity attestations (committee participation) and returning the best bid

報酬はcuratorの稼働量に比例される

curatorが少なければ、報酬が多くなる

blockが早く提示されればされるほど報酬は高くなる

future

Block size / Latency + Inclusion

intentにすることでblock構築をcurator layerに完全委任できる

所感

ProposeをIntentにするのはおもしろかった。全てが抽象化されていく。

CommitteでvalidateするのはCuratorが不正を行なってないか確認するためか？それともtx自体の検証を行なっているのか？

PoSの中もCommitteもCuratorのcommiteeに代替するものなのかも。そうだとしたら、新しいチェーンを作る（ETH3.0）くらいのものになりそうで、そこまでやるメリットはこの提案からは感じれなかった