Це неймовірно. Я переглянув кілька різних конструкторів блоків — Agave, Firedancer, BAM і Harmonic. Усі чотири мають різну логіку розкладу. У нас також є паладин і ракураї, кожен зі своїми версіями. З точки зору ринкової мікроструктури, у TradFi у вас є необмежена система: замовлення надходять безперервно і виконуються FIFO одним відповідним рушієм. Ця безперервність дозволяє маркет-мейкерам скасовувати котирування, не ризикуючи постійно бути підкупленими. Пріоритетних комісій не потрібні, і виробники можуть котирувати спреди нижче 1 базисного пункту за окремі угоди на мільйони доларів. На перший погляд, Solana здається обмеженою ~380 мс часу на слоті. Це правда, але частково. Завдяки Turbine валідатори знищують транзакції кожні ~15–20 мс і поширюють ці шреди по всій мережі. Після виготовлення шреду замовлення в межах цієї партії фіксується. При поточному використанні блоків значно нижче меж CU, Solana поводиться набагато більше як пакетна система FIFO, ніж можна було б показати за довжиною слота. Однак подрібнення — це лише частина картини. Інше велике обмеження — це дизайн планувальника. Різні будівельники блоків реалізують суттєво різну логіку розкладу: як голоси та неголоси чергуються, коли не голосування входять у слот і як економічно пов'язані TX кластеризовані. Для реквізитних AMM це створює невизначеність. Навіть коли блоки наполовину порожні і жодна транзакція не скасовується через низький пріоритет комісій, замовлення все одно варіюється залежно від забудовника. Проп-AMM потребують оновлення котирувань і передбачуваних рекомендацій у межах шреду. У випадку з гетерогенними планувальниками цей порядок не є детермінованим між слотами, що ускладнює визначення гарантій виконання. Можна уявити, що це можна пом'якшити за допомогою пріоритету виробника або «лежачих поліцейських» для потоку приймача. Але якщо мета — ICM на Solana, ця проблема потребує більш системного вирішення. Усвідомлення проблеми — це перший крок до її вирішення, тому IRBL Explorer — дуже цінний ресурс.