見出し画像

DEX決闘王への道　BSC編

Ros

仮想通貨botter Advent Calendar 2022 7日目の記事です。

どうも、Rosです。

Harmonyにおいて初めてのDeFi領域でのbotを作成し、そこそこなノウハウを得たあと、BSCという場でDEXアービトラージャーもといDEXデュエリストとして修業したことを書きます。

※Harmonyは前回記事参照（https://note.com/ros_1224/n/n881205035286）

用語について：
　本記事では、普段仮想通貨に触ってる方でも、見慣れない単語がいっぱい出てくると思います。MEVだとかbackrunningだとかatomic arbだとかGossipだとか。説明はそれぞれそれ一本で記事かける程度の無理ゲーなのでググってください。

デュエリストキングダム（BSC)入国

CEXにおける高頻度トレードなどは継続してやっていたのですが全然儲からず。HarmonyというよりDefi Kingdomsでそこそこ成功経験を得た僕はDeFi領域に活路を見出します。

DeFiで全自動トークン収穫祭を開催したい

Harmonyは当時EVM系の中では中堅チェーンの座をほしいままにしており、「Harmonyで勝てるのであれば、他のチェーンに横展開すればウハウハなのでは？」と僕は考えました。
そして攻略プランを人気上位のチェーンから下がっていくと決めます。
なぜなら、人気上位のチェーンほど継続性の前提があると考えたためです。継続性の前提を重視するのは法人化を見据えていたためです。
あとイキリエンジニアの自分は、ぶっちゃけ上位チェーンでも勝てるだろうと思ってました。

まずTVL圧倒的1位といえばEthereum。ですが、これはやめました。
当時ですらflashbots採用バリデータの比率は60%程度あり、MEVゲームであるためです。
MEVそのものはある意味でPlay2Earnであり、僕としてはそれはそれで興味深々なのですが、Harmonyとは戦い方が違ってきますし水平展開が難しいです。DAppプロトコルのお勉強、調査が主タスクになるので、労働要素高めです。
自分のもってるノウハウとはMEVというよりはレイテンシ重視のバックランニングのノウハウ。
となると次点はBSCです。

次回、「闇落ちエンジニア、死す」

さて、攻略対象が決まったとなれば何をするか。
フルノードを建てます。これは今も昔も変わってません。
同期中に、harmony botのコードをforkしてBSC向けにbotを改造します。

中堅チェーンであるHarmonyで一時的にですが覇権を取っていたという自負もあります。
Harmonyと一緒のことやれば多少は戦えるだろう。

イキリエンジニアなのでしょうがないですね

この時点で僕の手札はHarmonyデッキからの流用カード。
具体的には下記です。

  • Python＋一部Rust製ライブラリ(PYO3)でのatomic arb bot　
    Harmonyにおいて裁定パス算出1ms程度の攻撃力　特殊能力なし

  • ノード改造ちょっとデキル

  • EVMチョットワカル

  • 勢い

  • 投資資金100万

僕はこの時点で100万円ぶっこむことを決意します。
インフラが重要なのはHarmonyの経験上、分かり切っている。
BDNだろうがAWSだろうが払ってやんよ。つーか勝つまで払ってやんよ。
その決意でいました。

ただし、ひとつここに制約を課しました。
1か月程度で白黒つけることです。
インフラ費用や、その他経費を考えると勝てないまま数か月やり続けるのは非常に非合理的です。金が無限に溶けますし。

まあこれのせいで、無茶苦茶な1か月だったんですが。時間をかけると金が溶けるので時間をかけられない。
当時は在宅勤務だったので1日に使える時間は多い。いけると踏みました。

デュエルスタンバイ

フルノードが無事に立ておわりました。
こっからはやることは腐るほどあります。
海外勢はチームを組んでやってますが、自分は個人。
つまりこう

準備完了の儀式

ノードの改造

Harmonyと同様、BSCもgethベースなのでこれはそんなに手こずりませんでした。
唯一Harmonyはlibp2pベースのプロトコルであり、BSCはGethそのままForkした程度のdevp2pプロトコル実装であるため、多少の差はありましたが、やることはたいしてかわりません。

（１）俺用RPCの追加
（２）ノードそのもののチューニング、オーバーヘッドの削除
（３）設定値追加、魔改造
（４）Gossipプロトコルをハックする

以上です。これは他チェーンにおいてもある種のエッジなので詳細を省きます。

DEXの調査

次は、BSCのDEXを調査します。BSCといえばPancakeSwap、BiSwapが代表的でしょうか。いえ、もちろんそれだけじゃすみません。
オンチェーンに流れる流動性プールを片っ端に検出し、コントラクトコードを確認後、裁定パスの算出に組み入れます。
フロントエンドが死んだDEXやらもこれには含まれます。これは本当に地味な作業ですが非常に大切です。
当時のファイルをあさってみましたが、Uniswapフォーク類で30つぐらい対象にしていました。Poolの数で言うと数千～1万程度はあったと思います。
これはぶっちゃけただの労働ですね。

具体的な裁定パスの算出方法については書きませんが無論、収益がプラスとなる閉路を探索するためには、対象とするプールのLiquidity監視やら変動量も全て監視する必要があります。
リアルタイムで更新する各プールの流動性と、mempoolに流れてくるトランザクションを元に裁定トランザクションを生成するのです。
つまり基本的には監視対象は多いほうがより裁定機会を検出できます。

ガス最適化

Harmonyのときはガス代をあまり考えなくてもよかったですが、BSCはダイレクトにガス代が消耗します。
そのため、コントラクトをチューニングする際は一般的なSolidityのテクニックを使用してできる限りガス代消耗を抑える必要があります。
これまたこれ一本で記事かけるぐらいの内容になるので、具体例は書かないですが、基本的なロジックそのものを最適化するほか

・assemblyの使用
・uncheckedの使用
・callする際にstaticcallを直接使用
・uint256を基本的に使用する
・コンパイル最適化
・data input部独自unpack
・ガストークンの使用（割とBSCのみ主流だった。今は知らん）

などが一般的なテクニックかと思います。

追記：いまはHuffという低レベルでEVMを操作できる言語もあるようです。やろうと思えばどこまでも行けてしまう。怖い世界です。

加えてBSCという戦場では

・LPプールの流動性が高め
・Swapする人は多いが、小資金が多い

という理由から、開く鞘は数円～数十円。よくて数千円。みたいなのが大半なので、ガス代の最適化というのはそのまま対象にできる鞘レンジの広さへ直結します。
実際のところガス代を最適化すればするほど、取れる鞘も増えるので競合も減りますし、ある種の他人が面倒だから取らないエッジでもあります。数円の鞘とかですけど。
とはいえ1Txで1円でもガス代を節約できるのであれば、数万トランザクションを飛ばす前提だとかなり効いてきます。のでガス代の節約をやらない理由はない。

BSCScanで競合のTransactionのGeth TraceをBSC Scanで見ることができます。

こういうやつ


競合のガスコストは全て見れるため、どんなEVM OPCodeを何回実行したかというレベルで競合と比較することが容易に可能なのです。そのため目標があるので、比較を繰り返しつつどこまでも突き詰めることができます。

自分もちょっと頑張ったのですが、EVMガチ勢にはかないませんでした。
ガチ勢は通常であればSolidityをコンパイルした際に生成されるfunction dispacher部すらないのです。
あいつらは恐らくEVMアセンブリを直で書いてます。もはや芸術品です。
（いわゆるInlineではなくStandalone Assembly)　
海外勢は大抵チームでやってるのでコントラクトにも作成専門がいたりする。その人が己の限界に挑戦してるのではないでしょうか。

いや、何ゲーだよｗｗｗ付き合ってられっかｗｗ　ってことで競合の1.2倍ぐらいのガスコストかかる程度の効率の悪さで妥協しました。
ときには妥協も肝心です。数円の鞘はみないことにしました。

bloXrouteの導入

さて、最近ではその名前を見る方もいるのではないでしょうか。
bloXrouteの紹介です。

そもそもbloXrouteというサービスとは何でしょうか？
元々はブロックチェーンノード間の通信（ブロックの伝搬など）を仲介し、高速で伝搬するBDN（Blockchain Distribution Network)サービスです。Softbankビジョンファンドが出資したのは記憶に新しいでしょう。
対応チェーンはETH、BSC、Polygon、そっから最近ではSOLANAへの進出とどんどん拡充していってます。MEVリレーのインフラももってます。

bloxRouteの機能。BDN

ブロックチェーンのバリデータ視点では、より安定した高速な通信を得るためのインフラとして。
トレーダー視点ではより速くブロックとトランザクションを検知し、優位に立つためのインフラとしてマジで邪魔な広く使われているサービスです。

名目はBDNとしての機能を提供するサービスですが、もはやMEVやatomic arb bot向けのサービスといっても過言ではありません。

気になるお値段

驚きのお値段

100万円用意しても現実的にEnterpriseプランしか契約できません。
ちなみに上位プランほどトランザクションの優先度が高いので、EnterpriseプランはEnterprise-Eliteプランに対して1ms不利になります。

ゴールドラッシュで儲けた人たちとは、ツルハシを売る人。そんな言葉を思い出します。

つーか高すぎだろ！！ってことでとりあえずEnterprise 1250$/monthプランで妥協しました。

このbloXrouteですが、割と奥が深く。これまた書こうとすると1本いや、２本ぐらい記事書けます。

基本系は

１．フルノードを立てて、普通にBSCネットワークに参加
２．Dockerイメージで提供されるbloXroute Gatewayを建てて、契約してもらったクライアント証明書を突っ込む。するとbloXroute GatewayがbloXrouteの専用P2Pネットワークにつながる。
３．フルノードをbloXroute Gatewayと接続する。

です。
bloXroute Gateway自身が、devp2pプロトコルで対話が可能であり、一種のフルノードとして機能します。
自身が建てたフルノードはbloXroute Gatewayに接続するだけで以下のような恩恵を得られます。

  • ブロックの検知速度UP

  • トランザクションの検知速度UP

  • トランザクションをbloXrouteのネットワークを介して送信可能

  • bloXroute Gatewayが提供するRPCを使用可能

これ、実際のところ1秒とかそういうレベルで早くなります。

ではなぜそんなに早くなるのか？
それは、そもそも普通のGethの転送が遅いのです。その理由はdevp2pのプロトコルに由来するものなのですが、これまた長くなるのでやめます。
直で通信できてたら1秒なんて地球一周してもかからないはずですからね。

bloXroute Gatewayそのものを改造しようとした話もあるのですが、うまくいかなかったので割愛。go-gatewayのソースコードはGithubに上がってるのですが、バイナリと比較するとバージョンが古いです。（少なくとも当時は。）

バトルフェイズ「ずっと競合botのターン」

BSC仕様に改造したBOTの試運転を開始し、コンソールを眺めるとある事に気が付きました。
まずmempoolへの流入をみると、UniswapRouterに対してSwapするトランザクションをかなりの数検知しているのです。ただ、これは異常ではありませんでした。
これがBSCです。

この記事を書いたときに適当にブロックみただけでも１ブロックに相当数のUniswapRouter(ほぼPancake)へのリクエストがある

「Welcome to BSC.」

そう語り掛けてくる無数のトランザクションを前に僕は感動していました。ここで勝てたらこれは相当にでかいぞ、と。

そして、自身が送ったトランザクションを確認します。

はい、エラー。

そこにあったのは、圧倒的なエラーの大波でした。

メインフェイズ１：トークンバリデーション


先のトランザクション、なぜ失敗したか？

その答えの１つはBSCに蔓延る罠でありBOT殺し「Honeypotコントラクト」です。

BSCでのHoneypotの量は異常です。
ほかのチェーンの数十倍、いや数百倍あるといっても過言ではありません。その種類も代表的なERC20詐欺トークンから、BOT狙い撃ちの偽Poolコントラクトまでいくつもあります。

やはり代表的なのは、「コントラクト作成者しか売れないトークン」でしょうか。

こういうやつ

当たり前ですが、こんなものを騙されて購入した時点で裁定トランザクションは成立しません。売れないので。

スマコン書いたことがある人だとかWeb3有識者的な人であれば「いや、Revertすれば取引されないから余裕でガードできるでしょ！ｗ」　と思うかもしれませんが、Atomic arb botではこんなの対象にしたら秒でガス代でお金溶けます。
自分が送るのは数万数百万単位の数のトランザクションです。
そもそもトランザクションを投げる際に「１つの最良パス」を決めることになるので、最良パスにHoneypotが組み込まれた時点で「Honeypotを弾いていれば算出できたルート」という裁定機会をも失うことになります。

こういう明らかな悪意を持ったトークン以外にも、Transfer実施時に謎の手数料を徴収してくるトークンや特殊条件にマッチした際に失敗させてくるトークンやら謎トークンを発行して無駄にガス代をかけてくるトークンやら、裁定ルートに組み込むうえで非常に邪魔なトークンが腐るほどあります。
よってバリデーションしてフィルタリングする必要があります。
当時苦戦しながら試行錯誤を呟いてたTwitterのツリーが下記。

元々この記事を書くにあたり、ちゃんとeth_callの応用例的なトークンバリデーションに関しての技術的な話を書こうと思ってたんですがめちゃめちゃ長くなるので止めます。それだけで5千文字いけます。
よって簡潔に書きます。

（１）EVM上で、from:プールのアドレスから対象のトークンを「別のプールにTransfer」した際の入出力量が正しいことを検証する
（２）EVM上で、from:プールのアドレスから対象のトークンを「適当なアドレスにTransfer」した際の入出力量が正しいことを検証する
（３）EVM上で、from:プール以外のアドレス　から対象のトークンを「適当なプールにTransfer」した際の入出力量が正しいことを検証する。
（４）EVM上で、from:プール以外のアドレス　から対象のトークンを「適当なアドレスにTransfer」した際の入出力量が正しいことを検証する。
（５）EVM上で、対象のプールのswapの動作が正しいか確認する
（６）上記のケース全部で、GasCostが正常値になることを確認する。

ようは、ありとあらゆる角度からSwapをシミュレーションして、意図通りに動くことを確認します。裁定トランザクションを発行するにあたり障害がないことを確認します。

適当なプール、適当なアドレスへのTransferを検証する必要があるのは、対象のトークンのTransferの実装の内部で「PoolからのTransfer」「PoolへのTransfer」などを確認しないとダメなパターンがあるためです。

（３）、（４）はfromがプールではなく、プール以外なので「対象となるTokenを持ってないアドレス」になります。つまりSwapシミュレーションの主体になるためにはまずfromアドレス自身にTokenを入手する必要があります。
入出力量を検証する前にFlashSwapなどを用いてfromアドレスにTokenを持ってくるのが楽です。StorageをOverrideしてfromアドレスのBalanceを変更して疑似的に残高を増やすという手段もありそうですが、トークンコントラクトによってbalanceが入っているmapのオフセットが異なりそうで、多種多様な魔界ERC20トークンを相手にすると、うまくOverrideできないだろうと思ってやめました。

終わり。
ただこれでも完全には防げていないのですが引っかかったときの対処コストが釣り合わないので対応してません。
攻撃する側に経済的なインセンティブもないので、別に相手にしなくていいのです。
何に対応できてないかは書きませんが、最終的には「攻撃者のスマートコントラクトデプロイ」　vs　「BOT側のオフチェーン検証でのブラックリスト追加」　のいたちごっこの構図になるでしょう。
この勝負になっても、相手側にガス代が発生する以上負けはありません。

メインフェイズ２：ロジックの最適化

無事にhoneypotを弾く機構を実装したが、全くと言っていいほど勝てませんでした。
なんなら競合BOTの中で最下位クラスをさまよっています。

そう、単純な速度負けです。
実際のところ、Harmonyでは1msで済んでいたものが、BSCではルート探索に3ms-5ms程度かかってたりしました。
これは探索パスを算出するうえでベルマンフォード法のような2点間の最短距離を探索するアルゴリズムが基本となるため、プール数が多いとそれだけ網羅するパスが増えるのでその分探索時間を増えたためです。

そこで下記のように改善を施しました。

・フルRust実装に変更
・探索深さを３ホップまでに一旦制限
・パス算出のアルゴリズムを抜本的に速度重視のオレオレ仕様に変更

３行で書いてますが、辛かったです普通に。
Rustなんてほぼ書いたことないし。アルゴリズムの変更に至っては、当時のメモを見ても限界の中書いてるので、自分でももはや何を書いてたのかわかりません。

何だよこの星マーク

これらの施策によって大体10倍に高速化。
0.3ms～1ms程度に抑えることに成功しました。

メインフェイズ３：bloXrouteとバトル

先述の施策によって、多少順位が上がりましたがまだまだシェアを取れていません。
中堅にすら浮上していませんでした。たまに数千円の鞘を取ることはあるものの全くガス代をペイしません。

悩んでいた僕はここで、bloXrouteの1機能に便利な機能があることに気が付きます。tx-traceです。

この機能を使うと特定のトランザクションに対してbloXrouteの各リレーを通過したタイムスタンプがミリ秒単位でわかります。

{"txTrace":[
    {"region":"EU United Kingdom","txTime":"2021-11-09 14:55:54.755","diff":"+0ms"},
    {"region":"EU Germany","txTime":"2021-11-09 14:55:54.762","diff":"+7ms"}, 
..  ...
    ],
"txHash":"4a0c243bc1556c665dc5de722fb425a61e446a122f60a5addefaf7c5b13c2dea",
"numberOfRegions":10}

みたいなのがトランザクション単位で取得可能です。
そこで僕は考えました。

この時点でそもそもbackrunning対象に同ミリ秒に叩き込むぐらいじゃないと勝てないのでは？

Enterpriseプランだと1ms不利なので勝てないのでは？

上記の仮説を考えつつ、さらなる最適化。主にTCP周りやプロセス間通信のオーバーヘッドに対してのチューニングを施し、安定して初期リレー地点に同ミリ秒～＋1ミリ秒に叩き込むことに成功するようになりました。
目標値があると施策の効果が目に見えるので、試行錯誤の効率が段違いなんですね。

またbloXrouteのプラクティスにも書いてあるのですが、Txのブロードキャスト先はbloXrouteだけでなくBSCのネットワークそのものにも同時に流すべきです。
これはやはりbloXrouteを介すことが最速ではないケースがあるためです。
具体的にはAWSの同一NWに相手側のフルノードがいるケースとかですね。

メインフェイズ４：俺自身がノードになる事だ

無事、bloXrouteのtxtrace上は同ミリ秒、なんならbloXroute上でリレーしてるときにたまに追い越すみたいな状態にはなりましたが勝てません。
たまには取れるのですがそれでも上位の奴らには全くかないませんでした。

よってここで考えを変えました。

「bloXrouteに勝たないとダメじゃね？ｗ」

「つーかそれやるには競合のノードより高速に処理しないとダメじゃね？ｗ」

あと、ブロック上でもトランザクションの追い越しが多く発生しました。理由は省きますが、これを防ぐ方法をとるにはどうしてもbloXrouteから脱却する必要があるのです。
よって、ここからはtxtraceを確認しつつ「通常のブロックチェーンネットワークにトランザクションをブロードキャストしたうえでbloXrouteに勝つ」ことが目標になりました。

目標に向かってGeth実装そのものを捨て、BOT自身をDevp2pのクライアント、すなわちノードにすることを決めます。

弊BOTは先述のとおりフルRust実装になりました。
よって最速を求め、Rust実装のdevp2pクライアントをBOTに埋め込むことに決めました。

Twitter上ではopenethereumを使用したと記載しましたが、厳密には下記クライアントになります。説明に最速って書いてあったし。
丁度、本記事を書いた数日前あたりにサポートが終了したようです。残念。

このakulaというrustによるethereumクライアントですが、Githubにも記載のあるとおりErigon architecture.というのをベースにしています。
このErigon architectureにおけるSentryというコンポーネント。
それが実はdevp2pクライアントそのものであり、疎結合にできています。やろうとおもえばスタンドアロンで動かし、grpcで外部から制御もできます。
これに目を付けました。

この部分。当時はSentry単体のリポジトリもあった

SentryコンポーネントをBOTに組み込み、接続先をethereumじゃなくBSCにしました。
そう、融合です。

これもかなり紆余曲折苦戦したのですが、無事BOT単体でノードとなることに成功しました。
ネゴシエーションやらのプロセスでのForkIDをEthereum⇒BSCに変更しないといけなくて算出が大変だったり、実際のピアとの対話部分は自分で記載しないといけなかったりで大変だった記憶があります。

余談ですがDEX BOTTERとの会話の中でたまに使われる「Sentry」というワードの意味を自分だけ取り違えていたのはこういう理由だったりします。
頭の中がRustでした。

あとgithubや実際のp2pネットワークの通信見る限り、自分と同じようにbot自身をノードにしてるデュエリストがかなりいました。大体当時で2000ピア程度BSCネットワークにはいたのですが、ほとんどは同種の「見た目だけBSCフルノード」でしょう。

メインフェイズ５：独自BDN召喚


ここまでの施策で覇権ゲット！！



はい、そんなことにはなりませんでした。上位の４名程度でしょうか。
あいつらが頭おかしいのです。

「ここまでやって勝てないのか」

僕はもうその思考に支配されてました。
元々決めていた1か月の期限もオーバーし、用意した軍資金も厳しい気配です。

ただ、一つ　自分の中で試せずにいられない施策を頭に抱えていたのです。
独自BDNの構築です。金がかかるのはわかっていたが考えついたら試さずにはいられない。

そう、俺がbloXrouteを作ることだ。


これまでの試行錯誤や思考の中で「ノード同士の交換そのものは、bloXrouteを介さないほうが速い」「ノード数は多いほうがプロトコル的にも有利」ことがわかってました。
当たり前ですがbloXrouteそのものにもそれなりのオーバーヘッドがあるのです。また、devp2pプロトコルではTransaction本体を含むメッセージ送信(0x02)は、接続ピア数の一部にしか送信されないのでノード数を増えせば増やすほど有利に立てます。（このあたりの話はEIP-2464）


つまり全世界にノードと化したBOTを設置し、それぞれがbloXrouteより速い独自レイヤーでトランザクション交換を実装すればbloXrouteより速くTx検知できるのでは？


その仮説を元に僕は金でぶん殴ることを始めました。

・AWS間の通信は高速
・リージョンがかなりの数ある

という理由から、AWS一択です。

独自のトランザクション交換プロトコルには、UDPを使用し工夫をこらしできる限りデータサイズが少なくなるようにしました。

botを改造し、まずは独自BDNへ形成できるようにした後はsystemdによりdaemon化し、起動イメージを作成して全世界のリージョンにばらまきました。
独自ネットワークを形成するためのピアを管理するためのインスタンスを立ち上げました。占めて40インスタンス。

AWSの各リージョンをノードと化した弊botが埋め尽くすイメージ

通常のGossipプロトコルのように、「相手がそのトランザクションを知ってるか」なんて管理してるわけもないので、検知した瞬間即座にトランザクションをリレーします。40ノードがそれぞれお互いに。
ネットワーク通信費が加速しました。1日の通信費は500$-700$に到達しました。



「俺は、日本円とQOLを生贄に独自BDNを召喚！」

出でよ、独自BDN!!

紆余曲折を経て構築した独自BDN。
まずはbloXrouteのリレーから得られるトランザクションと独自BDNから得られるトランザクションの到達時間を比較しました。
平均して2ms-3ms程度勝てました。最終的に70％程度のトランザクションで速度勝ちできたと記憶しています。
これがbloXrouteのオーバーヘッドです。

tx-traceでも確認しました。
bloXrouteが検知するより2ms-3ms程度先に検知成功していました。
目論見は成功です。





それでも勝てませんでした。

爆発四散

なぜ勝てないのか？

いろいろ仮説はあるんですけど、やっぱこれだと思うんですよね。
独自BDNを作ったとはいえ、バリデータ側がそこに直で接続してくれるわけではありません。bloXrouteは直で繋がってるのはアーキテクチャ上間違いないですし、一部の競合BOTは直で接続できているのではないかもと思ってます。

バリデータと直で繋がせてくれれば、勝てる見込はあります。
ただし大体のバリデータは公式のプラクティスに則り前哨ノードを建ててたり、そもそもbloXroute gatewayとしかつながってないんじゃないかなって思ってます。
詳細は隠しますが、実際そういうデータが取れてます。

あと、バリデータのうち3ノードはflashbots的な仕組みを採用してるようなので一部はMEV gameなのかもしれません。バリデータそのものが大半みんな細工されてる疑惑も拭えません。
実際、gaspriceの並び替えがおかしいバリデータは数台確認してましたし、そいつらは隠す気もないのだと思います。

bloXrouteを上位プランにした上で、独自BDNでTx検知すれば勝てるのでは？説は残ってはいるんですが、あんま勝てる気がしなくてやる気がおきてません。
バリデータ数が21から41に増えるという話があったので、そのうち再挑戦してみようとは思ってます。

番外編：海外勢について

海外では、atomic arbitrageというよりは、MEVという括りで論じられてることが多いです。
本来、MEVはMiner Extractable Valueのことを指すので、FlashBotsが提供する「バリデータ内でブロックを並び替えることによって、抽出できる裁定利益」そのものを指すと思うのですが、まぁもう括りなんでしょうね。

海外勢のTwitterを見ると、mempool swimmerやらMEV PvPプレイヤーと呼称してる人が多くて面白いです。同じようにゲームととらえてる人が多いんですね。自分はデュエリストを呼称していこうかな。

海外勢のatomic arbに関する記事
　12/4 追記：とてもアプローチに親近感あって面白かったです

番外編：他のことやらないの？

NFT購入なりDEX鞘なりにバックランニングしなくても、DeFiだと見えるエッジって探せばいくらでもあるとは思います。色々とグレーなものも。

自分は基本的にその手のものにはノータッチ。法的リスクが怖いとかそういうのもありますが一番はこれです。

オレ様はデュエルで勝ちたいんです

法律に触れない範囲で用法・用量を守って正しくやりましょうね

総括

DEXのarbitrageとはエンジニアの誇りをかけた戦いであり闇のゲームです。
我々はデュエリストなのです。

ブロックチェーンというフィールドにて、BOTというモンスターカードを召喚し、Honeypotという罠カードを潜り抜けつつ、スマートコントラクトという魔法カードを発動する。

しかもお互い、永続魔法「インフラコスト」「ガス代」により、毎ターンライフポイントを削られている。ライフポイントが０になったら強制退場。
至極単純なルールです。

ルールは単純！

先日、ひろゆきはABEMAで言っていました。

「仮想通貨は遊戯王カードみたいなもの、資産と思ってる人は頭が悪いんですよね」

我々は遊戯王カードを使うデュエリストであり賞金稼ぎ、そういったポジションになるのかもしれません。

ブロックチェーンは止まらない！

あとがき

自分はBSCからは退場しましたが、修行経験を活かして下位のEVMチェーンに進出、更なる高速化の施策を実施しながら現在のところは生き残ることに成功し進出先を更に増やしていっています。そのうち3つ程度は主要ステーブルコインがハッキングくらいましたが。

どこかで実はデュエルしてることもあるかもしれません。
その時は対戦よろしくお願いします。



ちなみに100万で済ますつもりがBSC修行費全体では150万程度かかってました。しかも1か月どころか1か月半ぐらいやってた模様。
最後の「BDN召喚！」の生贄コストがあまりにも高かったようです。


いいなと思ったら応援しよう！