Обновление Agave v2.2: всё, что нужно знать

Основные изменения цикла выпуска Agave 2.2 

• Масштабная оптимизация производительности
• Увеличение лимита блока на 20% — с 50 млн до 60 млн CU
• Внедрение Accounts Lattice Hash (ALH)
• Проверка подписей Secp256r1 (перенесена из цикла выпуска Agave 2.1)
• Развертывание и выполнение программ SBPFv1, v2 и v3
• Снятие ограничения на вызывающую сторону CPI
• Loader-v4

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

Развертывание функций

На момент написания статьи на Agave v2.2 работает 19,8% общего стейка.* Это указывает на активную поддержку внедрения обновления по всей сети. На период обновления активацию feature gate в mainnet временно приостановили. Ожидается, что она вскоре возобновится в соответствии с запланированной последовательностью.

Большинство основных функций Agave 2.2 сейчас закрыты feature gate и еще не активны в mainnet. Их будут постепенно включать в течение цикла выпуска 2.2 с помощью системы feature gate Solana. Срок активации зависит от приоритета функций и порядка их развертывания в кластерах testnet и devnet. Актуальную информацию смотрите в трекере feature gate Agave.

Увеличение лимита блока до 60 млн CU

Anza поставила амбициозную цель на 2025 год: удвоить доступное пространство блока в Solana. В рамках этой работы SIMD-0256: увеличение лимита блока до 60 млн планируется включить в предстоящий выпуск Solana 2.2. Это на 20% больше текущего лимита блока.

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

Примечание. Некоторые блоки выглядят заполненными на 104% из-за жестко заданной константы в логике формирования отчетов панели Firedancer.

Другие ограничения протокола в этом обновлении не изменились:

• Бюджет вычислений на один аккаунт в блоке по-прежнему составляет 12 млн CU.
• Максимальный объем вычислений на транзакцию по-прежнему ограничен 1,4 млн CU.
• Совокупный лимит вычислений для голосующих транзакций в блоке по-прежнему составляет 36 млн CU.
• Максимальный объем новых данных аккаунтов в блоке по-прежнему ограничен 100 МБ.

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

Сложности при увеличении лимита блока

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

1. Готовность инфраструктуры

Инфраструктура всей экосистемы должна развиваться в том же темпе, что и оптимизация основного клиента. В частности, слой записи не должен опережать слой чтения — например, RPC-ноды, индексаторы и сервисы архивирования. Иначе пользовательский опыт ухудшится.

2. Своевременное распространение блоков

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

Особенно острая проблема возникает на этапе повторной передачи в модуле проверки транзакций (TVU), через который шарды распространяются по кластеру. Крупные валидаторы приближаются к 150 000 исходящих пакетов в секунду (PPS) из-за агрессивного коэффициента ветвления Turbine, равного 200. То есть каждая нода отвечает за ретрансляцию шардов 200 другим нодам. Неэффективная обработка может привести к накоплению шардов, нестабильной передаче роли лидера и расхождениям в представлении состояния между узлами сети.

Чтобы решить эту проблему, инженеры Anza сейчас полностью перерабатывают конвейер распространения блоков. Команда работает над переходом на XDP (eXpress Data Path), который позволяет обходить ядро, передавая обработку пакетов непосредственно в пользовательское пространство. Такой подход исключает ресурсоемкое промежуточное копирование и позволяет ПО валидатора напрямую взаимодействовать с сетевой картой (NIC).

Accounts Lattice Hash (ALH)

Чтобы Solana могла поддерживать миллиарды аккаунтов, нужен более масштабируемый подход к хешированию глобального состояния аккаунтов. Новый механизм Accounts Lattice Hash (ALH) заменит прежние хеши аккаунтов на основе дерева Меркла более эффективной и масштабируемой альтернативой на основе гомоморфного хеширования. Оно позволяет создавать новый хеш из существующих без полного пересчета с нуля.

Сейчас Solana хранит два хеша состояния аккаунтов:

• Epoch Accounts Hash (EAH): корень дерева Меркла для всего состояния аккаунтов, который вычисляется один раз за эпоху.
• Accounts Delta Hash (ADH): корень дерева Меркла для аккаунтов, измененных в одном блоке, который пересчитывается для каждого блока.

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

Принцип работы Accounts Lattice Hash

ALH достигает этой цели с помощью гомоморфной хеш-функции, которая допускает инкрементальные обновления. Вместо перестроения дерева Меркла ALH просто прибавляет или вычитает хеши отдельных аккаунтов (LtHashes) при записи в них. В результате получается единый хеш размером 2048 байт, который обобщает состояние всех аккаунтов. Главное преимущество — его можно обновлять для каждого блока без полного пересчета с нуля.

Этот подход обеспечивает сложность O(n), что значительно лучше сложности O(n log n) у деревьев Меркла. Благодаря ему каждый блок может содержать хеш всего состояния аккаунтов без ресурсоемкого пересчета.

Интеграция и вывод хешей из эксплуатации

Развертывание охватывает три отдельных SIMD с соответствующими независимыми активациями feature gate в течение цикла выпуска Agave 2.2.

• SIMD-0215: Accounts Lattice Hash
• SIMD-0220: использование Accounts Lattice Hash в снимках
• SIMD-0223: удаление Accounts Delta Hash

После этих изменений Accounts Lattice Hash заменит ADH и EAH. ALH будет интегрирован в банковский хеш каждого блока, что позволит хешировать полное состояние с частотой блоков, а не эпох.

Производительность и компромиссы

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

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

Интеграция снимков

Поскольку первоначальное вычисление Accounts Lattice Hash требует значительных ресурсов, значение ALH теперь сохраняется в снимках валидатора и при наличии восстанавливается во время запуска. В снимках будет использоваться обновленный формат ALH вместо Snapshot Hashes на основе дерева Меркла. Это дополнительно унифицирует модель хранения и хеширования Solana вокруг новой архитектуры.

Нативная проверка подписей Secp256r1

Solana добавляет нативную поддержку проверки подписей на эллиптической кривой secp256r1. Это важное обновление обеспечивает ончейн-совместимость с Passkeys, стандартом WebAuthn и продвинутыми моделями абстракции аккаунтов, включая двухфакторную аутентификацию (2FA). Обновление переносит беспарольную аутентификацию, уже повсеместно распространенную в Web2, в Web3 и повышает безопасность и удобство ончейн-приложений.

Изначально эту функцию планировали выпустить в Agave 2.1, но перенесли в версию 2.2. Подробнее читайте в нашем подробном разборе проверки подписей Secp256r1 в обновлении Agave 2.1.

Ошибка выравнивания прекомпилированных программ

Вскоре после начала развертывания Agave 2.2 в реализации прекомпилированных программ Secp256r1 и Ed25519 обнаружили критическую ошибку. Она возникала при использовании нового флага представления `--transaction-structure`, который открывает необработанную структуру транзакции без гарантии выравнивания. Прекомпилированные программы ошибочно предполагали 2-байтовое выравнивание данных инструкции. Это приводило к различным результатам выполнения у производителей блоков и валидаторов. В результате банковские хеши не совпадали, лидеры были вынуждены прерывать работу, а доступность сети снижалась. О проблеме впервые сообщили 9 апреля, а уже к 11 апреля ее исправили. Ошибка не повлияла на средства пользователей. Дополнительная информация представлена в анализе первопричины, опубликованном вскоре после инцидента.

Развертывание и выполнение программ SBPFv1, v2 и v3

Solana Berkeley Packet Filter (SBPF) — специализированная виртуальная машина для эффективного и безопасного выполнения программ Solana. Это основанный на Rust форк расширенного Berkeley Packet Filter (eBPF), изначально созданного для Linux. 

Обновления Solana Berkeley Packet Filter (SBPF) необходимы для повышения производительности, усиления безопасности и предоставления разработчикам приложений новых возможностей. Agave 2.2 закладывает основу для долгосрочной поддержки и улучшения производительности, внедряя формальную систему версий виртуальной машины SBPF, впервые описанную в SIMD-0161. Это изменение позволяет развертывать и выполнять программы SBPFv1 (SIMD-0166), SBPFv2 (SIMD-0173, SIMD-0174) и SBPFv3 (SIMD-0178, SIMD-0179, SIMD-0189). Так формируется устойчивая архитектура для поэтапного развития среды выполнения программ без необходимости повторного развертывания во всей сети.

До сих пор все обновления SBPF приходилось внедрять через глобальные feature gate. Это усложняло развитие среды выполнения и делало координацию развертывания почти невозможной. Версионирование решает эту проблему: поведение программы больше не зависит от глобальной среды выполнения, а определяется тегом версии отдельной программы, закодированным в поле e_flags заголовка файла Executable and Linkable Format (ELF). Такой подход обеспечивает следующие возможности:

Явно заданное поведение среды выполнения

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

Контролируемое развертывание

Feature gate будут независимо разрешать развертывание и выполнение новых версий SBPF, постепенно выводя старые версии из эксплуатации. Полные наборы изменений объединяются в отдельные версии SBPF, что упрощает обновление и управление им.

Поэтапное прекращение поддержки

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

Дискриминатор версии

Сейчас протокол рассматривает любое значение e_flags, кроме 0x0020, как SBPF v0. Это допустимо в текущей системе. Однако такой подход не масштабируется для поддержки нескольких версий SBPF, поэтому его необходимо изменить.

После активации первого feature gate, разрешающего новую версию SBPF, протокол изменит интерпретацию e_flags и начнет напрямую сопоставлять значение с номером соответствующей версии SBPF. В этой системе 0x0000 будет обозначать SBPF v0, 0x0001 — SBPF v1 и так далее.

Снятие ограничения на вызывающую сторону CPI

Цикл выпуска Agave 2.2 включает долгожданное улучшение, которое снимает историческое ограничение на межпрограммные вызовы (CPI). Сейчас вызывающая сторона должна явно передать любую вызываемую через CPI программу как аккаунт инструкции. Это усложняет формирование транзакций и создает значительные вычислительные издержки, особенно при глубоко вложенных CPI. Однако это ограничение имеет исключительно исторические причины и больше не требуется текущему протоколу.

SIMD-0163 снимает это ограничение и позволяет инструкциям CPI напрямую ссылаться на аккаунты программ из списка аккаунтов верхнего уровня транзакции. Больше не нужно рекурсивно передавать эти аккаунты через каждый уровень вызовов. Изменение дает следующие преимущества:

• Значительно сокращает расход CU, устраняя избыточную сериализацию и десериализацию аккаунтов программ. Исключение — программы loader-v3, которые хранят исполняемый файл в отдельном аккаунте. Эти операции особенно затратны из-за большого размера аккаунтов (двоичные файлы размером ~10 МБ).
• Упрощает формирование транзакций: аккаунты вызываемых программ больше не нужно передавать через стеки инструкций.
• Улучшает компонуемость и упрощает создание модульных архитектур программ с глубокой вложенностью.

Обратная совместимость

Изменение не затрагивает существующие программы, если они не хотят использовать его преимущества. В этом случае им доступен один из следующих вариантов:

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

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

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

Loader-v4

Agave 2.2 добавляет поддержку Loader-v4 — упрощенного и более гибкого механизма развертывания программ, который должен заменить Loader-v3. Loader-v4, активируемый через SIMD-0167, упрощает управление аккаунтами программ, улучшает процессы обновления и добавляет важные функции безопасности для работающих программ, особенно в средах с высокими рисками, таких как DeFi.

Ключевые функции Loader-v4:

Модель с одним аккаунтом: Loader-v4 устраняет необходимость в прокси-аккаунтах и отдельных буферах данных программы. Теперь каждая программа представлена одним аккаунтом.

Режим обслуживания

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

Произвольное изменение размера

Loader-v4 позволяет как увеличивать, так и уменьшать двоичные файлы программ после развертывания. Это повышает гибкость распределения ресурсов и позволяет возвращать заблокированные средства.

Необязательное использование буфера

В отличие от Loader-v3, где для повторного развертывания всегда требовался внешний аккаунт буфера, в Loader-v4 буферы необязательны. Теперь программы можно повторно развертывать непосредственно в основном аккаунте программы. Это вдвое сокращает объем средств, которые необходимо блокировать во время загрузки.

Частичное повторное развертывание

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

Бесшовная миграция с Loader-v3

Программы, развернутые с помощью Loader-v3, можно перенести на Loader-v4 без изменения адреса программы. Для этого в Loader-v3 добавлена новая инструкция Migrate. Это действие активирует отложенную видимость, поэтому программа будет недоступна до конца текущего слота.

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

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

Механизмы управления полномочиями и закрытия аккаунтов в Loader-v4 остаются прежними. Все эти возможности будут доступны через новую подкоманду program-v4 в CLI.

Заключение

Agave 2.2 — важная веха для протокола Solana. Выпуск содержит критически важные улучшения среды выполнения и новые возможности, которые расширяют технические границы сети. В нем представлены несколько ключевых изменений: увеличение емкости блока на 20%, интеграция Accounts Lattice Hash (ALH) для масштабируемого хеширования состояния, ряд улучшений для разработки программ и поддержка проверки подписей Secp256r1, необходимая для массового внедрения криптографических интеграций. Вместе эти улучшения повышают пропускную способность, улучшают удобство разработки и расширяют возможности сети по поддержке разнообразных приложений.

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

Дополнительные ресурсы

• Репозиторий клиента Agave
• График выпуска Agave v2.2
• Журнал изменений Agave v2.2
• Помеченные запросы на слияние Agave v2.2