Constellation: предложение по внедрению MCP в Solana

Практические выводы

• Constellation — первое формальное предложение протокольного уровня по масштабному внедрению множественных параллельных пропоузеров (MCP) в работающем блокчейне.
• Constellation вводит две новые роли — пропоузеров и аттестаторов, — которые ограничивают свободу лидера при формировании блока. Около 16 пропоузеров работают параллельно в 50-миллисекундных циклах, объединяя транзакции в pslice с кодированием стирания и распределяя их между 256 аттестаторами. Запись аттестации криптографически привязывает лидера к набору включаемых им транзакций. Если pslice аттестован достаточным числом аттестаторов, лидер не может исключить транзакцию, не создав недействительный блок, который сеть отклонит.
• Constellation обладает свойством устойчивости к избирательной цензуре: в каждом цикле включаются либо все конкурентоспособные по комиссии транзакции, либо ни одна из них.
• Атаки на порядок транзакций с видимым содержимым и манипуляции временем по-прежнему остаются нерешёнными. В Constellation транзакции видны всем пропоузерам, которые получают их в момент отправки. Из-за архитектуры MCP с несколькими пропоузерами поверхность таких атак может даже расшириться, а не сократиться. Текущая архитектура признаёт, что игры с задержкой на основе времени невозможно наказать.
• Constellation перестраивает существующие комиссии: комиссия за включение соответствует нынешней базовой комиссии, а комиссия за порядок — существующей приоритетной комиссии. Более существенный экономический сдвиг состоит в том, что активность, которая сейчас проходит через внепротокольные сервисы доставки транзакций и офчейн-соглашения о комиссиях, должна вернуться в протокол. Выбор ролей с учётом доли стейка сохраняет существующую динамику концентрации, а итоговое влияние на отдельных валидаторов невозможно смоделировать до появления окончательного SIMD для Constellation.
• MCP увеличивает задержку определения последовательности, но сокращает задержку включения. Раунд аттестаторов, окно цикла в 50 мс и пакетная сборка увеличивают время относительно нынешнего прямого пути отправки в TPU. Сейчас задержка выше у валидаторов, которые сразу упаковывают транзакции TPU, и ниже у тех, кто их задерживает. В Constellation действительные транзакции получают ограниченную по времени и обеспечиваемую протоколом гарантию включения.
• Constellation явно несовместим с моделями разделения пропоузера и сборщика (PBS). Как только запись аттестации ограничивает свободу лидера, специализированному сборщику больше нечего продавать. Этот подход воплощает принципиально иную философию по сравнению с нынешним подходом Ethereum к MEV.
• Эмпирических тестов в реалистичных сетевых условиях пока нет. Самые важные данные, которые может предоставить Anza, — сравнительные прогнозы задержки для слотов длительностью 200 мс в текущем протоколе и в Constellation. Пока эти данные недоступны, сообщество обсуждает компромиссы, которые невозможно оценить количественно. 
• Constellation строится поверх Alpenglow, запуск которого в mainnet запланирован на третий квартал 2026 года.

Введение

Несмотря на поразительное отсутствие агав, Brennan Watt, CEO Anza, отправился в пустыню Калифорнии, чтобы представить Constellation — предложение по внедрению множественных параллельных пропоузеров (MCP) в Solana. Это самое структурно амбициозное обновление и, вероятно, самое значимое предложение по MCP на уровне протокола, которое до сих пор выдвигал какой-либо работающий блокчейн. Оно призвано устранить временную монополию лидера на упорядочивание транзакций и создаваемую ею извлекаемую ценность. Constellation демократизирует пространство блоков в Solana.

В этой статье представлен критический анализ Constellation: какие проблемы он решает, что намеренно откладывает и что действительно остаётся нерешённым. Мы предлагаем трёхуровневую модель оценки устойчивости к цензуре, сравниваем Constellation с текущими решениями MCP и рассматриваем, совместимы ли его компромиссы с той производительностью, которая стала отличительной чертой Solana.

Предполагается знание принципов работы Alpenglow. 

Проблема, которую решает Constellation

Транзакции — основа Solana. Их объединяют и навсегда записывают в сеть в виде блоков. Но решение о том, какие транзакции попадут в эти блоки и в каком порядке, не является нейтральным процессом. 

Монополия лидера на производство блоков

Производство блоков передаётся по расписанию лидеров: в каждый момент времени один валидатор отвечает за создание блоков в заданном окне.

В течение этого времени транзакции перенаправляются непосредственно в модуль обработки транзакций лидера (TPU), где лидер обычно получает их раньше остальных.

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

Лидер может не включать некоторые транзакции, произвольно менять их порядок или добавлять собственные.

Это структурная особенность текущей модели консенсуса с одним лидером. В той или иной степени она присутствует практически во всех работающих сегодня блокчейнах на основе Proof of Stake.

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

В Solana информационное преимущество лидера сложнее оспорить из-за особенностей перенаправления транзакций. 

Максимальная извлекаемая ценность (MEV)

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

Такая извлекаемая прибыль известна как максимальная извлекаемая ценность (MEV). Впервые этот термин формализовали Daian и соавторы в работе Flash Boys 2.0 как извлекаемую майнерами ценность, прежде чем его стали применять к сетям Proof of Stake. Понятие охватывает всё: от арбитража и опережающих транзакций до сэндвич-атак, избирательной цензуры и любых стратегий, использующих информационное и позиционное преимущество лидера над пользователями, чьи транзакции он обрабатывает.

Основным ответом отрасли на MEV стала модель разделения пропоузера и сборщика (PBS), реализованная в Ethereum через MEV-Boost. В PBS специализированные сборщики конкурируют за создание блоков, максимизирующих извлекаемую ценность, а пропоузеры просто выбирают наиболее прибыльный блок для производства. Это прагматичное переосмысление проблемы: модель исходит из неизбежности извлечения MEV и стремится демократизировать доступ к нему и распределить доходы между валидаторами, а не сосредоточивать их у наиболее опытных участников.

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

Отношения Solana с MEV также продолжают развиваться. Сочетание короткого времени блока, прямой отправки в TPU и конкуренции между валидаторами сформировало особую среду MEV, для которой характерны спам, аукционы приоритетных комиссий и изменение порядка транзакций на уровне валидаторов. Движок блоков Jito можно считать частичным аналогом MEV-Boost: он предоставляет офчейн-механизм аукциона, в котором поисковые участники делают ставки на порядок транзакций, а доход распределяется между валидаторами и стейкерами. Иными словами, подобно PBS, Jito более демократично управляет MEV и перераспределяет его, а не устраняет полностью.

Constellation призван исправить эту ситуацию. Вместо того чтобы принимать монополию лидера и управлять её последствиями, он стремится структурно ограничить её и сделать наиболее вредоносные формы MEV невозможными на уровне архитектуры. В технической документации Constellation эта цель описана как «инфраструктура интернет-рынков капитала — универсальная площадка для экономической деятельности, где пользователи могут быть уверены в справедливости рыночной структуры».

Традиционные финансовые рынки пытаются обеспечить схожую защиту с помощью регулирования и надзора в рамках юрисдикций. Такая защита реактивна и неравномерна, и практика неоднократно показывала её недостаточность. Цель Constellation — обеспечить справедливость на уровне протокола, чтобы её нельзя было обойти или применять избирательно. Для этого Constellation предлагает внедрить множественных параллельных пропоузеров (MCP) в Solana.

Множественные параллельные пропоузеры

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

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

Множественные параллельные пропоузеры (MCP) — класс протокольных архитектур, которые устраняют эту монополию на структурном уровне. Вместо передачи исключительного права на производство блока одному лидеру MCP позволяет нескольким нодам одновременно предлагать транзакции. Ни один пропоузер не контролирует полный набор транзакций. Их предложения объединяет, как правило, действующий в строгих рамках сборщик в соответствии с правилами протокола.

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

Главный компромисс MCP — сложность координации. Если разрешить нескольким нодам одновременно предлагать транзакции, возникают вопросы, которых полностью избегают архитектуры с одним лидером. Как разрешать конфликтующие транзакции, если два пропоузера включили одну и ту же транзакцию? Как определять порядок между предложениями? Как помешать опытному пропоузеру манипулировать правилами объединения? Это значительно усложняет протокол: командам приходится решать задачи координации, связанные с новыми ролями нод, логикой расписания, криптографическими допущениями и сценариями сбоев. Всё это требует тщательного тестирования.

Здесь важно использовать точные определения, поскольку в отрасли термин MCP применяется довольно свободно к целому ряду архитектур с существенно различающимися свойствами. На базовом уровне MCP обеспечивает вероятностную устойчивость к цензуре: транзакцию, отправленную нескольким пропоузерам, сложнее подвергнуть цензуре, поскольку для этого требуется координация между несколькими нодами. На более высоком уровне MCP может обеспечить структурную устойчивость к цензуре: лидер математически не способен создать блок, который подвергает цензуре транзакцию, подтверждённую достаточным кворумом. Именно к этому стремится Constellation, и такое различие критически важно для финансовых приложений, которым нужны строгие гарантии.

Как работает Constellation

Constellation — протокол для внедрения MCP в Solana. Он дополняет Alpenglow: Alpenglow отвечает за консенсус, то есть безопасность, живучесть и финализацию, а Constellation — за рыночную структуру: кто может предлагать транзакции, как эти предложения подтверждаются и что лидер вправе с ними делать. Constellation формирует полезную нагрузку, которую финализирует Alpenglow.

Архитектура

Constellation вводит в стек протоколов Solana две новые роли с разными обязанностями и одновременно изменяет роли лидеров и валидаторов.

Пропоузеры служат точкой входа для транзакций. В каждый момент времени параллельно активны около 16 пропоузеров, которых случайным образом выбирают с учётом стейка и меняют каждые 32 цикла, то есть примерно каждые 1,6 секунды. Пользователи отправляют транзакции напрямую одному или нескольким выбранным пропоузерам. Пропоузер может принять или отклонить любую транзакцию при условии, что принятые транзакции действительны. На этом этапе протокол не требует обязательного включения транзакций — гарантия устойчивости к цензуре появляется позднее в конвейере. Каждый пропоузер работает в циклах длительностью 50 миллисекунд. В течение каждого цикла пропоузер объединяет принятые транзакции в структуру под названием pslice. Префикс «p» не произносится и нужен лишь для отличия от slices в Alpenglow. Для pslice применяется кодирование стирания, которое разделяет его на 256 меньших частей — pshreds. Каждый из 256 активных аттестаторов получает один pshred. Порог восстановления при кодировании стирания равен 64: любых 64 из 256 pshreds достаточно, чтобы восстановить полный pslice. Каждый pshred содержит криптографическое хеш-обязательство для полного списка транзакций. Поэтому после подтверждения аттестаторами лидер не может подменить транзакции или изменить их порядок внутри pslice.

Аттестаторы получают pshreds от пропоузера, сразу перенаправляют их следующим примерно двум лидерам на случай сбоев или отсутствия одного из них и записывают хеш-обязательство полученного pslice. В конце каждого цикла аттестатор подписывает аттестацию — криптографически обязывающее заявление со списком всех хешей обязательств pslice, которые он наблюдал в течение цикла. Аттестация отправляется лидеру и служит доказательной записью, ограничивающей набор транзакций, которые лидер может включить. Запись подписана и учитывает доли стейка, поэтому её нельзя подделать или незаметно проигнорировать. 

Лидер в Constellation совпадает с лидером Alpenglow — это нода, отвечающая за создание итогового блока, который передаётся в консенсус. Разница в том, что в Constellation свобода действий лидера строго ограничена записью аттестации. Constellation устанавливает два отдельных порога. Чтобы совокупная аттестация считалась действительной, в ней должны участвовать не менее 60% аттестаторов. Если этот порог не достигнут, весь блок пропускается. При этом лидер обязан включить любой pslice, подтверждённый как минимум 40% аттестаторов. В противном случае блок становится недействительным, и сеть его отклоняет. Архитектура с двумя порогами отделяет действительность блока от включения данных отдельных пропоузеров. Иными словами, лидер может создать действительный блок, даже если данные некоторых пропоузеров не дошли до достаточного числа аттестаторов, но не может избирательно исключать пропоузеров, чьи данные дошли. Собрав все аттестованные pslices в пакет, лидер передаёт его валидаторам через Rotor из Alpenglow. 

Валидаторы получают пакеты от лидера через Rotor и выполняют их конвейерную обработку по мере поступления. Получив полный блок, валидаторы сверяют его с записью аттестации и проверяют, что каждому аттестованному pslice соответствует отправка в блоке. Валидатор голосует за финализацию только в том случае, если все проверки пройдены. Если проверки не пройдены, валидаторы с помощью вызова TrySkipWindow голосуют за пропуск всего окна лидера. 

Циклы и блоки

Цикл — базовая единица времени в Constellation. Это 50-миллисекундное окно, вычисляемое по физическому времени UTC путём деления временной метки Unix в наносекундах на 50 000 000. Важно, что циклы не синхронизированы со слотами Alpenglow. Слот содержит несколько циклов, а созданные в них пакеты образуют полезную нагрузку блока лидера. Это различие важно: 50-миллисекундный цикл служит экономическим тактом, то есть окном, в котором обеспечивается устойчивость к цензуре, тогда как слот остаётся единицей консенсуса Alpenglow.

В технической документации задан допустимый рассинхрон часов между пропоузерами и аттестаторами, а окно аттестации корректируется соответствующим образом. Чтобы понять важность этого параметра, предположим, что часы пропоузера спешат на 5 мс относительно часов аттестаторов. Pshreds этого пропоузера могут поступить аттестаторам раньше ожидаемого относительно границы цикла, поэтому у транзакций в таком pslice будет немного больше времени для накопления аттестаций. И наоборот, pshreds от пропоузера с отстающими часами могут прийти настолько поздно, что полностью выпадут из окна аттестации, хотя пропоузер отправил их «вовремя». В центрах обработки данных, где используются такие инструменты, как chrony или GPS-приёмники, синхронизация часов выполняется регулярно, а расхождение обычно составляет менее миллисекунды и укладывается в допустимые пределы Constellation. Проблема в том, что Constellation вводит новую переменную, которой не было в модели чисто логического времени Alpenglow. В окончательном SIMD для Constellation следует задать пределы её мониторинга.

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

Жизненный цикл транзакций и комиссии

До выполнения транзакция должна пройти четыре этапа:

• Пропоузер должен принять её и включить в pslice.
• Этот pslice должен накопить достаточно аттестаций для включения в пакет лидера.
• Ставка транзакции должна быть достаточно высокой, чтобы её выбрали для выполнения с учётом лимита вычислений пакета.
• Блок, содержащий пакет, должен быть подтверждён консенсусом Alpenglow.

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

Constellation разделяет стоимость транзакции на две отдельные комиссии:

• Комиссия за включение.
• Комиссия за порядок.

Комиссия за включение — небольшая фиксированная плата, зависящая от размера транзакции и числа подписей. Её получает пропоузер, включивший транзакцию в свой pslice. Комиссия взимается с момента, когда транзакция преодолевает порог аттестации, независимо от того, будет ли она в итоге выполнена. Это аналог базовой комиссии в текущей системе Solana, но с важной оговоркой: если пользователь для надёжности отправляет одну транзакцию трём пропоузерам, он платит комиссию за включение трижды, то есть по одному разу каждому пропоузеру, поскольку каждый из них независимо выполнил работу по её включению. Таким образом, если пользователь для надёжности отправляет одну транзакцию n разным пропоузерам, он платит комиссию за включение n раз.

Комиссия за порядок — более крупная составляющая, зависящая от приоритета. Она равна общему числу единиц вычислений транзакции, умноженному на её ставку. Эта комиссия взимается только один раз, поскольку транзакцию можно выполнить лишь один раз независимо от числа включивших её пропоузеров. Например, транзакция, запрашивающая 200 000 единиц вычислений при ставке 0,00001 SOL за единицу, платит комиссию за порядок в размере 2 SOL. Если для надёжности эта транзакция была отправлена четырём пропоузерам, пользователь заплатит четыре комиссии за включение и одну комиссию за порядок в размере 2 SOL. Комиссия за порядок возвращается в экосистему пропорционально стейку нод. Архитектуру этого механизма техническая документация оставляет для окончательного SIMD.

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

Constellation и Alpenglow

Alpenglow — протокол консенсуса Solana. Он определяет действительность блоков, порядок их финализации и способ восстановления сети после сбоев. Его компоненты Votor и Rotor заменяют Tower BFT и распространение голосов через gossip, существенно сокращая время финализации. Alpenglow ничего не говорит о том, кто предлагает транзакции и как определяется их порядок внутри блока.

Constellation — слой рыночной структуры, который ограничивает действия лидера Alpenglow с собираемыми им блоками. Он определяет, кто предлагает транзакции и как устанавливается их порядок внутри каждого блока. Создаваемые Constellation пакеты становятся полезной нагрузкой блоков Alpenglow. Затем Votor в Alpenglow нотариально подтверждает эти блоки согласно заранее заданным правилам голосования. Два протокола объединены так, что Alpenglow обеспечивает безопасность и живучесть, а Constellation — справедливый порядок.

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

Constellation — первое формальное предложение протокольного уровня по внедрению MCP в масштабируемом работающем блокчейне. Это важный шаг к обеспечению устойчивости Solana к цензуре и следующая глава дорожной карты протокола, которую открывает Alpenglow.

Что на самом деле требуется для устойчивости к цензуре

В исследованиях MEV эту проблему исторически рассматривали с нескольких разных точек зрения. Вместе они формируют более целостное представление о том, какие задачи должно решать любое предложение по обеспечению устойчивости к цензуре. Опираясь на базовую классификацию атак с опережением от Eskandari и соавторов, формальную модель двух свойств для протоколов MCP от Garimidi и соавторов, а также анализ специфичных для MCP каналов MEV от Landers и Marsh, мы предлагаем разделить поверхность атаки на три уровня. Для каждого требуется отдельный класс решений. Эта модель — наш собственный синтез, который мы представляем здесь для оценки архитектуры Constellation.

Уровень 1: жесткая цензура

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

Уровень 2: упорядочивание с видимым содержимым

Второй уровень сложнее. Хотя пропозеры не могут напрямую цензурировать транзакции, они по-прежнему могут видеть их содержимое до окончательного упорядочивания и пытаться использовать эту информацию, например для сэндвич-атаки на крупную сделку. Garimidi и соавторы формализуют это как свойство сокрытия: злоумышленник не должен видеть содержимое транзакций до их подтверждения. Constellation реализует частичное сокрытие. Транзакцию видит только получивший ее пропозер, а не все пропозеры, и лидер получает доступ к ее содержимому лишь после завершения цикла. Это лучше полной видимости, но не полностью удовлетворяет свойству сокрытия Garimidi и соавторов, согласно которому содержимое транзакции должно оставаться невидимым для всех сторон до подтверждения. Получивший транзакцию пропозер по-прежнему может увидеть и использовать ее содержимое.

Более серьезная проблема Constellation заключается в том, что MCP с публичной отправкой транзакций может усилить эксплуатацию видимого содержимого. В такой системе каждый пропозер видит полученные транзакции и может использовать эту информацию в пределах собственного pslice. Поверхность атаки отличается от модели с одним лидером: несколько участников видят каждый свое подмножество. Пользователь, отправляющий транзакцию одному пропозеру, раскрывает ее только ему. Но если для резервирования пользователь отправляет ее нескольким пропозерам, раскрытие пропорционально расширяется. Landers и Marsh формализуют эту динамику: параллельное производство блоков создает игры со временем, возможности дублирования в одном тике и структурно устраняет единственную точку контроля со стороны сборщика, которая сейчас ограничивает число попыток извлечения ценности из одной транзакции жертвы. Децентрализация набора пропозеров без решения проблемы видимости содержимого не сокращает, а расширяет поверхность атак MEV.

Анализ специфичных для MCP каналов MEV от Landers и Marsh предполагает более широкую видимость содержимого, чем предоставляет Constellation. При частичном сокрытии в Constellation усиление эксплуатации видимого содержимого зависит от стратегии отправки пользователя и не является неизбежным следствием архитектуры. Пользователь, отправляющий транзакцию одному доверенному пропозеру, раскрывает содержимое примерно так же, как в современной модели с одним лидером. Компромисс заключается в том, что отправка одному пропозеру лишает систему резервирования, от которого зависит устойчивость к цензуре. 

Уровень 3: манипуляции временем и задержкой

Самый тонкий и трудный для наказания уровень связан с манипуляциями временем и задержкой. В Constellation пропозер может задержать пересылку pshreds аттестаторам ровно настолько, чтобы транзакция конкурента не попала в окно аттестации, либо использовать расхождение часов UTC, чтобы влиять на то, какие транзакции наберут достаточно аттестаций. В техническом документе Constellation этот пробел признается напрямую: за позднюю доставку сообщения «нельзя наказать», поскольку ее невозможно отличить от реальной сетевой задержки. Именно на этом уровне может потребоваться слешинг, и это главный открытый вопрос, который предстоит решить в будущем SIMD для Constellation. 

В основе архитектуры Constellation лежит фундаментальное допущение: отношения между пропозером и пользователем не анонимны. Это повторяющееся взаимодействие, в котором доверие можно измерить, а репутация имеет значение. Когда одновременно активны около 16 пропозеров, пользователь, который постоянно сталкивается с плохим отношением одного из них, может начать отправлять транзакции одному из остальных 15. Это не создает ончейн-артефакта, позволяющего напрямую наказать недобросовестного участника, но влечет экономические последствия для пропозеров, злоупотребляющих своим положением. Достаточно ли такого репутационного давления для сдерживания манипуляций временем по сравнению с таким решением, как слешинг, — открытый вопрос. Вероятно, ответ будет зависеть от того, насколько прозрачным для пользователей со временем станет поведение пропозеров. 

Влияние на валидаторов и пользователей

Валидаторы

Constellation перераспределяет возможности MEV между валидаторами, а не устраняет их полностью. Самый очевидный и непосредственно извлекаемый источник дохода, доступный сегодня лидерам, — жесткая цензура — становится невозможным по замыслу системы. Однако ему на смену приходит набор более тонких и трудных для наказания временных каналов. Они дают преимущество валидаторам с меньшей задержкой, точной синхронизацией часов и достаточной технической компетенцией, чтобы стабильно использовать окна пересылки pshred. В результате меняется способ извлечения ценности валидаторами, а не общий масштаб возможностей для такого извлечения. Единственная оговорка: извлекать ценность становится значительно сложнее.

Constellation не столько вводит принципиально новые потоки комиссий, сколько перестраивает существующие. Комиссия за включение аналогична современной базовой комиссии, а комиссия за упорядочивание соответствует существующей приоритетной комиссии. Ожидается, что распределение будет похоже на нынешний доход валидаторов. Разница в основном операционная. Хорошие операторы должны получать больше комиссий за включение в роли пропозеров. Это создает градацию доходности по эффективности в рамках существующей экономики, а не отдельную категорию дохода. В текущей архитектуре роль аттестатора отдельно не оплачивается. Предполагается, что, как и нынешнее участие в Turbine, эта работа будет выполняться потому, что в целом приносит пользу сети. Более значимое экономическое изменение касается активности, которая сейчас проходит через внепротокольные сервисы доставки, рыночные аукционы и офчейн-соглашения о комиссиях. Она должна вернуться в протокол и приносить валидаторам более непосредственную выгоду. Однако пока SIMD не определит точные механизмы, итоговое экономическое влияние на отдельных валидаторов остается открытым вопросом. Особенно это касается небольших валидаторов, для которых взвешенный по стейку отбор снижает частоту выбора пропозером, а инфраструктурные расходы повышают минимальный уровень затрат.

Пропозеров и аттестаторов выбирают с учетом веса стейка. Поэтому те же факторы концентрации, которые формируют экономику валидаторов, влияют и на участие в этих ролях. Если небольшой круг валидаторов с крупным стейком будет доминировать при выборе пропозеров, формальная гарантия устойчивости к цензуре сохранится, но практическое разнообразие набора пропозеров сократится. При этом ситуация все равно улучшится относительно современной Solana: выбор 16 из n вместо 1 из n. Допущение о независимости начнет ослабевать на практике, даже если сохранится в теории. Это важная проблема на фоне появления предложений Validator-as-a-Service (VaaS), при которых одна организация может управлять несколькими валидаторами с крупным стейком. Введет ли SIMD механизмы против концентрации или стимулы для выбора пропозеров — архитектурный вопрос, который напрямую влияет на надежность заявленных Constellation гарантий. 

Пользователи

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

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

Для маркетмейкеров гарантия включения Constellation устраняет риск того, что инфраструктура злоумышленника определит качество исполнения. Остается только информационная асимметрия — тот же профиль риска, с которым маркетмейкеры сталкиваются сегодня на лучших традиционных площадках. Именно это сближение превращает довод в пользу включения и снижения задержки из пожелания в конкретный аргумент. Мы подробнее рассматриваем его в разделе «Открытые вопросы».

Средний пользователь, вероятно, почти не заметит итоговых изменений, но гарантия включения существенно повысит надежность. До появления будущих тестов итоговое влияние на задержку последовательности остается открытым эмпирическим вопросом.

Обзор: сравнение Constellation с другими решениями

Sei Giga

Sei Giga — ближайший аналог Constellation в современной экосистеме MCP. Это блокчейн промышленного уровня, для которого MCP является первоочередным архитектурным приоритетом, а не целью будущих исследований. Сравнение полезно, поскольку на одном уровне эти системы выбирают разные компромиссы.

В основе консенсуса Giga лежит Autobahn — BFT-протокол с несколькими пропозерами, где каждый валидатор параллельно ведет собственную непрерывную «полосу» предложений. Вместо одного лидера каждая нода постоянно распространяет собственный поток предложений данных по независимой полосе. Уровень консенсуса периодически фиксирует «срез вершин» — компактный снимок, объединяющий последние предложения со всех полос. Архитектурно это отличается от модели Constellation, где около 16 выбранных пропозеров работают с фиксированным циклом 50 мс. В модели Autobahn с полосами любой валидатор может непрерывно вести собственную полосу предложений. Его не нужно выбирать из сменяющегося подмножества, взвешенного по стейку, поэтому участие в производстве блоков становится намного шире.

Наиболее существенное различие связано с упорядочиванием при видимом содержимом. Autobahn обеспечивает асинхронное исполнение, отделяя упорядочивание транзакций от исполнения, тогда как Constellation откладывает этот шаг. Как показано в следующем разделе, асинхронное исполнение сужает поверхность атак на упорядочивание при видимом содержимом: пропозеры не могут во время упорядочивания моделировать результаты исполнения относительно известного конечного состояния.

Giga обеспечивает вероятностную устойчивость к цензуре, а Constellation — структурные гарантии. В основе Giga лежит представление, что транзакцию, отправленную нескольким пропозерам, сложнее подвергнуть цензуре. Каждый пропозер располагает неполной информацией, а цензура может оказаться бесполезной, если другой пропозер включит транзакцию в том же тике. В Constellation лидер, исключивший транзакцию с достаточным числом аттестаций, создает невалидный блок. Вероятностная устойчивость повышает стоимость цензуры, а структурная делает ее криптографически невозможной. Для финансовых приложений, которые стремятся поддерживать оба протокола, эта разница имеет значение. 

Стоит откровенно признать разницу в амбициях этих двух архитектур. Constellation — спецификация протокола, которая доказывает свойства корректности, определяет условия отказа и пороги кворума и предназначена для представления в качестве формального предложения для масштабируемой промышленной сети с миллиардами застейканной стоимости. Технический документ Sei Giga написан иначе: он сосредоточен на заявленной пропускной способности и совместимости с EVM, а MEV и устойчивость к цензуре рассматриваются как естественные преимущества архитектуры с несколькими пропозерами, а не как формально определенные гарантии. Асинхронное исполнение — верное направление, но Giga не предоставляет столь же строгих формальных гарантий для ограничений упорядочивания, кворумов аттестаторов и условий отказа, как Constellation. Это не критика решений Giga в области последовательности, а следствие разных контекстов. Constellation предлагается для самого производительного промышленного блокчейна в мире, что требует и обеспечивает соответственно более высокий стандарт спецификации.

Академический идеал

Теоретический ориентир для архитектуры MCP — работа Несколько параллельных пропозеров: зачем и как (2025) авторства Garimidi и Neu из a16z Crypto Research и Max Resnick из Anza. В ней предлагается протокол MCP с двумя свойствами, которые, по мнению авторов, обязательны для любой устойчивой к цензуре архитектуры: устойчивостью к избирательной цензуре и сокрытием. Первое гарантирует, что злоумышленник не сможет избирательно задерживать транзакции, а второе — что их содержимое останется невидимым до подтверждения. Это единственная архитектура MCP в современной литературе, которая формально обеспечивает оба свойства одновременно.

Сокрытие обеспечивает HECC — Hiding Erasure-Correcting Code. Параметры подобраны так, что любые T шардов не раскрывают никакой информации об исходном пакете транзакций, а K + T шардов позволяют полностью его восстановить. Критически важно, что ретрансляторы передают сохраненные шарды только после того, как консенсус подтвердит включенные пакеты. Это предотвращает любое наблюдение содержимого транзакции до подтверждения и полностью закрывает поверхность атак на упорядочивание при видимом содержимом посредством теоретико-информационной гарантии. 

В рамках разработанной выше модели это единственная архитектура протокола, которая решает проблемы уровня 1 с помощью структурной устойчивости к цензуре, уровня 2 — с помощью сокрытия и ограничивает уровень 3 благодаря предоставляемым сокрытием гарантиям устойчивости к цензуре. Ни Constellation, ни Giga не достигают этого в полной мере.

Сравнение особенно интересно тем, что Resnick, соавтор теоретического идеала, также выступает соавтором Constellation — протокола, который сознательно от этого идеала отступает. Это отражает взвешенное решение о том, что полную архитектуру на базе HECC пока невозможно развернуть в промышленной сети масштаба Solana, а структурная устойчивость к цензуре — более срочная задача. Эта работа служит для Constellation путеводной звездой: формальной спецификацией цели развития протокола, даже если реализовать все сразу невозможно. 

Ethereum Braid

Braid — основное предложение MCP для Ethereum, представленное Max Resnick. Сейчас его рассматривают как часть дорожной карты Ethereum Scourge наряду с конкурирующей архитектурой списков включения FOCIL. Оно включено сюда не столько для технического сравнения, сколько для контекста: вся отрасль пытается решить одни и те же структурные проблемы, но с разных исходных позиций.

Braid реализует MCP, позволяя нескольким пропозерам одновременно создавать блоки в параллельных цепочках в одном слоте. Уровень исполнения объединяет транзакции, устраняет дубликаты и сортирует их по заранее установленным правилам. Дополнительные протокольные роли не вводятся. Самое существенное различие в том, что безопасность Braid сильно зависит от зашифрованных мемпулов. Поэтому сокрытие здесь — обязательное условие, а не отложенная задача. Braid остается неразвернутым исследовательским предложением, и сообщество Ethereum еще не решило, стоит ли предпочесть его FOCIL.

В конечном счете Braid подтверждает, что структурные аргументы в пользу MCP выходят за рамки одной цепочки. Стоит также отметить, что Resnick работал над тремя из четырех проектов в этом разделе. Возможно, это самый явный признак того, что Constellation стал результатом продолжительной, межконтекстной и академически строгой работы над проблемой, для которой нет простых решений.

Замечание о PBS

Proposer-Builder Separation (PBS) стоит упомянуть как противоположный подход, а не как сопоставимую архитектуру. Все решения в этом разделе пытаются структурно ограничить временную монополию лидера, тогда как PBS принимает ее и оптимизирует систему вокруг нее, чтобы перераспределить доходы MEV. Constellation прямо несовместим с PBS: когда свобода действий лидера ограничена записями аттестации, специализированному сборщику больше нечего продавать. PBS стал основным способом смягчения MEV в Ethereum, хотя никак не уменьшает ущерб пользователям. Именно такого сценария MCP призван избежать.

Внепротокольный прецедент

Еще до запуска Constellation экосистема Solana уже воспроизводит отдельные аспекты MCP вне протокола. Например, Harmonic — это открытый уровень агрегации для сборки блоков, который непрерывно собирает и оценивает предложения блоков от нескольких независимых сборщиков и в реальном времени передает их валидаторам для конкурентного выбора. Формально это не MCP: протокол не обеспечивает устойчивость к цензуре, кворум аттестации или криптографическое ограничение свободы лидера. Однако валидаторы с Harmonic уже выбирают между несколькими параллельными предложениями блоков — это основной механизм, который MCP стремится закрепить. Вместе с BAM эти системы представляют попытку экосистемы решить проблемы структуры рынка, не дожидаясь контроля на уровне протокола. Такие внепротокольные системы показывают, что спрос на свойства MCP достаточно реален и сборщики не намерены ждать запуска Constellation.

Открытые вопросы

Технический документ Constellation — это спецификация протокола. Он доказывает свойства корректности при заявленных допущениях и обоснованно откладывает все остальное, что уместно для предложения версии v0.9. Далее приведен не список недостатков Constellation, а карта вопросов, которые необходимо решить в будущем SIMD и последующих версиях, чтобы эффективно внедрить MCP в Solana. 

Эти вопросы неодинаково сложны. Некоторые относятся к спецификации — это архитектурные решения, которые Anza может и должна принять в рамках обычного процесса SIMD. Другие являются действительно открытыми проблемами, которые широкое исследовательское сообщество MCP пока не решило. Но мы должны учитывать их, прокладывая путь к первому масштабному блокчейну с MCP. Ни один SIMD сам по себе не решит эти проблемы. Различие важно: если смешивать эти категории, можно либо преувеличить недостатки Constellation, либо недооценить объем оставшейся работы.

К относительно простым задачам SIMD относятся:

• Распределение комиссий: описано, как приоритетные комиссии делятся между пропозерами, аттестаторами и более широким набором валидаторов, но схема раскрыта не полностью. В техническом документе говорится, что приоритетные комиссии возвращаются экосистеме пропорционально стейку, однако точный механизм распределения между пропозерами, аттестаторами и валидаторами не определен.
• Структура вознаграждений валидаторов: как вознаграждение пропозеров соотносится с существующими вознаграждениями валидаторов и изменит ли отмена комиссий за транзакции голосования в Alpenglow экономику небольших валидаторов.
• Последовательность развертывания: Constellation зависит от Alpenglow, запуск которого запланирован на третий квартал 2026 года. SIMD должен явно указать эту зависимость и определить порядок действий во время перехода от базового Alpenglow к Constellation+Alpenglow. Нужно ли сначала развернуть в mainnet какие-либо обязательные SIMD?
• Управление параметрами ролей: число пропозеров (p ≈ 16), число аттестаторов (q ≈ 256), длительность цикла (△cycle = 50ms) и другие параметры из таблицы 1 технического документа Constellation представлены лишь как предложения. SIMD должен определить, как устанавливать эти параметры, управлять ими и при необходимости менять их со временем.

Более сложные вопросы, включая асинхронное исполнение, слешинг и конфиденциальность уровня отправки, рассматриваются в следующих подразделах. Исследовательское сообщество MCP активно работает над ними, и мы обязаны учитывать их. Архитектурные решения Constellation могут как сузить, так и расширить путь к определенным будущим решениям.

Асинхронное исполнение

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

Асинхронное исполнение устраняет вторую часть этого преимущества, но только в сочетании с MCP. Если консенсус фиксирует порядок транзакций до исполнения, пропозер, видящий содержимое транзакции, не может смоделировать результат исполнения относительно известного конечного состояния, поскольку в момент упорядочивания такого состояния еще нет. Информационное преимущество фактически сужается с «я знаю, что делает эта транзакция и в каком порядке она исполняется» до «я знаю, что это за транзакция, но не знаю, что она сделает относительно окончательно упорядоченного набора». Для этого пропозер не должен контролировать окончательное упорядочивание. В модели с одним лидером одно лишь асинхронное исполнение такой защиты не дает: лидер по-прежнему полностью управляет порядком и может выгодно размещать собственные транзакции независимо от момента исполнения. Поверхность атаки сужает именно сочетание ограниченного упорядочивания и отложенного исполнения.

Обратите внимание, что асинхронное исполнение не закрывает уровень 2 полностью. Опытный пропозер по-прежнему может делать категориальные выводы. Например, он видит, что транзакция обращается к определенному пулу ликвидности, и может предположить ее вероятное направление, не зная точного результата. Тем не менее это существенно усложняет самые механические и прибыльные формы эксплуатации и представляет наиболее ясный архитектурный путь к сужению уровня 2 без криптографического сокрытия на уровне консенсуса. Примечательно, что именно такой подход выбрала Sei Giga, сделав асинхронное исполнение первоочередным архитектурным приоритетом наряду с MCP.

Возникает естественный вопрос, над которым стоит задуматься: почему сначала не занялись асинхронным исполнением? Оно сужает уровень 2 и теоретически могло быть реализовано как локальное изменение уровня исполнения без дополнительной протокольной сложности MCP: новых ролей нод, требований к синхронизации часов UTC, нерешенной архитектуры слешинга и удвоенных накладных расходов на создание шардов. 

Самый веский довод в пользу такой последовательности заключается в том, что асинхронное исполнение и MCP решают разные задачи. MCP предоставляет структурные ограничения упорядочивания, которых само по себе асинхронное исполнение обеспечить не может. Валидатор, который не способен моделировать результаты исполнения, но видит содержимое транзакции, все равно может управлять порядком в разрешенном протоколом окне. MCP решили внедрять первым, поскольку он структурно ограничивает уровень 1, а этот уровень представляет более очевидную и непосредственную экономическую угрозу. Встроить асинхронное исполнение в существующую синхронную модель Solana с учетом ее допущений о компонуемости и архитектуры программ сложнее, чем изначально заложить его в новую цепочку. Sei Giga может проектировать асинхронное исполнение с первого дня, а Solana — нет. Эта практическая асимметрия может объяснять приоритет MCP не хуже теоретических аргументов. Архитектура Alpenglow также делает MCP более реализуемым, чем это было бы при Tower BFT. Мы рассматриваем это в следующем подразделе о сложности протокола.

Верна ли такая последовательность — обоснованный открытый вопрос. Constellation не устраняет уровень 2, что проблематично с учетом новых векторов атак, которые MCP создает на уровне 3. В свою очередь, это может повысить прибыльность атак уровня 2, поскольку поверхности атак дополняют друг друга. Например, пропозер, видящий крупную транзакцию DEX, может задержать ее pshreds, чтобы вытеснить ее из текущего окна пакета, и одновременно опередить ее собственной транзакцией в том же окне. Видимость уровня 2 и игры со временем уровня 3 — взаимосвязанные инструменты в рамках одной поверхности атаки. По мере развития Solana они будут становиться лишь сложнее.

Слешинг

Криптографический контроль хорошо работает, когда нарушение создает проверяемый артефакт: например, конфликтующие подписи, неудачные проверки валидности или доказуемо некорректные обязательства. Constellation столь эффективно решает проблемы устойчивости к цензуре уровня 1, поскольку лидер, исключивший аттестованную транзакцию, создает невалидный блок, и эту невалидность можно доказать математически. Игры со временем и манипуляции задержкой не оставляют такого артефакта. Отдельный подобный случай невозможно отличить от обычной сетевой задержки. Нарушение проявляется как отсутствие действия, которое нельзя доказать криптографически. Единственный доступный рычаг — экономическое сдерживание, для которого требуется слешинг. 

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

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

Здесь децентрализованным финансам может пригодиться опыт традиционных финансов и подход регуляторов к манипуляциям на основе задержки. Например, контроль спуфинга в рамках закона Додда — Франка опирается на выявление статистических закономерностей, таких как соотношение отмененных и исполненных заявок, распределение времени отмены и корреляция с влиянием на цену, а не на доказательство намерения для каждой отдельной заявки. Ни один отдельный случай нельзя доказуемо считать преднамеренным. Однако закономерность доказуема. Та же логика применима здесь, поскольку статистическая регулярность объективна, даже если отдельные действия — нет. Кроме того, экономический стимул к манипуляциям присутствует в общедоступных наборах пропозеров не меньше, чем у высокочастотных трейдеров в традиционных финансах. Аналогия перестает работать в механизме правоприменения. Закон Додда — Франка опирается на регулятора с правом требовать документы, тогда как в среде без доверия механизмы выявления и наказания должны быть закреплены в самом протоколе.

Мы предлагаем адаптировать ноды-наблюдатели fisherman как возможный механизм устранения этого пробела. Изначально представленные в исследовании Vitalik о доступности данных, ноды fisherman можно адаптировать в класс наблюдателей, которые отслеживают данные аттестации на протяжении множества циклов и отправляют статистические доказательства мошенничества во встроенный протокол арбитража. Отдельное позднее поступление субъективно. Однако закономерность, детерминированно рассчитанная по n циклам, объективна. На том же принципе основаны доказательства мошенничества в оптимистичных роллапах, но здесь он применяется к временному поведению, а не к переходам состояния. Кроме того, встроенный протокол арбитража для статистических доказательств мошенничества по своей сути не отличается от новых инструментов управления, которые сейчас разрабатываются и позволят стейкерам переопределять голоса своих валидаторов в будущих предложениях управления. Если Solana готова создать инфраструктуру для переопределения голосов валидаторов стейкерами, техническая база для арбитражной системы на основе fisherman может быть ближе, чем кажется.

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

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

Сокрытие

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

Теоретический идеал — подход Garimidi и соавторов, использующий Hiding Erasure-Correcting Code (HECC) как примитив. В отличие от стандартного Reed-Solomon в Constellation, HECC предоставляет теоретико-информационную гарантию: злоумышленник, собравший меньше порогового числа шардов, ничего не узнает о содержимом транзакции. Constellation решила продолжить использовать кодирование стирания, уже работающее в Solana через Turbine.

Наиболее значимая недавняя разработка — Block Assembly Marketplace (BAM) от Jito. Он использует доверенные среды исполнения (TEE) для создания зашифрованного мемпула, в котором транзакции остаются конфиденциальными до исполнения. BAM показывает растущий реальный спрос на конфиденциальность содержимого в Solana. Однако у сокрытия на основе TEE есть ограничения: допущения о доверии переносятся на производителей оборудования. Для протокола, стремящегося работать без доверия, это существенное ограничение. Следует тщательно исследовать путь с использованием порогового шифрования как более принципиальной альтернативы.

BAM важен как внепротокольная попытка решить проблему видимости содержимого, которую Constellation откладывает. Jito располагает операционными возможностями для масштабной конфиденциальной обработки транзакций через BAM еще до запуска Constellation. Возникает вопрос, остается ли сокрытие на уровне протокола срочной задачей, если решение уровня приложений уже может его предоставить. Ответ полностью зависит от допущений о доверии и от того, считаются ли производители оборудования «достаточно» надежными по сравнению с теоретическими гарантиями протокола. Тем не менее считать это постоянным решением нельзя. Вероятно, BAM обеспечит конфиденциальность в ближайшей перспективе, а будущие версии Constellation рассмотрят пороговое шифрование как долгосрочную альтернативу.

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

Сложность протокола

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

В прошлом Solana приобрела печальную известность из-за многочисленных сбоев, преследовавших сеть в 2021 и 2022 годах. У них была общая причина: сложно учитывать пограничные случаи в новом высокопроизводительном протоколе под реальной нагрузкой. Более двух лет непрерывной работы сети с тех пор — настоящее достижение, добытое болезненным процессом итераций. Этот результат внушает уверенность в зрелости Solana. 

Теперь любое изменение протокола масштаба Constellation необходимо одновременно реализовать в Agave и Firedancer. Две независимые команды разработчиков должны согласовать семантику протокола, пограничные случаи и новые для обеих сторон временные допущения. Даже для одного Alpenglow это уже очень сложная задача, а Constellation только усугубит ее. Это не аргумент против продолжения работы. Скорее, будущий SIMD для Constellation должен содержать ясный план реализации в нескольких клиентах.

Финансовые организации начинают переходить в ончейн. Репутационные и экономические последствия крупного сбоя теперь значительно серьезнее, чем в 2021 году. Мы как сообщество должны честно оценивать сложность, которую привносит Constellation. К будущему SIMD необходимо подойти со строгостью, соответствующей требованиям глобальной финансовой системы. 

Естественно возникает вопрос: почему именно сейчас? Действительно ли стоит принимать риск такого обновления? Нельзя ли со временем внедрить постепенные улучшения, чтобы смягчить переход? Упомянутые исследования асинхронного исполнения и слешинга показывают, что постепенная альтернатива возможна. Возможна версия дорожной карты Constellation, при которой экосистема получает преимущества от поэтапного развертывания разных взаимодополняющих обновлений. Считать это благоразумием или искусственным замедлением — вопрос ценностей не меньше, чем технологий, и разумные люди могут придерживаться разных мнений. Мы создаем не только финансовую систему, но и систему смыслов.

На практике это уже происходит. Anza подтвердила, что слоты по 200 мс и лидерские окна по два слота появятся раньше Constellation. Это означает, что Solana получит значимые улучшения производительности, которые без полной сложности MCP устранят часть опасений сообщества по поводу задержки последовательности. Мы обсудим их в следующем разделе. Если слоты по 200 мс приблизят путь подтверждения Solana к прогнозируемым накладным расходам Constellation настолько, что предельная стоимость MCP станет небольшой, политически обосновать его будет значительно проще. Но если действующие участники рынка сочтут 200 мс «достаточно хорошим» результатом, срочность Constellation снизится. Сравнительные прогнозы задержки для слотов по 200 мс с Constellation и без него помогут сообществу сопоставить дополнительные затраты с дополнительной гарантией. Разумеется, придется дождаться будущего SIMD и предлагаемой реализации Constellation.

Самый сильный аргумент в пользу продолжения — окно возможностей, которое создает Alpenglow. Constellation наследует модель безопасности Alpenglow, использует Rotor как уровень распространения данных и выигрывает от устранения сложности Tower BFT. Дополнительная стоимость внедрения MCP поверх Alpenglow ниже, чем создание с нуля будущей архитектуры консенсуса. Ожидание тоже не бесплатно: конкуренты изучают возможности переноса MCP в ончейн, а перенос устойчивости к цензуре на будущий цикл обновлений неизбежно создаст собственные сложности и политическое сопротивление.

Если не сейчас, то когда?

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

Соответствует ли Constellation принципам IBRL?

Задержка последовательности и задержка включения

Первоначальная реакция сообщества Solana на Constellation была, мягко говоря, полярной. Она выявила важную дискуссию, требующую точного, а не дипломатичного ответа. Наиболее резкая формулировка прозвучала в публикации Cavey: «MCP и IBRL принципиально несовместимы». Он утверждает, что MCP прямо и несомненно снижает пропускную способность и увеличивает задержку в попытке улучшить структуру рынка. Ответ Toly был столь же прямым: «Ты ошибаешься. Без MCP снизить задержку включения невозможно».

Технически оба правы: они измеряют разные величины.

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

Задержка последовательности — время от отправки транзакции до ее исполнения. При MCP она неизбежно увеличивается, поскольку раунд аттестаторов, окно цикла 50 мс и этап сборки пакета требуют времени, которого нет в нынешнем пути отправки через TPU кооперативному лидеру. Верно, что рациональные участники, отправляя транзакции нескольким пропозерам, потребляют больше пропускной способности. Верно и то, что окно объединения добавляет задержку. Все это реальные издержки. Их следует измерить и представить сообществу как компромисс ради устранения жесткой цензуры.

Задержка включения — гарантированный период, в течение которого валидная и конкурентоспособная по комиссии транзакция будет включена. В современной модели с одним лидером эта гарантия фактически не ограничена. Лидер может задержать или исключить определенную транзакцию, и протокол никак не способен ему помешать. Задержка, которую пользователи уже испытывают, включает все издержки удержания, планирования и игр со временем, а также избирательное упорядочивание со стороны лидеров. Поэтому довод о том, что реальные сроки подтверждения включают задержки от этих игр и итоговый пользовательский опыт может улучшиться, в целом верен в рамках такой модели. Его подтверждают и текущие обсуждения сообщества в X. 

Настоящий вопрос заключается в том, какую задержку следует оптимизировать.

FIFO, FCFS и FBO

Прежде чем определять, какую задержку следует оптимизировать, стоит разобраться в связанной дискуссии, которую сообщество ведет параллельно: совместим ли MCP с FIFO.

FIFO (First In, First Out — «первым пришёл — первым вышел») — общий принцип упорядочивания, при котором транзакции обрабатываются в порядке поступления. Умберто подробно объяснил, почему ответ на этот вопрос по своей природе неоднозначен. MCP может обеспечить так называемый «вероятностный FIFO», но только при определённых инфраструктурных условиях. По сути, если пользователь географически находится достаточно близко к достаточному числу пропозеров, чтобы избежать цензуры, а те, в свою очередь, достаточно близки к аттестаторам, чтобы быстро достичь порога аттестации в 40% для гарантированного включения, то на практике пользователь получает включение по принципу FIFO. Иными словами, его транзакция включается до того, как конкурент успеет её заметить и отреагировать. Гонка заканчивается на этапе включения, а не исполнения. В таких условиях MCP приближается к FIFO как к возникающему свойству системы, а не как к правилу протокола.

Проблема в том, что текущая инфраструктура Solana не соответствует этим условиям. Стейк сосредоточен в нескольких регионах, поэтому формирование кворума ограничено необходимостью охватить регионы с высокой концентрацией стейка. Эта концентрация создаёт окно, в котором наблюдатель с «географическим преимуществом» может опередить транзакцию в процессе её передачи. Для результата географическое распределение и плотность аттестаторов при развёртывании Constellation, необходимые для вероятностного FIFO, не менее важны, чем сама архитектура протокола. Протокол, который гарантирует устойчивость к цензуре, но из-за разреженной инфраструктуры допускает опережение транзакций за счёт задержки, не обеспечит рыночную справедливость, обещанную в его техническом документе.

Связанный, но отдельный вопрос: могла ли Constellation реализовать FCFS, но решила этого не делать. В то время как FIFO — это возникающее свойство инфраструктуры, FCFS (First Come, First Served — «первым пришёл — первым обслужен») представляет собой конкретное правило протокола, которое гарантирует детерминированную обработку первой поступившей транзакции. Стоит отметить, что Constellation действительно задаёт детерминированный порядок: транзакции в каждом пакете сортируются по приоритетной комиссии. Поэтому вопрос не в том, закреплён ли порядок на уровне протокола, а в том, должно ли время поступления определять этот порядок относительно приоритетных комиссий.

Недавняя дискуссия выявила более фундаментальное возражение, чем предполагалось изначально: FCFS может быть в принципе невозможно обеспечить в системе без доверия. Валидаторы могут просто искажать порядок поступления транзакций, не оставляя никаких ончейн-следов. Это та же проблема отсутствия доказательств, из-за которой за манипуляции временем нельзя наказать слэшингом в традиционном смысле. Для её решения могут потребоваться более нестандартные подходы, например разработанный в подразделе о слэшинге метод статистического выявления закономерностей. Правило протокола, которому будут следовать честные валидаторы и которое нечестные смогут незаметно игнорировать, не даёт значимой гарантии. С этой точки зрения отсутствие FCFS в Constellation — уже не проектное предпочтение, требующее объяснения, а признание того, что в наборе валидаторов без разрешений FCFS, возможно, пока вообще нельзя реализовать в Solana как жёсткое свойство протокола, по крайней мере при текущих допущениях. Если при текущих допущениях FCFS действительно невозможно обеспечить в наборе валидаторов без разрешений, задача SIMD — прямо обозначить это ограничение и обосновать упорядочивание по приоритетной комиссии как правильный вариант по умолчанию. Если сообщество продолжит обсуждать FCFS как жизнеспособную альтернативу, которую Constellation просто решила не реализовывать, а не как свойство, которое может быть нереализуемым, это вызовет ещё больше разногласий в сообществе.

Упорядочивание по приоритетной комиссии в рамках фиксированного временного интервала — не новый компромисс. Этот подход известен как частый пакетный аукцион (FBA) — модель рыночной микроструктуры с серьёзной академической поддержкой. Например, Budish, Cramton и Shim в работе Гонка вооружений в высокочастотной торговле: частые пакетные аукционы как ответное решение для структуры рынка (2015) утверждают, что пакетные аукционы в дискретном времени с единой клиринговой ценой устраняют гонку за скоростью, порождаемую рынками непрерывного времени. Конкуренция на основе задержки заменяется конкуренцией по цене. Опираясь на этот подход, Constellation вводит Fixed Batch Ordering (FBO) на основе приоритетных комиссий. Таким образом, 50-миллисекундный цикл Constellation реализует эту модель: внутри каждого пакета транзакции конкурируют по комиссиям, а не по времени поступления, и ко всем транзакциям одного пакета применяются одинаковые правила упорядочивания. Это именно тот класс приложений, который ранее был обозначен как пока не существующий в Solana в значимом масштабе. 

Споры о FIFO, FCFS и FBO в основном сводятся к одному фундаментальному вопросу: кто контролирует порядок после того, как устойчивость к цензуре гарантирована, и действительно ли рыночная структура, которую стремится создать Constellation, справедлива или лишь менее несправедлива, чем существующая сегодня. Constellation устраняет наиболее очевидную форму манипуляций. То, что придёт ей на смену, зависит от решений, которые технический документ оставляет для SIMD.     

Итак, что именно мы оптимизируем?

Задержка последовательности наиболее важна для существующих торговых приложений, то есть AMM, проп-трейдинговых фирм и CLOB. Эти приложения построены на предположении, что побеждает тот, кто быстрее и предлагает наиболее конкурентные комиссии. Их инфраструктура создана с учётом этого принципа. Торговлю должны ограничивать только законы физики, обеспечивая непревзойдённый пользовательский опыт в Solana. Для некоторых из этих пользователей Constellation — шаг назад по самому важному для них показателю. Есть опасение, что Solana может повторить ту же фатальную ошибку, которую когда-то совершил Ethereum: отдать приоритет структуре рынка, а не производительности, из-за чего исполнение может уйти из сети. Это реальный риск, который стоит обсудить.

Для финансовых приложений, ради которых создаётся Constellation, то есть ончейн-аукционов, книг ордеров с надёжными гарантиями включения и устойчивых к цензуре протоколов DeFi, правильным показателем является задержка включения. Лимитный ордер, который можно опередить или выборочно задержать, даёт более слабые гарантии, чем ордер на бирже, независимо от номинальной скорости подтверждения. Теперь Solana может поддерживать торговые приложения с пакетными аукционами и единой клиринговой ценой, где порядок не должен влиять на цену исполнения. Сегодня в Solana этот класс приложений практически отсутствует именно потому, что нет гарантий включения. Можно утверждать, что Constellation чрезмерно ориентирована на пользователей, которых в Solana пока нет в значимом масштабе, в ущерб тем, кто уже есть. Этот аргумент уже выдвигают ключевые участники разработки.   

Опасения по поводу задержки последовательности следует рассматривать с учётом того, что сейчас Solana заметно уступает Hyperliquid в торговле бессрочными фьючерсами. Hyperliquid — специально созданная биржа бессрочных фьючерсов с централизованным секвенсором, которая не претендует на децентрализацию, но предлагает привлекательное исполнение менее чем за миллисекунду, необходимое профессиональным трейдерам и приложениям. Hyperliquid сознательно решила создать продукт, которым профессионалы действительно хотят пользоваться, пожертвовав основными принципами, делающими криптовалюты «криптовалютами». Неявный риск Constellation заключается в том, что добавление коммуникационных издержек и раундов аттестации в процесс подтверждения — это тот же компромисс, на который идёт Hyperliquid, но в противоположном направлении. Критики негативно относятся к отказу от любого потенциального преимущества в производительности, благодаря которому Solana сейчас конкурирует с централизованными торговыми приложениями, пока ещё нет финансовых приложений, оправдывающих этот компромисс. И они весьма громко об этом заявляют.

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

Однако здесь есть более глубокая проблема. Сравнение с Hyperliquid показывает, что смысл IBRL, возможно, со временем изменился. Изначальной мотивацией Toly и Raj при создании Solana была устойчивость к цензуре: «Чтобы продукты DeFi могли привлечь миллиарды пользователей и устройств, необходимо масштабировать устойчивость к цензуре… Это самая важная проблема, которую нужно решить, и главная причина, по которой мы создаём Solana». IBRL появился значительно позже как инженерное воплощение этой миссии: обеспечить такую скорость, чтобы децентрализованная сеть могла превзойти централизованную инфраструктуру по ключевым показателям. С тех пор IBRL обрёл собственный технооптимистический смысл и стал неотъемлемой частью культурного духа Solana. В нём в равной степени сочетаются инженерный диктат, культурный маркер и светская молитва. Для многих он стал целью, а не средством: минимизация задержки последовательности превратилась в самоцель, оторванную от задачи обеспечения устойчивости к цензуре, которой она изначально должна была служить.

Если этот сдвиг действительно произошёл, а судя по всему, так и есть, Constellation столкнётся с сильным культурным сопротивлением. Такая динамика не нова: сообщество уже отклонило SIMD-228, спорное предложение по снижению инфляции, которое не прошло голосование по управлению. Даже предложения, приносящие очевидную пользу большинству, могут провалиться, если противоречат укоренившимся убеждениям сообщества. Ситуация с Constellation сложнее, поскольку затраты пропускной способности и задержки реальны, но их совокупное влияние на пользовательский опыт не измерено. Без данных преждевременно делать однозначные выводы в любую сторону. Сообществу не хватает эмпирических данных о том, как выглядит путь подтверждения в реалистичных сетевых условиях, и Anza потребуется предоставить их для убедительного SIMD. Alpenglow не столкнулся с этой проблемой благодаря соответствию IBRL: он обеспечил стократное сокращение времени до финализации транзакции и упростил консенсус. Преимущества Constellation сложнее оценить интуитивно, но они не менее реальны, если будущие бенчмарки их подтвердят.

Похоже, сообщество будет оценивать обновление для обеспечения устойчивости к цензуре по показателю производительности, который оно никогда не было призвано оптимизировать. Более продуктивный вопрос — оправдан ли этот компромисс. Цена реальна и измерима: некоторое увеличение задержки последовательности и нагрузки на пропускную способность в обмен на жёсткую, закреплённую протоколом гарантию того, что ни один лидер не сможет выборочно исключить транзакцию. Это необходимое условие для финансовых приложений, которые Solana сейчас стремится привлечь.

По нашему мнению, Constellation соответствует IBRL при правильном понимании того, к чему IBRL всегда должен был стремиться. Придёт ли сообщество к тому же выводу, зависит не столько от технических достоинств, сколько от того, будут ли представлены эмпирические доказательства и объяснены проектные решения.  

Заключение

Constellation — первое формальное предложение на уровне протокола, предусматривающее масштабное внедрение MCP в рабочем блокчейне. Оно устраняет жёсткую цензуру на структурном уровне: транзакции с конкурентоспособной комиссией, аттестованные достаточным кворумом, нельзя исключить из валидного блока. Эта криптографическая гарантия расширяет возможности разработки в Solana. 

Не менее важно и то, что Constellation сознательно откладывает на будущее. Модель отправки Constellation частично снижает риск упорядочивания на основе видимого содержимого: содержимое транзакции видит только принимающий пропозер. Однако оставшаяся поверхность атаки растёт вместе с числом пропозеров, которым пользователь отправляет транзакцию. Манипуляции временем и задержкой остаются крупнейшей нерешённой проблемой, за которую при текущей архитектуре нельзя наказать. Возможные пути решения — асинхронное исполнение, слэшинг и сокрытие — обозначены, но не конкретизированы, и каждый из них добавляет собственные сложности. Технический документ Constellation честно описывает эти границы. Будущий SIMD должен быть столь же откровенным.

Самый сложный вопрос, который ставит Constellation, — может ли Solana позволить себе предлагаемые компромиссы. Затраты на задержку упорядочивания и пропускную способность реальны и измеримы, но пока не определены количественно. Вместе с тем гарантии включения дают реальную, но ещё не измеренную пользу, а базы приложений, которая оправдала бы её в масштабе, пока нет. Сообществу предлагают инвестировать в инфраструктуру для финансовых приложений, которые сегодня практически отсутствуют в Solana, потенциально в ущерб уже существующим торговым приложениям. Является ли это дальновидным шагом или преждевременным решением, зависит от данных, которых у сообщества пока нет.

Успех или провал Constellation в конечном счёте определят будущие эмпирические бенчмарки в реалистичных условиях. Самый важный показатель, который может предоставить Anza, — сравнение пути подтверждения только при слотах длительностью 200 мс и при слотах длительностью 200 мс с Constellation. До его появления сообщество обсуждает компромиссы, которые не может оценить количественно.

По нашему мнению, Constellation представляет собой правильный следующий шаг в дорожной карте протокола, возможность для которого открыл Alpenglow. Он соответствует IBRL в том понимании, ради которого изначально создавалась Solana. Однако эта оценка зависит от того, будет ли SIMD соответствовать уровню строгости, необходимому глобальной финансовой системе: в спецификации, поэтапном развёртывании, тестировании и эмпирическом обосновании, представленном сообществу, которому предлагается его принять.

Дополнительные материалы

• Budish, E., Cramton, P., and Shim, J. (2015). Гонка вооружений в высокочастотной торговле: частые пакетные аукционы как ответное решение для структуры рынка. https://doi.org/10.1093/qje/qjv027
• Daian, P., Goldfeder, S., Kell, T., et al. (2019). Flash Boys 2.0: опережение транзакций, изменение их порядка и нестабильность консенсуса на децентрализованных биржах. https://arxiv.org/abs/1904.05234
• Eskandari, S., Moosavi, S., and Clark, J. (2019). SoK: прозрачная нечестность — атаки с опережением транзакций в блокчейне. https://arxiv.org/abs/1902.05164
• Garimidi, P., Neu, J., and Resnick, M. (2025). Несколько параллельных пропозеров: зачем и как. https://arxiv.org/abs/2509.23984
• Kniep, Q., Resnick, M., Sliwinski, J., and Wattenhofer, R. (2026). Solana Constellation: интернет-рынки капитала. https://drive.google.com/file/d/1MiGlZ_OORdnq6znkVQ5LrenBF3kyBIWf/view
• Landers, S. and Marsh, B. (2025). MEV в блокчейнах с несколькими параллельными пропозерами. https://arxiv.org/abs/2511.13080
• Yakovenko, T., and Gokal, R. Разработчики блокчейнов сосредоточены не на той проблеме. CoinDesk, 2020. https://www.coindesk.com/markets/2020/12/30/blockchain-developers-are-focused-on-the-wrong-problem