Flashbot / MEV-boostの概要と課題、これからについて
Special thanks to Vita for reviewing this article and discussing topics related to MEV-boost
Ethereumのコミュニティーでは最大級のカンファレンスであるETHCCがパリで行われました。
ETHCCではMEVに関する登壇やサイドイベントを多く見かけ、Ethereumの中でもMEVに関する注目が高まってきています。
MEVはEthereumのblock構築などEthereumの根幹に関わる議論と密接に関わっており、EthereumがEthereumであるために非常に重要な分野です。
本記事ではMEV議論の中でもFlashbotが提供するMEV-Boostの仕組みと課題について書きます。
なぜFlashbot/MEV-boostなのか
Flashbotの話に入る前に、「なぜFlashbot/MEV-boost」について記事を書くのか」について説明します。
EthereumはPoSに移行してから、下記のような手順でblock構築がなされています。
- 32ETHをstakeすると確率的にblockを構築できるValidatorになれる
- block構築が始まると、Validatorの中から無作為に、block構築を提案できるProposerが選出される
- 選出されたProposerはblockを作成し、Validatorで構成されるCommitteeに提出する
- Committeから一定数の承認を得る
- 一定数の承認を得たblockがネットワークに伝播される
https://www.coinbase.com/ja/cloud/discover/protocol-guides/guide-to-eth2
現状の仕組みでは、blockの構築を提案できるProposerに強い権限があり、トランザクションを検閲やProposerの利益になるようなトランザクションの恣意的変更などができてしまいます。
また、収益性の高いblockを構築するためには独自のアルゴリズムや収益性の高いトランザクションをProposer自身で集める必要があります。そうすると、業者としてやっているProposer/Validatorに収益がよってしまい、solo stakerの参入障壁を上げることになってしまいます。
そのようなProposerによる不正やProposer/Validatorの収益機会の分散と参入の促進のために、Proposerが有しているblock構築権限を分離する Proposer-Builder Separation(PBS) の提案が2021年から行われています。
PBSに関する資料はこちらのサイトにまとめられています。
このPBSには大きく分けて２つあり、プロトコルレベルで実現する in-protocol PBC と、アプリケーションレベルで実現する out-of-protocol PBS があります。
in-protocol PBSには、Two-spot、PTC、PEPCなどがありますが、それらの実装はプロトコルの改修が必要なため実現するまで時間がかかります。明確な実現時期は決まっておらず、3~5年かかるとも言われています。
そこで、PBSを部分的にしようとしたものがFlashbotが提供するMEV-boostです。
MEV-boostは、Ethereumのコンセンサスを変更することなく、部分的にPBSを実現しているため、「out-of-protocol PBS」に該当します。
MEV-boostとは収益性の高いblockを構築し提案してくれるサービスであり、ProposerはMEV-boostに接続することでblockの構築をMEV-boostにアウトソースすることができます。
MEV-boostはプロトコルの改修を必要としないため、素早く実現することができ、リリースしてから数ヶ月で90%以上のblockがMEV-boostによって構築されるようになりました。
ただ、MEV-Boostは部分的にPBSを実現しようとしており、PBSの目的であったblock構築におけるproposerの検閲や不正を完全に防ぐことはできていません。
MEV-Boostの概要
ここからは、MEV-boostでどのように収益性の高いblockの構築を行っているのか解説していきます。
MEV-Boostを使わない場合、block構築は緑の斜線の箇所で行われていました。
具体的には、ProposerはEthereum利用者のトランザクションが集まっているMempoolからblockに取り入れたいトランザクションを選び出し、それらのトランザクションをもとにExecution Clientを使ってexecution payloadを作成し、Consensus Clientの中でValidatorにblockを渡すことでblock構築が行っています。
しかし、MEV-boostを使うことで、Proposerはblockの作成をMEV-boostにアウトソースし、Consensus Clientでのblock提案のみに作業を減らすことができます。
MEV-Boostには、Searcher, Builder, Relayerの３つの役割にがあり、それぞれが収益性の高いblockを構築するために動いています。
https://docs.flashbots.net/flashbots-auction/overview#technical-architecture
- Searcher： ArbitrageやLiquidationなど収益性のあるトランザクションを見つけ出し、Builderにbundleとして渡す役割
- Builderは、Searcherから受け取ったbundleやMempoolからのトランザクションをもとに、独自のアルゴリズムで価値の高いblockを作成し、Relayerに渡す役割
- Relayerは、複数のBuilderから受け取ったblockの中でも一番高いblockをProposerに渡す役割
ここからは、具体的にそれぞれの役割と、各者間でどのようなデータが受け渡されているのか説明します。
Searcher
Searcherの概要
広義の意味でSearcherは、P2PのMempoolを使うのではなく、Floshbotのprivate transaction poolを使うEhterum利用者のことを指します。
具体的には下記のような利用者が挙げられます。
- arbitrage や liquidation botのような、早くトランザクションを確定させたいbot運用者
- Uniswap traderなど、トランザクションをフロントランから守りたい利用者
- AAのガスレストランザクションのような、特殊な機能をもつDapps事業者
Searcher → Builder
Builderは各自でRPC endpointを提供しているため、SearcherはそのRPC endpointに対して、eth_SendRawTransactionやeth_sendBundleなどのRPC methodを利用してトランザクションを渡します。
各BuilderのRPCはこちらのサイトにまとめられています。
https://www.mev.to/builders
Builderに渡すトランザクションはFlashbotの中ではよくbundleと呼ばれ、実際にbundleをBuilderに送信するスクリプトはこのようになっています。このbundleは単一のトランザクションのみの場合もあれば、複数のトランザクションがまとめられる場合もあります。
const ethers = require("ethers.js");
const {
FlashbotsBundleProvider,
} = require("@flashbots/ethers-provider-bundle");
const provider = new ethers.providers.JsonRpcProvider({
url: ETHEREUM_RPC_URL,
});
const authSigner = new ethers.Wallet(
"0x2000000000000000000000000000000000000000000000000000000000000000"
);
const flashbotsProvider = await FlashbotsBundleProvider.create(
provider,
authSigner
);
const signedBundle = await flashbotsProvider.signBundle([
{
signer: SOME_SIGNER_TO_SEND_FROM,
transaction: SOME_TRANSACTION_TO_SEND,
},
]);
const bundleReceipt = await flashbotsProvider.sendRawBundle(
signedBundle,
TARGET_BLOCK_NUMBER
);
ETHEREUM_RPC_URLはbundleを送信したいBuilderのRPCを指定します。
RPCを経由してBuilderにbundle渡すだけなので、例えばUniswapで取引する際にフロントラン防ぎたい利用者は、MetamaskのRPC URLをBuilderのRPCに変更するだけでもBuilderにbundleを送信することができます。
Metamaskでトランザクションを送信する場合、eth_SendRawTransactionが使われますが、全てのBuilderはこのRPC methodに対応しているわけでない点には注意が必要です。
BuilderのRPCはPrivate RPCやProtected RPCと呼ばれることが多くありますが、これはMempoolにトランザクションを投げるのではなく、MEV-boostの仕組みを使ってBuilderにのみトランザクションが公開されるため、このように言われています。
Searcherの実例
実際にこちらのトランザクションがSearcherからBuilderに渡されたbundleだと考えられます。
https://etherscan.io/tx/0x52fd6fcc63d4c51a903b84c035981d143331528601b39d14a1b1ad1950a83974
このトランザクションでは、UniswapとSushiswapを使ってIceTokenのArbitrageを行っており、約0.0086ETHの収益を得ています。（①でWETHが出入りしており、その差額が利益になります）
Searcherが獲得した収益はSearcherだけに還元されるのではなく、BuidlerとProposerにも分配する必要があります。
なぜかというと、MEV-boostでは収益性の高いblockがProposerに渡されるため、MEVの収益を多く分配してくれればしてくれるほど、Proposerにblockが渡る可能性が高くなるためです。
Searcherとしてはせっかく見つけたMEVの機会でもトランザクションをblockに取り入れてもらえなければ収益を得ることができません。
そのため、MEV-boostの中で、SearcherはBuilderに収益の一部を分配し、さらにBuilderがProposerに収益を分配するように動きます。
実際に、Arbitrageで得た収益を、②でbuilderに0.00635...ETH、③でSearcher自身のアドレスに0.00224...ETH送信して分配していることがわかります。
非常に小さいですが、0.00224ETH - 0.002ETH（ガス代）がSearcherの収益になります。
こちらのトランザクションは多く収益が挙げられているので、こちらもご覧になってください。
Builderが提案したblockがProposerまで渡らないとblockとして取り込まれないので、bundleとして渡したトランザクションが早く確実に確定されるわけではないことには注意しておいてください。
Builder
Builderの概要
https://docs.flashbots.net/flashbots-auction/overview#technical-architecture
Builderは、「Searcherからのbundle」、「private order」、「Mempool」などから、トランザクションを集め収益性の高いblockを生成します。
収益性の高いblockを構築するためには、収益性を高める独自のアルゴリズムと、より多くの価値の高いトランザクションを集める必要があり、Builderは各自の戦略でblockの構築を行っています。
例えば、Proposerがどのblockを受け取るかはblockの収益性で決まるので、賄賂のようなものを渡してblockを受け取ってもらいblock構築のシェアを伸ばしたり、Searcherを優遇してより多くのorder flowを獲得したりなど、さまざまな戦略があります。
Builderの特性に関してはこちらの記事がよくまとまっています。Builderの特性と戦略について詳しく知りたいからはご覧になってください。
Builder→Relayer
Builderはblockを作成したら、Relayerが提供するAPIのsubmitBlockを通してfull blockを送信します。
実際に送信するデータはこのような形になっています。
{
"message": {
"slot": "1",
"parent_hash": "0xcf8e0d4e9587369b2301d0790347320302cc0943d5a1884560367e8208d920f2",
"block_hash": "0xcf8e0d4e9587369b2301d0790347320302cc0943d5a1884560367e8208d920f2",
"builder_pubkey": "0x93247f2209abcacf57b75a51dafae777f9dd38bc7053d1af526f220a7489a6d3a2753e5f3e8b1cfe39b56f43611df74a",
"proposer_fee_recipient": "0xabcf8e0d4e9587369b2301d0790347320302cc09",
"gas_limit": "1",
"gas_used": "1",
"value": "1"
},
"execution_payload": {
"parent_hash": "0xcf8e0d4e9587369b2301d0790347320302cc0943d5a1884560367e8208d920f2",
"fee_recipient": "0xabcf8e0d4e9587369b2301d0790347320302cc09",
"state_root": "0xcf8e0d4e9587369b2301d0790347320302cc0943d5a1884560367e8208d920f2",
"receipts_root": "0xcf8e0d4e9587369b2301d0790347320302cc0943d5a1884560367e8208d920f2",
"logs_bloom": "0x00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000",
"prev_randao": "0xcf8e0d4e9587369b2301d0790347320302cc0943d5a1884560367e8208d920f2",
"block_number": "1",
"gas_limit": "1",
"gas_used": "1",
"timestamp": "1",
"extra_data": "0xcf8e0d4e9587369b2301d0790347320302cc0943d5a1884560367e8208d920f2",
"base_fee_per_gas": "1",
"block_hash": "0xcf8e0d4e9587369b2301d0790347320302cc0943d5a1884560367e8208d920f2",
"transactions": [
"0x02f878831469668303f51d843b9ac9f9843b9aca0082520894c93269b73096998db66be0441e836d873535cb9c8894a19041886f000080c001a031cc29234036afbf9a1fb9476b463367cb1f957ac0b919b69bbc798436e604aaa018c4e9c3914eb27aadd0b91e10b18655739fcf8c1fc398763a9f1beecb8ddc86"
]
},
"signature": "0x1b66ac1fb663c9bc59509846d6ec05345bd908eda73e670af888da41af171505cc411d61252fb6cb3fa0017b679f8bb2305b26a285fa2737f175668d0dff91cc1b66ac1fb663c9bc59509846d6ec05345bd908eda73e670af888da41af171505"
}
MEV-Boostでは、Relayerにblockを送信する際は下記2点の決まりがあります。
- execution_payloadにあるblock headerのfeeRecipientにbuilderの受け取りアドレスを指定する
- blockの一番最後にProposerのアドレスにETHを送信するトランザクションを入れる
そうすることで、BuilderからProposerに分配される収益の計算がシンプルになり、Relayerは主に最後のトランザクションを見て、一番多く収益を挙げられるblockをProposerに渡すことができます。
つまり、MEV-BoostによるProposerの収益はblockの最後に送信されるETHの額になります。
Builderの実例
先ほど例に出したSearcherのトランザクションが含まれたblockを見てみます。
https://etherscan.io/block/18190574
実際にfeeRecipientに該当のblockを生成したblock builderが指定されていることがわかります。
https://etherscan.io/txs?block=18190574
また、blockに含まれるtransactionのリストを見てみると一番上にProposerの受け取りアドレス、今回はLidoのアドレスへETHが送信されていることがわかります。
Builderの収益は、シンプルに該当blockと一個前のblockでのBuilderのアドレスのETH残価の差分になります。
実際に、該当block、つまり、18190574との一個前のblockのBuilderのアドレスの残高を比較してみます。
// Block number : 18190574
curl https://eth.public-rpc.com \
-X POST \
-H "Content-Type: application/json" \
--data '{"method":"eth_getBalance","params":["0xbd3Afb0bB76683eCb4225F9DBc91f998713C3b01", "0x11590ee"],"id":1,"jsonrpc":"2.0"}'
{"jsonrpc":"2.0","id":1,"result":"0x257deed762f489d"}
// Block number : 18190573
curl https://eth.public-rpc.com \
-X POST \
-H "Content-Type: application/json" \
--data '{"method":"eth_getBalance","params":["0xbd3Afb0bB76683eCb4225F9DBc91f998713C3b01", "0x11590ed"],"id":1,"jsonrpc":"2.0"}'
{"jsonrpc":"2.0","id":1,"result":"0x255490ae73513fd"}%
RPCを実行する際は、block numberや残高などの数値は１０真数ではなく16進数で扱います。
残高の結果を16進数から10進数に変換するを下記のようになり、その差分はBuilderの利益になります。
- 該当blockの残高 : 168848622521108640
- 1個前のblockの残高 : 168120872273777660
Relayer
Relayerの概要
https://docs.flashbots.net/flashbots-auction/overview#relays
RelayerはBuilderから受け取ったfull blockを安全に保存し、Proposerがそれらにアクセスできる環境を構築する役割を持っています。
https://docs.flashbots.net/flashbots-auction/overview#relays
Relayerは複数のBuilderから複数のblockを受け取っており、受け取ったblockの中でも一番収益があるblockを登録します。
Relayerも複数存在しており、Relayerの中でも最も収益のあるblockがProposerはそのblockに渡されます。
Builder → Relayer → Proposer
https://docs.flashbots.net/flashbots-mev-boost/relay#relay-api-specification
Relayerの中ではさまざまなプログラムが動いており、BuilderとProposerの橋渡しを行う役割を担っています。
これまでRelayerがProposerにblockを渡すと説明していたので、Relayerは能動的に動いていると考えた方がいるかもしれません。どちらかというと、プログラム上ではBuilderやProposerの要求に対してRelayerが受動的に受け答えをしており、Proposerが能動的にRelayerからblockを取得しに行っているイメージが近いです。
主に下記のようなプログラムが動いています。
- BuilderとProposerのためのAPI
- BuilderとProposerの状態管理
- 一時的なpayload（blockに含まれるトランザクションのリスト）の保存のためのデータベース
BuilderはsubmitBlockでRelayerに提出したfull blockはRelayerのデータベースの中に保存されます。
blockを受け取った後、blockの検証などかなりの計算量が必要なため、blockの受け取りに優先度をつけています。基本的にRelayerに登録されているBuilderからのblockは優先度が高くなっており、外部のBuilderからのblock提出を区別するために使われています。
また、優先度の他にも、受け取り数の制限もつけられています。
ProposerはRelayerが提供するBuilderAPIのgetHeaderを利用して、保存されているblockの中でも一番収益性の高いblockのexecution payload header（①blinded block）を受け取ります。
このexecution payload headerは、EthereumのExecutionAPIにあるexecutionpayloadv1から、blockに含まれるトランザクションのリストを省いたものになります。
トランザクションの中身を抜いており、この情報だけではblockの提案ができないので「blinded block」と呼ばれています。
Proposerは受け取ったexecution payload headerに署名して、その署名データとともにsubmitBlindedBlockを使って、トランザクションのリストを含めたexecution payload header（②full block）を受け取ります。
このように、①「blinded block」をProposerに渡してから、Proposerの署名をもとに「full block」を渡すようにすることで、Proposerによる不正を検知しやすくしています。
Relayerに保存されているトランザクションデータは膨大になるため、一定期間後に定期的に削除されます。
課題
以上、MEV-boostの概要を解説しました。
MEV-Boostは部分的にPBSを実現していると説明したように、block構築の8割以上で使われているもののまだ多くの課題があります。
悪いMEVが存在していること
MEVの中でも利用者に不利益を被る形で収益を上げる悪いMEVと呼ばれるものがあります。
代表的な例として、sandwich tradingがあります。
sandwich tradingとは、例えばある人がUniswapでトレードしようとした際に、攻撃者がそのトレードの前後に悪意のあるトレードを配置することで、該当のトレードのレートを意図的に悪くして収益を上げるトレードのことです。
MEV収益の中でもsandwich tradingによる攻撃は少なくない割合を占めています。
https://eigenphi.io/
MEV-boostでは、Mempoolにあるトランザクションはsandwich攻撃を防ぐことはできず、どちらかというと助長しています。
MEV-burnにより、sandwich攻撃を行うインセンティブが弱くなるとは言われていますが、完璧に防ぐことはできず、引き続き改善が必要な分野です。
Searcherが弱い立場にあること
SearcherがBuilderに渡したbundleは必ずしもblockに含まれるとは限りません。そのため、Searcherはbundleがblockに含まれる可能性を上げるために、複数のBuilderにbundleを投げることが考えられます。
しかし、Builderがbundleを検閲しないとは限りません。
例えば、１つのBuilderにのみbundleを投げていて、Searcherが渡したbundleがblockに含まれずbundleに似た別のトランザクションがblockに含まれていたら、そのbundleを渡したBuilderがbundleを盗んだ可能性が高いと推測できます。
しかし、複数のBuilderにbundleを渡していた場合、どのBuilderがbundleを盗んだのかの検証が非常に難しくなります。
利益を多く上げているTop SearcherであればBuilderからの不正のインセンティブは弱くなりますが、中小のSearcherであれば不正される可能性は十分にあります。
この問題はIn-protocol PBSでも解決するのは難しく、悪いMEVと同様に引き続き議論が必要です。
ブロックビルダーが一元化してしまうこと
MEV-boostの仕組みでは最も収益が高いblockがProposerに受理されるため、Searcherはblock構築率の高いtop builderにbundleを投げる傾向があります。これはMEV-boostの性質上、避けられない現象です。また、高いblockを構築するためには、どれだけ多くのorder flowを獲得できるかに大きく依存しています。
そうなると、一部の収益性の高いblockを構築できるBuilderにorder flowが集中し、Builderの独占状態を生んでしまいます。
Builderの独占がすすむと、top builder間で競争優位性を守るために恣意的なルールが作られBlock構築のプロセスが不透明になってしまう可能性があります。
ブロックビルダー一元化がなぜ起きるのか、何が問題なのか、どのように解決するのかに関しては、Vitaさんの記事に詳しく書いてあるのでぜひご覧になってください。
Relayerの検閲が可能なこと/Relayerにインセンティブがないこと
MEV-boostにおいてRelayerはとても重要な役割を担っており、マシンスペックも高いものが求められています。
しかしながら、MEV-boostにおいてRelayerにはインセンティブがありません。一種の公共財として扱われています。
そのインセンティブのなさからか、Relayerの寡占が進んでおり、bloXrouteが約30%,ultrasound.moneyが20%となっており、トップ２が全体半分を占めています。
| RELAY | PAYLOADS | % |
|---|---|---|
| relay.ultrasound.money | 20,531 | 24.51 |
| boost-relay.flashbots.net | 16,154 | 19.29 |
| bloxroute.max-profit.blxrbdn.com | 15,430 | 18.42 |
| agnostic-relay.net | 12,680 | 15.14 |
| bloxroute.regulated.blxrbdn.com | 9,886 | 11.80 |
| builder-relay-mainnet.blocknative.com | 7,738 | 9.24 |
| aestus.live | 1,200 | 1.43 |
| relay.edennetwork.io | 101 | 0.12 |
| mainnet-relay.securerpc.com | 31 | 0.04 |
| Top relays - 7d, 2023-09-24 07:15 UTC, via relayscan.io |
仮に、Relayerの占有が進みRelayerが２つだけになってしまった場合、どちらかのRelayerが止まってしまうと、Proposerにblockを提出できずに空きスロットが生まれてしまう可能性があります。
また、RelayerはBuilderからfull blockを受け取るため、Relayerによるblockの検閲は可能です。
したがって、Relayer-Builderの統合が起こった場合、blockの中身を見て自身のBuilderを優遇したり、MEV収益を奪ったりすることができます。
現状、Relayerで1番の占有率のbloXrouteはBuilderもやっており、Relayer-Builder統合による不正は十分に起こる可能性は十分にあります。加えて、それらの不正を外部にわからないように行うことは可能で、外部から検知は非常に難しいです。
また、PBSではOptimistic Relay、Two slot PBS、PTCなど、Relayerの存在自体を問題しし解決しようとしているものが多いです。
Ethereumが安定的に稼働するためにもRelayerにインセンティブを与えてより多くの参入を促し、Relayerを分散化することはMEV-boostにおいて重要な役割を担うと言えます。
Validator/Proposerの力が強すぎること
Searcher、Builderがどんなに収益機会を見つけたとしても、Proposerにblockを選んでもらわなければ収益を上げることはできません。
そのため、Searcher、Builderは自身の収益を上げつつも、ギリギリのラインを見極めながらProposerにも収益を分配する必要があります。
https://ethresear.ch/t/who-takes-the-tastiest-piece-of-the-mev-supply-chain-cake/15724
そのため、その収益分配は均等ではなく、約7割近くがProposerに渡ってしまっています。
Flashbotが理念として掲げている「MEV収益の持続可能な分配（Distribute: enabling sustainable distribution of MEV revenue.）」のためにも、もう少し適正な収益分配になるような改善が必要です。
MEV-boostの今後
in-protocol / out-of-protocol PBSの動向
冒頭で話したように、MEV-Boost以外にもさまざまな形でPBSを実現しようする動きはあります。
https://youtu.be/7OxDXd9C2SY?si=L_qcXu47oJ_dVwht
in-protocol PBSでも、out-pf-protocol PBSでも、主題となっている議論は大きく 「Relayerや役割をどうするか」、「block構築におけるcommitmentをどこまで柔軟にするか」 の２つに集約されます。
どのPBSもMEV-boostの基本構成と似てはいるので、現状のMEV-boostの一部を切り取ってそれらのPBSに当てはめて利用するといった流れになるでしょう。
下記２つの動画はPBS全体の概要を掴むのに分かりやすかったので、気になる方はご覧になってください。
Ethereum L2、Intent-based applicationsの台頭
FlashbotはEthereum L1で主にサービス展開されています。しかし、Ethereum全体の動きとして、Ethereum L1をセキュリティーレイヤー、L2を実行レイヤーとしようとしています。つまり、これまで多くのアプリケーションがEthereumL1で動いていたのですが、それらのアプリケーションをL2で動かそうとしています。
実際に、Ethereum L1のトランザクションの数よりもEthereumL2のトランザクションの数が多くなってきています。また、L1のトランザクションの中でも、L2に関連するトランザクションが増えてきています。
https://www.orbiter.finance/data
現状、劇的にL1でのトランザクションは減少はしていませんが、L2の流れがさらに進むとL1でのトランザクション数が減少し、それに伴いMEVの収益も比例して少なくなることが考えられます。
また、多くのDEXはSlippageを小さくするようにプロトコルの改善を行っています。加えて、UniswapXや1inch fusionなど、オンチェーンの処理を、オフチェーンで最適化する流れも出てきてきます。
これにより、MEVの主な収益だったオンチェーンでのArbitrageやSandwitch攻撃などの収益が少なくなることも考えられるでしょう。
終わりに
Flashbotが提供するMEV-boostの仕組みについて解説しました。"MEV-boostの今後"でも述べたように、今後もMEV-boostが残り続けるとは限りません。
しかし、blockの構築の8割以上を占めるなど、MEV-boostがEthereumにもたらした影響は計り知れません。
MEV-boostの仕組みが改善されout-of-protocolでPBSが実現されるのか、それともin-porotocolの実装が進みPBSが実現されるのか、これからの動きが大変興味深い分野です。
最後に、Ethereum L2、Intent-based applicationsの台頭でMEVの収益が減少するかもしれないと述べましたが、単なる予想で数値に基づいていません。
次回は、オンチェーンデータをもとにしたMEVの今後の収益性を分析したいと考えています。
参考
Discussion
素晴らしい記事をありがとうございます！
個人的にこの表現に少し違和感がありました。bundleとethereumのtxとが1:1かつイコールかのような表現ですが、厳密には1:Nの関係でイコールでは無い気がします！
日本語に複数形が無いってだけかもしれませんが、「トランザクションの塊」的な意味合いでbundleと呼ばれている気がします。
ありがとうございます！
「このbundleは単一のトランザクションのみの場合もあれば、複数のトランザクションがまとめられる場合もあります。」を加えました！
ありがとうございます！