Block Assembly Marketplace (BAM)

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

• Сегодня лидеры Solana единолично определяют порядок транзакций в своих слотах, а процесс формирования блоков остается непрозрачным. BAM предлагает проверяемую децентрализованную альтернативу, в которой логику упорядочивания можно проверить.
• В сети BAM обязанности четко разделены: ноды BAM получают, приоритизируют и фильтруют транзакции Solana, а валидаторы BAM отвечают за исполнение, консенсус и управление состоянием. Такой подход приближает Solana к архитектуре разделения предлагающей и формирующей блок стороны (Proposer-Builder Separation, PBS).
• Плагинная платформа BAM позволяет разработчикам задавать собственную логику упорядочивания и добавлять новые примитивы планирования. Это обеспечивает управляемое приложениями исполнение (Application-Controlled Execution, ACE), при котором приложения могут применять собственные правила планирования транзакций.
• Jito обязалась со временем открыть исходный код BAM и изначально проектирует систему с упором на прозрачность. Это значительное улучшение по сравнению с нынешним закрытым движком блоков Jito, которым управляет одна доверенная сторона.
• Ноды BAM будут работать на процессорах AMD с поддержкой усовершенствованной защищенной зашифрованной виртуализации и защищенной вложенной страничной организации памяти (Secure Encrypted Virtualization with Secure Nested Paging, SEV-SNP). Благодаря аппаратному ускорению накладные расходы SEV-SNP составляют всего 2–5%, что позволяет обрабатывать данные в реальном времени.
• Первый реализованный планировщик для нод BAM будет проводить в их мемпулах периодические внутриблочные аукционы, разделяя блок на N слотов и поровну распределяя CU между аукционами.
• Управляемое приложениями исполнение (ACE) может снизить потребность в роллапах или сетевых расширениях для применения собственной логики, помогая сохранить больше активности в основной сети Solana. Оно также значительно расширяет возможности создания новых приложений, использующих программируемое пространство блоков.
• Jito планирует направлять 100% комиссий протокола от Block Engine и будущей системы BAM в казначейство Jito DAO. Сейчас Jito взимает комиссию в размере 6% от чаевых и поровну делит ее между Jito Labs и DAO. Во II квартале 2025 года DAO получила через Tip Router 22 391,31 SOL (~4 млн долларов) из этих комиссий.
• BAM вдохновлена BuilderNet от Flashbots и использует похожий подход к формированию блоков в доверенных средах исполнения. В основной сети Ethereum уже около 40% блоков формируются в TEE.

Введение

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

BAM создает зашифрованный мемпул внутри доверенных сред исполнения (Trusted Execution Environments, TEE), где все транзакции остаются конфиденциальными до момента исполнения. Эта сохраняющая приватность архитектура призвана существенно сократить или даже устранить многие наиболее агрессивные формы MEV, обеспечивая пользователям более надежные гарантии исполнения и выгодные цены. Валидаторы смогут предлагать более качественное исполнение, а разработчики и поисковики — создавать решения непосредственно поверх нового программируемого уровня пространства блоков.

BAM реализует логику управляемого приложениями исполнения (ACE) через систему плагинов. Она поддерживает такие сценарии, как приоритетное сопоставление заявок маркетмейкеров для бессрочных контрактов, оперативные обновления оракулов, соблюдение сроков действия заявок и другие формы пользовательской маршрутизации и исполнения. Благодаря детальному контролю порядка транзакций разработчики смогут создавать в Solana более сложные и надежные финансовые примитивы, включая книги лимитных заявок, темные пулы и уровни агрегации.

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

BAM опирается на проверенный практикой подход и вдохновлена BuilderNet от Flashbots, применяя аналогичный метод формирования блоков в доверенных средах исполнения. В основной сети Ethereum уже около 40% блоков формируются в TEE, а в Unichain (специализированной L2-сети Uniswap) этот показатель достигает 100%. BAM переносит эту модель в Solana и дополняет ее встроенной поддержкой программирования на уровне приложений, исполнением с низкой задержкой и глубокой интеграцией с клиентами валидаторов Jito, которые сегодня защищают более 89% общего стейка через Jito-Agave и Jito-Firedancer.

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

Общий обзор BAM

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

Сама нода BAM включает блок обработки транзакций (TPU) и планировщик транзакций, работающие внутри TEE. Она также запускает сервер gRPC для связи с подключенными валидаторами. Модифицированный клиент Jito-validator содержит исполнитель по принципу «первым пришел — первым обслужен» (FIFO), оптимизированный для конкурентного и параллельного выполнения с помощью блокировок, учитывающих аккаунты.

Каждая нода BAM может обслуживать несколько валидаторов, но каждый валидатор одновременно подключается только к одной ноде BAM. Сейчас Jito управляет семью движками блоков. С BAM сеть планируется значительно масштабировать: от 50 до более чем 100 нод BAM во всех основных географических регионах для повышения децентрализации и отказоустойчивости. Нода BAM и валидатор обмениваются данными через двунаправленный поток gRPC. Валидатор в реальном времени передает результаты исполнения обратно ноде BAM.

Все транзакции в нодах BAM зашифрованы внутри доверенных сред исполнения (TEE) до момента исполнения, поэтому поток транзакций остается приватным вплоть до исполнения.

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

Аудиторский журнал содержит транзакции, переданные валидатору, и их порядок. Например, он фиксирует, что транзакции A, B и C были отправлены валидатору Helius в данном слоте. Система предлагает инструменты мониторинга и аналитики в реальном времени, позволяя пользователям отслеживать транзакции с момента отправки до исполнения. Пользователи и приложения смогут проверить, соблюдал ли валидатор BAM заданный порядок, и точно узнать, какой код выполнялся в ноде BAM.

Ноды BAM открыто видны в сети, подобно существующим ретрансляторам Jito. При подключении к BAM валидатор объявляет экземпляр BAM через порты TPU и TPU forward, которые служат точками входа для приема транзакций.

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

При поступлении в BAM транзакция проходит стандартную очистку, включающую дедупликацию, проверку подписи, формата, хеша блока, плательщика комиссии, одноразового номера и таблиц поиска адресов.

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

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

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

• Исключение нарушившего правила валидатора из сети BAM.
• Требование залога от валидаторов в форме облигаций, которые могут быть сокращены за нарушения (однако это может повысить барьеры входа для новых валидаторов).
• Применение черных или серых списков для полного или частичного ограничения участия нарушителей.

Комиссии

Jito Labs и Jito Foundation совместно готовят предложение по улучшению Jito (Jito Improvement Proposal, JIP), которое направит 100% комиссий протокола, полученных от Block Engine и будущей системы BAM, в казначейство Jito DAO. Ожидается, что предложение будет официально подано в ближайшие недели. Оно существенно меняет экономическую модель Jito и требует одобрения DAO. Если предложение примут, оно укрепит центральную роль DAO и держателей токенов JTO в экосистеме Jito.

Сейчас протокол Jito взимает комиссию в размере 6% от чаевых и поровну делит ее между Jito Labs и DAO. Только во II квартале 2025 года DAO получила 22 391,31 SOL (~4 млн долларов) из этих комиссий через Tip Router. Другой основной источник дохода DAO — комиссии jitoSOL, которые за тот же период составили 13 223,73 SOL (~2,38 млн долларов).

Доверенные среды исполнения (TEE)

Доверенная среда исполнения (Trusted Execution Environment, TEE) — это аппаратно защищенная архитектура, обеспечивающая конфиденциальность и целостность вычислений и памяти. TEE, также называемые анклавами, изолируют исполнение кода от операционной системы, ядра и гипервизора хост-системы, обычно на аппаратном уровне. Такая изоляция значительно сокращает поверхность атаки, поэтому наблюдать за операциями анклава или вмешиваться в них чрезвычайно сложно, хотя и не невозможно.

TEE применяются с 2000-х годов в таких областях, как управление цифровыми правами, защита контента и безопасные платежные системы. Сегодня их широко используют на потребительских устройствах и в облачных сервисах для безопасной обработки конфиденциальных данных и кода. На смартфонах и ноутбуках Apple Secure Enclave и Android TrustZone защищают биометрические данные, платежные реквизиты и ключи шифрования. Игровые консоли, такие как PlayStation и Xbox, используют процессоры AMD или Pluton для защиты от вмешательства и пиратства. В облаке такие провайдеры, как Azure и Google Cloud, применяют AMD SEV-SNP, Intel TDX или AWS Nitro Enclaves для изоляции рабочих нагрузок и конфиденциальных вычислений. Криптокошельки Ledger и Trezor используют защищенные элементы для хранения приватных ключей, а новый телефон Solana Seeker применяет TEE для той же цели.

TEE — стандартный аппаратный подход к обработке приватных данных и практичная альтернатива чисто криптографическим методам, таким как полностью гомоморфное шифрование (FHE) и безопасные многосторонние вычисления (MPC). Хотя FHE и MPC предоставляют надежные теоретические гарантии, на практике они часто неприменимы из-за высокой сложности и значительных накладных расходов.

BAM опирается на два ключевых свойства TEE:

Конфиденциальность: код и данные внутри TEE зашифрованы и изолированы от остальной системы. Ни операционная система, ни гипервизор, ни внешнее программное обеспечение не могут получить доступ к тому, что выполняется внутри анклава, или изучить его.

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

Реализация TEE в BAM

BAM будет работать на процессорах AMD, поддерживающих усовершенствованную защищенную зашифрованную виртуализацию и защищенную вложенную страничную организацию памяти (Secure Encrypted Virtualization with Secure Nested Paging, SEV-SNP). В отличие от подходов на основе небольших анклавов, SEV-SNP защищает все приложение BAM с минимальными накладными расходами. Поэтому технология хорошо подходит для систем транзакций с высокой пропускной способностью и низкой задержкой.

Благодаря аппаратному ускорению накладные расходы SEV-SNP составляют всего 2–5%, что позволяет обрабатывать данные в реальном времени. Технология поддерживает не только изолированные вычисления, но и сложные сетевые приложения с состоянием. Она проверена на практике: ее используют крупные облачные провайдеры, включая Google Cloud, Azure и AWS, а надежность подтверждают многолетние исследования безопасности и опыт эксплуатации.

Применяемая в BAM технология SEV-SNP предоставляет несколько ключевых гарантий безопасности. Каждый экземпляр TEE работает в отдельной аппаратно изолированной виртуальной машине, а память шифруется во время выполнения, обеспечивая надежную изоляцию на уровне виртуальной машины. BAM использует аттестацию с аппаратным корнем доверия, благодаря которой каждая TEE может криптографически доказать, что исполняет подлинный неизмененный код. Цепочка аттестации закреплена аппаратными корневыми ключами AMD, которые физически встраиваются в процессор при производстве. Кроме того, ключи TLS создаются внутренним аппаратным генератором случайных чисел процессора и никогда не попадают в незашифрованную память.

При подключении к BAM клиент получает сертификат TLS, содержащий стандартный сертификат подключения, отчет об аттестации AMD SEV-SNP и криптографическое доказательство того, что приватный ключ TLS был создан внутри аттестованной TEE. Эта цепочка сертификатов криптографически привязана к аппаратному корню доверия AMD. Ее невозможно подделать без доступа к приватным корневым ключам AMD, поэтому доверять каким-либо посредникам помимо процесса производства чипов AMD не требуется.

Плагины

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

Плагины решают эту проблему. 

Платформа плагинов BAM позволяет разработчикам реализовывать специализированную логику упорядочивания и добавлять новые примитивы планирования. Плагины обеспечивают управляемое приложениями исполнение (Application-Controlled Execution, ACE), позволяя приложениям задавать собственные правила планирования транзакций. У ACE много потенциальных применений, но самый известный и обсуждаемый сценарий — приоритизация отмен заявок в книге. Этот механизм снижает неблагоприятный отбор и позволяет уменьшить спреды.

Приоритет отмен заявок маркетмейкеров

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

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

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

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

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

Оперативные обновления оракулов

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

С BAM Pyth сможет обновлять определенные потоки цен именно тогда, когда они нужны, вставляя обновление оракула непосредственно перед транзакцией пользователя в том же блоке. Это снижает риски, связанные с устаревшими данными оракула, включая неэффективные ликвидации и манипуляции оракулом, и позволяет DeFi-приложениям работать надежнее и конкурентоспособнее.

Другие плагины

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

Кроме того, приложения смогут монетизировать функции плагинов, взимая комиссии. Часть доходов потенциально можно будет распределять между держателями токенов управления или валидаторами.

Перспективные плагины общего назначения

Плагины не ограничены одним приложением. Jito уже предложила несколько примеров универсальных межприложенческих плагинов, которые можно разработать для BAM:

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

Срок действия заявки (Time in Force, TIF): определяет, как долго заявка остается активной до автоматической отмены, если она не исполнена полностью. Например, транзакцию в книге заявок можно сделать действительной только в течение 20 миллисекунд. Примитивная версия этого механизма уже возможна в Solana: для нее намеренно используют старые хеши блоков, чтобы транзакция оставалась действительной только для последних блоков.

Предварительные подтверждения: пользователи могут получать уведомление о передаче транзакции валидатору до ее исполнения и распространения по сети. Это позволяет раньше подтверждать транзакции с определенным уровнем уверенности.

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

Агрегатор с низкой задержкой и запрос котировки (RFQ): пользователи отправляют торговые намерения непосредственно в BAM, где локальный агрегатор определяет оптимальный маршрут.

Отмена и замена транзакций: пользователи могут отправлять транзакции со специальными маркерами, позволяющими отменять, удалять или заменять ранее отправленные транзакции.

Этапы запуска

На этапе запуска Jito Labs будет управлять первоначальным набором нод BAM для обеспечения стабильности, производительности и безопасности. Группа первых партнеров-валидаторов с разрешенным доступом, включая Helius, SOL Strategies, Triton One и Figment, запустит клиент BAM. Вскоре после запуска они будут защищать несколько процентов общего стейка сети, близких к двузначному показателю. 

Параллельно первая группа приложений Solana, включая Drift, Pyth и DFlow, начнет проектировать и тестировать первую серию плагинов. Ожидается, что к завершению этапа запуска BAM подтвердит работоспособность ключевых функций и создаст основу для более широкого участия операторов нод и валидаторов. 

Валидаторы, разработчики приложений и поисковики, заинтересованные в участии в BAM, могут заполнить эту форму.

Консультативный комитет экосистемы, в который войдут видные представители сообщества валидаторов и разработчиков Solana, включая Solana Foundation, будет консультировать Jito Labs. Комитет поможет направлять расширение BAM, развивать децентрализацию и поддерживать инновации под руководством сообщества.

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

• Разработка плагинов: создание собственных плагинов для расширения возможностей BAM.
• Алгоритмы планирования: проектирование и добавление новых стратегий упорядочивания транзакций для конкретных сценариев.
• Библиотеки интеграции: разработка SDK на нескольких языках программирования для упрощения интеграции BAM.
• Инструменты аналитики: создание панелей мониторинга и систем наблюдения, использующих данные аттестации BAM.
• Исследовательский вклад: предложение и реализация новых подходов к снижению MEV и оптимизации системы.

Последствия

BAM может стать поворотным моментом для Solana и открыть новую волну инноваций, решив проблемы, связанные с эксплуатацией MEV и эффективной компоновкой блоков. Защищённое TEE упорядочивание и фреймворк плагинов BAM могут снизить стимулы для команд приложений создавать сетевые расширения, роллапы или разрешительные среды Solana, чтобы реализовать собственную логику или особые правила использования пространства блоков. Благодаря этому больше активности останется в основной сети Solana. Кроме того, увеличение лимитов вычислений на блок и спрос на более эффективные токен-программы и фреймворки, использующие меньше CU (например, растущая популярность Pinocchio и p-token), повысят пропускную способность основной сети и ещё сильнее снизят стимулы для разработчиков создавать собственные решения.

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

Сокращение MEV с помощью BAM может негативно повлиять на выручку Jito, повторив последствия отключения мемпула в 2024 году, которое снизило краткосрочные доходы, но в итоге принесло пользу сети. Улучшения BAM могут компенсировать это за счёт общего роста объёма транзакций и комиссий плагинов, повышая долгосрочную выручку благодаря более широкому внедрению. Однако точная реализация BAM, поэтапный запуск и экономика создают потенциальные риски централизации и открытые вопросы, которые мы рассмотрим в следующих разделах. Тем не менее этим рискам и открытым вопросам противостоят различные преимущества, каждое из которых имеет собственные последствия для перераспределения MEV, PBS и разработки «нового» клиента.

Перераспределение MEV

BAM фундаментально меняет ландшафт MEV в Solana: вместо неконтролируемого извлечения ценности появляется более структурированная модель перераспределения. В традиционных системах MEV часто отнимает ценность у пользователей через опережение транзакций или спам, а валидаторы и боты получают выгоду с помощью вредоносных тактик, таких как сэндвич-атаки. Однако зашифрованный с помощью TEE мемпул BAM скрывает транзакции до исполнения, ограничивая видимость для отрицательного MEV. Вместо этого ценность остаётся внутри системы благодаря плагинам и настраиваемому упорядочиванию. Это, в свою очередь, позволяет приложениям, разработчикам и поисковикам извлекать положительные формы MEV, повышающие эффективность экосистемы (например, сужать спреды DeFi и сокращать спам оракулов).

При таком перераспределении прибыль от MEV возвращается заинтересованным сторонам: комиссии плагинов распределяются между операторами нод BAM, валидаторами, стейкерами и DAO Jito. Это может создать устойчивые источники дохода. Например, DEX может использовать плагин, который оптимизирует сопоставление ордеров и преобразует потенциальный MEV, извлекаемый валидаторами, в комиссии приложения, которые можно распределить между держателями токенов. Такой «защищённый» подход к действиям трейдеров может превратить MEV из игры с нулевой суммой в механизм, углубляющий ликвидность и привлекающий институциональный капитал.

Однако перераспределение сопряжено с рисками. Важно понимать: BAM не устраняет MEV, а перемещает его. Из-за этого первые авторы плагинов, операторы нод BAM и связанные с Jito организации могут получить непропорционально большую выгоду. Несмотря на ограничения, накладываемые криптографическими аттестациями, появление уязвимостей TEE (например, атак по сторонним каналам) может предоставить поисковикам привилегированный доступ и создать новые скрытые способы извлечения ценности, что в итоге подорвёт гарантии конфиденциальности. Это также открывает возможности для «защищённых» форм бэкраннинга, при которых поисковики могут развёртывать код, добавляющий транзакции после пользовательской (например, чтобы получить арбитражную прибыль от свопа, изменившего цену), не раскрывая стратегии и не допуская опережения. Кроме того, при отсутствии программного слэшинга адаптивные злоумышленники могут применять вредоносные стратегии, связанные с аттестациями, которые выполняются после исполнения и сейчас зависят от контроля сообщества.

В конечном счёте перераспределение MEV делает BAM катализатором главной цели Solana — создания децентрализованного аналога NASDAQ. Однако успех зависит от внедрения справедливых моделей комиссий и надёжной защиты TEE. При неправильной реализации BAM может фрагментировать сеть, подорвать доверие пользователей и привлечь внимание к «защищённой», но непрозрачной деятельности поисковиков.

Разделение ролей предлагающего блок и сборщика (PBS)

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

Разделение ролей предлагающего блок и сборщика (PBS) — это архитектурный подход, который отделяет сборку блока от его предложения. В этой модели сборщики блоков формируют упорядоченные списки транзакций и подают заявки на эти блоки. Затем предлагающие блоки, обычно валидаторы, принимают и фиксируют блок с максимальной ставкой, перераспределяя MEV через аукционы или чаевые без необходимости самостоятельно применять сложные стратегии упорядочивания. 

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

С BAM Solana движется к будущему, похожему на PBS: конструирование блоков, то есть упорядочивание в защищённых TEE нодах BAM, отделяется от исполнения, которое остаётся обязанностью валидаторов. Это может демократизировать положительные формы MEV для приложений и поисковиков через плагины. Однако существует и риск усиления централизации стейка Solana, если экономика плагинов будет благоприятствовать действующим крупным участникам. Это уже заметно в Ethereum, где три сборщика (Titan Builder, BuilderNet и Beaverbuild) теперь формируют более ~90% всех блоков, что создаёт проблемы доверия к ретрансляторам и барьеры для небольших участников. 

Хотя MEV-Boost внедрил PBS в Ethereum, более корректным объектом сравнения здесь будет BuilderNet — децентрализованная сеть сборки блоков, запущенная в ноябре 2024 года и управляемая Flashbots, Beaverbuild и Nethermind. BuilderNet использует TEE для конфиденциальной сборки блоков и распределяет этот процесс между несколькими операторами нод, чтобы нейтрализовать эксклюзивные соглашения о потоках ордеров и снизить централизацию. Система ориентирована на создание ценности — например, распределение возвратов MEV между поставщиками потока ордеров, включая пользователей, кошельки и приложения, — а не на борьбу за потоки ордеров, например за частные сделки. BuilderNet по-прежнему использует ретрансляторы MEV-Boost, но они не являются строго обязательными: сборщики и предлагающие блоки могут взаимодействовать напрямую внутри TEE. 

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

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

Выше: сравнение PBS в Ethereum с BAM в Solana

Появление «нового» клиента

Клиент Jito-Agave во многом повторяет основную кодовую базу Agave и отличается от неё главным образом добавленными возможностями MEV. Модель Jito «Agave плюс MEV» позволила клиенту без проблем интегрироваться в существующую экосистему валидаторов Solana, повысив вознаграждения при минимальных изменениях основной архитектуры. В результате на момент написания статьи клиент Jito-Agave лидирует в сети: его используют 79% валидаторов. Таким образом, валидаторы могут полагаться на базовую логику Agave и одновременно получать дополнительный доход от Jito.

BAM означает отход от прежнего подхода Jito, при котором клиент во многом повторял Agave. Появление отдельной сети нод BAM создаёт новый инфраструктурный уровень. В результате Jito превращается из простого «Agave с улучшениями» в более самостоятельный клиент с собственной программируемой экосистемой для встраивания логики конкретных приложений.

Это расхождение заметно на примере готовящихся привязок планировщика Agave, о которых Anza объявила в мае. По мере развития MEV в Solana собственные реализации планировщиков становятся всё более распространёнными. Хотя собственные планировщики могут повысить доход операторов, их текущие реализации имеют несколько недостатков: необходимость запускать бинарный файл другой версии валидатора, зависимость от закрытого исходного кода и потенциальные проблемы с работоспособностью. 

Готовящиеся привязки планировщика Anza добавляют модульность, позволяя валидаторам подключаться к внешним сервисам сборки блоков без изменения основного бинарного файла валидатора и использовать собственные планировщики. Такая архитектура повышает прозрачность и безопасность, а также упрощает DevOps. Однако BAM избавляет пользователей Jito от необходимости использовать эти привязки, поскольку упорядочивание выполняется на предыдущем этапе планировщиком ноды BAM. Это позволяет обойти запланированные привязки планировщика Agave и потенциально упростить работу, но вызывает вопросы о будущей фрагментации экосистемы из-за расхождения с усилиями Anza по стандартизации — например, это может усложнить интеграцию с Firedancer.

Однако Jito позиционирует BAM как часть единого клиента валидатора. Валидаторы BAM будут запускать обновлённую версию клиента Agave с интегрированным планировщиком BAM и принимать от нод BAM только транзакции в порядке FIFO. Такая архитектура предотвращает фрагментацию клиентов и одновременно повышает устойчивость системы. Jito планирует выпустить совместимый с BAM клиент до запуска модульного планировщика Anza. Этот шаг подчёркивает двойственный эффект BAM: система стимулирует инновации и развивает инфраструктуру MEV в Solana, но также рискует ещё сильнее закрепить Jito в роли доминирующего клиента валидатора.

Также возможно, что BAM будет использовать эти привязки. Если BAM будет работать внутри модульного планировщика, поддержка Firedancer станет элементарной и возникнет новый вопрос: действительно ли Jito нужен собственный клиент валидатора? Ответ покажет время — после публикации исходного кода и запуска BAM.

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

Сокращение роли валидаторов

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

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

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

Остаётся несколько вопросов:

• Как валидаторы смогут конкурировать в чём-либо, кроме оборудования и времени бесперебойной работы, если ноды BAM отвечают за упорядочивание и извлечение MEV? 
• Если BAM получит широкое распространение, снизит ли ориентация валидаторов исключительно на исполнение общую децентрализацию Solana? Если да, какими метриками можно измерить это снижение?
• Если BAM подтолкнёт валидаторов к более вредоносным способам поиска дохода, какие защитные меры, помимо аттестаций, смогут предотвратить это без дальнейшего ослабления стимулов?
• Могут ли уязвимости TEE или эксплуатация плагинов привести к несправедливому наказанию валидаторов? 
• Учитывая опыт Ethereum с PBS, что может сделать Solana, чтобы противодействовать сокращению самостоятельности валидаторов?

Злонамеренные операторы нод

Архитектура BAM вводит новые предположения о доверии к валидаторам. В частности, предполагается, что при взаимодействии с нодами BAM валидаторы не будут действовать злонамеренно — например, изменять заранее упорядоченные транзакции или допускать утечки данных. На момент запуска из-за ограничений TEE BAM будет использовать разрешительный набор операторов. Им доверят запуск обновлённого клиента Jito-Solana и добросовестное исполнение перенаправленных транзакций. Эти валидаторы должны доверять нодам BAM и рассчитывать, что те не будут манипулировать входящим потоком. Это создаёт два уровня доверия — к нодам BAM до TEE и к валидаторам после TEE — и повышает риск в разрешительной системе. Ключевой вопрос: что мешает операторам нод BAM просматривать транзакции до их попадания в TEE? Ответ — шифрование QUIC для проверенных нод: аттестация будет встроена в сертификат QUIC. Проверить честность нод BAM также можно, сопоставив их хеши с открытым репозиторием BAM и убедившись, что конкретная нода BAM действительно запускает заявленное ПО. Если предположить, что TEE не взломана, сертификаты QUIC для TPU будут создаваться внутри TEE. Поэтому весь входящий и исходящий трафик будет зашифрован.

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

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

Остаётся несколько вопросов:

• Если злонамеренный оператор цензурирует пакеты или допускает утечку данных, как будут применяться меры воздействия?
• Как на разрешительном этапе процесс выбора операторов предотвратит сговор и какие метрики можно использовать для оценки прогресса в направлении децентрализации? 

Компонуемость и взаимодействие плагинов

Один из важнейших открытых вопросов для BAM — как плагины будут взаимодействовать друг с другом на практике. Одна транзакция может одновременно зависеть от нескольких плагинов: например, от плагина оракула для своевременного обновления цен, плагина DEX для определения оптимальных маршрутов свопа и токен-плагина для обработки особенностей конкретных токенов SPL. Критически важно обеспечить предсказуемую и безопасную совместную работу этих компонентов.

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

Дополнительную сложность создаёт взаимодействие логики плагинов на уровне приложений с механизмом комиссий Solana. Как будут взаимодействовать порядок исполнения плагинов, чаевые Jito и приоритетные комиссии, когда несколько плагинов конкурируют за влияние на сборку блока? Эти экономические механизмы необходимо чётко определить и прозрачно применять, чтобы избежать непреднамеренных манипуляций или злоупотреблений.

Для управления этими рисками запуск плагинов BAM, как ожидается, начнётся в разрешительной среде. Это позволит экспериментировать и проверять поведение плагинов на раннем этапе, а затем постепенно перейти к модели без разрешений.

Доверие к TEE и ответственность

Зависимость от TEE вводит новые предположения о доверии, поскольку для гарантии проверяемых вычислений используется специальный аппаратный анклав вместо создания системы, не требующей доверия. Зависимость от одного поставщика оборудования, например Intel или AMD, создаёт риски монокультуры: отзыв прошивки или уязвимость могут остановить BAM и, в зависимости от распространённости системы, привести к простою всей сети. Если такие уязвимости невозможно устранить обновлением прошивки, микрокода или BIOS, замена оборудования потребует времени и создаст регулярные капитальные расходы для операторов нод BAM, ещё сильнее усугубляя последствия потенциального простоя. 

Эти опасения основаны на исторических уязвимостях, показавших, что TEE могут давать сбои и потенциально раскрывать зашифрованные данные. Например, технология Software Guard Extensions (SGX) от Intel страдала от множества проблем, затронувших блокчейны. В августе 2022 года Secret Network была подвержена уязвимостям xAPIC и MMIO. Вместе они позволяли извлечь начальное значение консенсуса — главный ключ расшифровки приватных транзакций, исполняемых в сети. 

Множество других проблем в итоге привело к тому, что Intel прекратила поддержку SGX в процессорах Intel Core 11-го и 12-го поколений. У Secure Encrypted Virtualization-Secure Nested Paging (SEV-SNP) от AMD также есть несколько раскрытых уязвимостей. В частности, в феврале была раскрыта CVE-2024-56161 — уязвимость, позволявшая при наличии административного доступа внедрять вредоносный микрокод. 

Обновления для устранения уязвимостей не всегда обратно совместимы и могут требовать физической модернизации. Например, раскрытие CVE02020-12967 и CVE-2021-26311 означало возможность произвольного исполнения кода внутри гостевых виртуальных машин на системах AMD Secure Encrypted Virtualization-Encrypted State (SEV-ES), предыдущем поколении реализации TEE этой компании. AMD не выпустила обновлённую прошивку для устранения этих уязвимостей и реализовала защиту в функции SEV-SNP, которая поддерживалась только процессорами AMD EPYC 3-го поколения, то есть «Milan». 

Инфраструктура TEE BAM построена на архитектуре SEV-SNP последнего поколения, включающей аппаратные средства защиты, необходимые для предотвращения этих известных атак. Также важно отметить, что при обнаружении уязвимости нулевого дня сеть сможет продолжить работу, поскольку валидаторы Jito могут автоматически переключиться на собственный TPU при отключении от ноды BAM. Этот механизм аварийного переключения позволяет валидаторам продолжать работу во время установки исправлений безопасности.

Остаётся несколько вопросов:

• Как зависимость BAM от поставщиков оборудования влияет на долгосрочное доверие с учётом прошлых атак? Можно ли использовать альтернативы, такие как среды исполнения с нулевым доверием (ZTEE), чтобы снизить эту зависимость?
• Кто будет нести ответственность за финансовые потери, если из скомпрометированной TEE произойдёт утечка данных приватных транзакций?
• Как восстановить доверие после сбоя TEE? Можно ли предложить альтернативу?

Заключение

Валидаторы могут свободно выбирать программное обеспечение. Это коммерческие компании, работающие на высококонкурентном рынке, поэтому их решения зависят от потенциальной доходности как для них самих, так и для их делегаторов. Делегаторы, в свою очередь, могут перевести стейк туда, где доходность выше. Широкое распространение клиента Jito отражает эту динамику: его успех во многом обусловлен способностью приносить дополнительный доход операторам и делегаторам. Внедрение BAM будет зависеть от тех же факторов. Если использование BAM окажется стабильно выгоднее текущего подхода, валидаторы перейдут на него. В противном случае они могут не решиться на переход, даже если BAM принесет значительную пользу другим участникам экосистемы.

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

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

• Представляем BAM: будущее формирования блоков в Solana - Jito
• Серия о BAM на доске - Jito Learn
• Jito BAM и будущее Solana - 0xResearch