Предложение для Solana SIMD-0649 должно было обязать валидаторов проверять порядок транзакций по приоритету комиссий внутри пакетов. При этом производители блоков сохраняли бы право решать, какие транзакции включать, а также определять начало и конец каждого пакета. Запрос на внесение изменений закрыли 25 сентября 2026 года без слияния, поэтому правила не вступили в силу. Данных о фактическом размере пакетов пока нет, и оценить, сделало бы предложение исполнение транзакций более предсказуемым, затруднительно.
SIMD-0649 вводило проверку порядка внутри пакетов
Solana группирует данные блока в пакеты. Согласно предложению, транзакции в одном пакете следовало бы располагать по убыванию приоритета, за исключением тех, на которые правило не распространялось. При повторном воспроизведении блока валидаторы проверяли бы зафиксированный порядок и отклоняли блок при нарушении требований, а не переставляли транзакции после его получения.
Транзакции с одинаковым приоритетом могли бы идти в любом порядке. Простые транзакции голосования освобождались бы от проверки. Приоритет рассчитывался бы не только исходя из комиссии, указанной пользователем: вознаграждение производителя блока за включение транзакции делилось бы на запрошенную стоимость исполнения по модели затрат. Расчет включал бы множитель и защиту знаменателя от некорректных значений. Целочисленная арифметика должна была обеспечить одинаковые результаты в разных клиентских реализациях.
По предложенным правилам, в вознаграждение входили бы приоритетная комиссия и та часть базовой комиссии, которая не сжигается. В случае принятия SIMD-0649 наблюдатели получили бы общий способ проверять, одинаково ли упорядочены транзакции, уже попавшие в один пакет. Авторы считали, что это помогло бы сравнивать порядок обработки в разных клиентах валидаторов и планировщиках. Однако правило не определяло бы, следует ли вообще включать конкретную транзакцию в блок.
Производители блоков сохраняли бы контроль над включением транзакций
Предложение не устанавливало единую очередь по приоритету на весь слот. Производители блоков по-прежнему могли бы выбирать транзакции, переносить их в следующие пакеты и задавать границы пакетов. Поэтому конкурирующие транзакции могли бы оказаться в разных пакетах и не сравниваться по одному правилу. Транзакция с более высоким приоритетом в следующем пакете не перемещалась бы автоматически перед транзакциями из предыдущего.
Таким образом, область действия SIMD-0649 была бы уже, чем у правил сортировки на весь слот, и оно не гарантировало бы оптимального исполнения. В проект также включили минимальный размер пакета: это должно было помешать производителям ослаблять проверку, разбивая транзакции на слишком мелкие группы.
Все пакеты, кроме последнего, должны были бы охватывать не менее двух наборов коррекции ошибок прямого распространения (FEC). Набор FEC состоит из шардов данных блока; согласно предусмотренному фиксированному размеру, два набора соответствуют как минимум 64 шардам данных. Последний пакет также проверялся бы на соблюдение порядка, но для него минимальный размер не устанавливался: слот может завершиться до того, как пакет заполнится.
Недостаток данных о размерах пакетов мешает оценить эффект
В комментарии к проекту от 23 сентября отмечалось, что даже при минимальном размере производитель блока мог бы завершить пакет в момент, когда это позволяло бы разделить конкурирующие транзакции. Автор комментария запросил данные о текущих размерах пакетов с разбивкой по планировщикам, клиентам и рыночным условиям, а также предложил проверить, как разные минимальные размеры повлияют на результат. Вопрос касался практического охвата правила; комментарий не утверждал, что производители блоков применяли такой подход в основной сети.
В предложении говорилось, что Agave и Firedancer нацелены на пакеты размером примерно в два набора FEC. Однако ни сам проект, ни комментарии к нему не содержали распределения фактических размеров пакетов. Поэтому сложно оценить, как минимальный порог повлиял бы на обычное формирование блоков и насколько ограничил бы возможность производителей менять границы пакетов.
Неизмеренными остаются задержки и риски приоритетных комиссий
В августовском обсуждении подняли вопрос о задержке: если валидаторам пришлось бы ждать заполнения пакета перед проверкой, это могло бы затруднить воспроизведение данных в Firedancer по мере их поступления. В обновленном проекте предусматривалась возможность сравнивать и исполнять транзакции постепенно, отклоняя блок, если нарушение порядка обнаруживалось позднее. Но при небольшом потоке транзакций требование дождаться минимального размера в два набора FEC могло бы увеличить задержку передачи. Данных измерений задержек в доступных материалах нет.
SIMD-0649 также не запрещало бы производителю блока отдавать предпочтение собственным транзакциям, оплачивая приоритетную комиссию самому себе. В предложении указывалось, что приоритетные комиссии поступают производителю блока, тогда как сжигаемая часть базовой комиссии остается для него затратой. Поэтому проверка порядка внутри пакета сама по себе не устраняла бы преимущественное исполнение, максимальную извлекаемую стоимость (MEV) или проскальзывание.
SIMD-0649 закрыли 25 сентября; дальнейшее продвижение зависело бы от обсуждения и поддержки разработчиков клиентов. Для трейдеров ключевые вопросы — сколько действительно конкурирующих транзакций попало бы в один пакет и изменил бы минимальный размер поведение производителей блоков. Пока таких данных нет, предложение дает способ проверять относительный порядок транзакций внутри пакета, но его влияние на фактическое исполнение остается неясным.