これは素晴らしい。 いくつかのブロックビルダーを試しました — Agave、Firedancer、BAM、Harmonic。4人とも異なるスケジューリングのロジックを示しています。パラディンとラクライもそれぞれ独自のバージョンを持っています。 市場ミクロ構造の観点から見ると、TradFiでは制約のないシステムが使えます。注文は継続的に到着し、単一のマッチングエンジンによってFIFOで実行されます。この継続性こそが、マーケットメイカーが常に狙われるリスクを負わずにクオットをキャンセルできる理由です。優先手数料は不要で、メーカーは1ベーシオン未満のスプレッドを1ベーシスコの取引で数百万ドルの見積もりを提示できます。 一見すると、Solanaは約380msのスロット時間に制限されているように見えます。それは確かにそうですが、ある程度はそうです。Turbineのおかげで、バリデーターは1~20msごとにトランザクションをシュレッドし、これらのシュレッドをネットワーク全体に伝播させます。一度シュレッドが作られると、そのバッチ内での注文が固定されます。現在のブロック利用率がCU制限を大きく下回っているため、Solanaはスロット長が示すよりもバッチ型FIFOシステムに近い動作をしています。 しかし、シュレッダーは全体の一部に過ぎません。もう一つの大きな制約はスケジューラ設計です。異なるブロックビルダーは、投票と非投票の入れ替え方法、非投票トランザクションをスロットに含めるタイミング、経済的に関連したトランザクションのクラスタリングなど、意味のある異なるスケジューリングロジックを実装します。プロペラAMMの場合、これは不確実性をもたらします。ブロックが半分空いていて、優先度が低いために取引がドロップされなくても、注文はビルダーによってスロットごとに変わります。 プロップAMMは見積もり更新やテイカーの取引が予測可能にスムーズに注文される必要があります。異種スケジューラでは、スロット間での順序が非決定的であり、実行保証を推論するのが困難です。 これをメーカー優先制やテイカーフローのスピードバンプで緩和することも考えられます。しかし、もし目標がソラナでのICMであるなら、この問題にはより体系的な解決策が必要です。 問題があることに気づくことが解決への第一歩なので、IRBLエクスプローラーは非常に貴重なリソースです。