Предлагаемое правило Solana позволит валидаторам отклонять блок, если транзакции внутри одного пакета записей будут обработаны не в порядке приоритета комиссий. Это правило не будет определять, какие транзакции попадут в блок. Запрос на слияние SIMD-0649 был закрыт 25 сентября без слияния, оставив этот узкий компромисс для дальнейшего обсуждения, вместо того чтобы ввести новое правило упорядочивания.

Это различие важно для трейдеров, пытающихся предсказать, где окажется их ордер. Согласно проекту, продюсер блока, известный как лидер, по-прежнему будет выбирать, какие транзакции включить и как разделить их на пакеты. Предлагаемая проверка консенсуса сделает порядок транзакций внутри каждого завершенного пакета проверяемым и принудительным. Она не установит единую очередь приоритетов для всего слота.

Реестр Solana группирует записи в пакеты. В соответствии с дизайном проекта, неисключенные транзакции в каждом пакете должны будут располагаться в порядке убывания приоритета. Валидатор, воспроизводящий блок, будет сравнивать их зарегистрированные приоритеты и рассматривать нарушение как недействительный блок. Он не будет перемешивать транзакции в правильной последовательности после их получения. Транзакции с равным приоритетом могут располагаться в любом порядке, а простые транзакции голосования будут исключены.

Оценка приоритета основана на вознаграждении, которое лидер получает за включение транзакции, разделенном на ее запрошенную стоимость в рамках модели стоимости до выполнения. Проект предусматривает целочисленный расчет с множителем и единичным значением в знаменателе, чтобы клиенты могли вычислить тот же результат. Согласно правилам комиссий, описанным в предложении, вознаграждение включает комиссию за приоритет и несгоревшую часть базовой комиссии. Таким образом, оценка более специфична, чем простое ранжирование по комиссии, указанной пользователем.

Это изменение даст наблюдателю проверяемый ответ на один вопрос: среди неисключенных транзакций, помещенных лидером в один пакет, соответствовал ли зарегистрированный порядок предложенной оценке? Автор утверждает, что общая проверка облегчит проверку порядка в различных клиентских программах валидаторов и планировщиках. Предложение не устанавливает, должна ли транзакция быть включена в первую очередь.

Где лидеры Solana сохраняют дискреционные полномочия

Нецели проекта оставляют лидерам свободу выбора транзакций, откладывания одной до следующего пакета и выбора границ пакетов. Эти решения могут определить, столкнутся ли две конкурирующие транзакции с одинаковым тестом упорядочивания. Транзакция с высоким приоритетом в более позднем пакете не будет перемещена перед транзакцией с более низким приоритетом в более раннем пакете только потому, что ее оценка выше. Таким образом, упорядочивание внутри пакета является более узким свойством, чем упорядочивание по всему слоту или гарантия лучшего исполнения.

Предложение Solana пытается предотвратить самый очевидный способ лишить правило смысла: сделать пакеты настолько маленькими, что сравнивать почти нечего. Оно потребует, чтобы каждый пакет, кроме последнего, охватывал как минимум два набора прямой коррекции ошибок (FEC), группы пакетов данных, называемых “shreds”, которые составляют блок. При фиксированном размере FEC, на котором основан проект, это означает как минимум 64 пакета данных. Последний пакет по-прежнему будет подвергаться проверке порядка, но будет освобожден от минимального размера, поскольку слот может закончиться до его заполнения.

Этот минимум не устраняет всех дискреционных полномочий. В обзоре от 23 сентября рецензент утверждал, что лидер все еще может закрыть пакет, когда выгодно разделить конфликтующие транзакции, и запросил данные о текущем размере пакетов, разбитые по планировщикам, клиентам и рыночным условиям. Обзор также запросил тест на чувствительность для различных минимальных размеров. Это возражения против практического охвата правила, а не доказательства того, что лидер уже использовал эту тактику в основной сети.

В проекте говорится, что Agave и Firedancer нацелены на пакеты размером примерно в два FEC-набора, но ни в предложении, ни в обзоре не приводится измеренное распределение, показывающее, как часто текущие лидеры производят меньшие пакеты. Без этих данных эффект минимума на обычное производство блоков не может быть количественно оценен. Это может закрыть простую лазейку, но общедоступные данные не устанавливают, насколько поведение это изменит.

В обсуждении в августе была поднята связанная проблема задержки: проверка, которая должна была ждать целого пакета, могла бы помешать практике Firedancer по воспроизведению частично полученных данных. Пересмотренный проект позволяет валидаторам сравнивать и выполнять транзакции по мере их поступления, а затем аннулировать блок, если последующее сравнение не удается. Он также признает, что задержка лидера до достижения минимума в два FEC-набора может увеличить задержку трансляции при низкой пропускной способности. Источники не измеряют эту задержку.

SIMD-0649 также не помешает лидеру отдавать предпочтение собственным транзакциям, выплачивая себе комиссии за приоритет. Проект гласит, что эти комиссии возвращаются лидеру, в то время как сгоревшая доля базовой комиссии остается расходом. Это еще одна причина, по которой предложенный тест упорядочивания не следует рассматривать как гарантию против преференциального отношения, MEV или проскальзывания.

Закрытие 25 сентября последовало за призывом к дальнейшему обсуждению и поддержке со стороны разработчиков клиентов. Если пересмотренное правило Solana будет продвигаться, его ценность для пользователей будет зависеть от того, как часто значимые конкурирующие транзакции попадают в один пакет, и изменит ли минимальный размер пакета поведение лидеров. Общедоступное предложение определяет способ аудита их относительного порядка, но отсутствие данных о пакетах оставляет нерешенным вопрос о его влиянии на фактическую предсказуемость выполнения.

Всегда имейте в виду, что редакции могут придерживаться предвзятых взглядов в освещении новостей.