Всё, что нужно знать об обновлении Solana v1.17

О чём эта статья?

Сеть Solana успешно достигла важного рубежа: подавляющее большинство валидаторов перешло на 1.17, последнюю версию клиентского ПО валидатора Solana Labs. После недавнего сбоя сети валидаторы перезапустились на версии 1.17.20. На момент написания статьи ~68,6% валидаторов используют версию 1.17.21, а ~31,3% — версию 1.17.20.  Новая версия включает ряд улучшений для повышения эффективности, масштабируемости и расширения сценариев использования сети. От передовых разработок в области доказательств с нулевым разглашением до оптимизации протокола Gossip — v1.17 стала важным этапом в развитии Solana.

В этой статье собрано всё, что нужно знать об обновлении клиентского ПО валидатора Solana Labs до версии 1.17. Мы рассмотрим тщательное тестирование v1.17, недавний сбой сети и новые функции этого обновления.

Как тестировали v1.17?

v1.17 работает в testnet с 3 октября 2023 года. Версию регулярно подвергали стресс-тестам с высокой транзакционной нагрузкой. Solana Labs также развернула несколько контрольных нод mainnet-beta на v1.17, чтобы проверить стабильность версии в реальных условиях. Последние несколько месяцев они работали стабильно. Историю активности и состояние этих контрольных нод можно посмотреть в канале #canaries-monitoring в Solana Tech Discord. Кроме того, с 4 декабря 2023 года небольшая группа добровольных нод mainnet-beta перешла на v1.17. 

Было разработано несколько фаззеров среды выполнения, которые выполняли частично рандомизированные транзакции для выявления пограничных случаев и редких состояний гонки. Эти транзакции выполнялись в нескольких версиях, чтобы обеспечить стабильность результатов. v1.17 несколько раз прошла аудит у внешних специалистов. Отчёты будут публиковаться в репозитории аудитов безопасности Solana на GitHub по мере готовности.

Февральский сбой

6 февраля 2024 года в 9:53 UTC в mainnet-beta произошёл сбой, временно остановивший финализацию блоков. Работа сети была нарушена примерно на пять часов, пока в 14:55 UTC не возобновился консенсус. Причиной стала ошибка в механизме компиляции и кэширования кода программ для выполнения, которая затрагивала старые версии загрузчиков программ.

Первопричина заключалась в том, как валидаторы обрабатывали результат компиляции Just-in-time (JIT) часто используемых программ. Новая система кэширования, призванная оптимизировать этот процесс, непреднамеренно внесла критическую ошибку. Для некоторых устаревших программ система могла войти в бесконечный цикл повторной компиляции. Это остановило механизм консенсуса Solana, поскольку большинство валидаторов столкнулось с проблемой и не могло продолжить обработку транзакций.

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

Официальный отчёт, первоначально опубликованный Anza, доступен здесь.

ZK Token Proof Program

Выпуск ZK Token Proof Program планировался вместе с обновлением 1.16. Однако активацию отложили из-за масштабного аудита. В расписании активации Feature Gate программа отмечена как ожидающая активации в testnet с минимальной версией 1.17.12. 

Конфиденциальные переводы

После активации ZK Token Proof Program наконец станут доступны конфиденциальные переводы. Конфиденциальные переводы используют доказательства с нулевым разглашением для шифрования балансов токенов и сумм переводов SPL-токенов. Основная цель здесь — конфиденциальность, а не анонимность. Гомоморфное шифрование позволяет выполнять вычисления над зашифрованными данными без их расшифровки. Например, балансы можно складывать и вычитать, не расшифровывая и не шифруя повторно указанные суммы. Таким образом, вычисления над зашифрованными данными выполняются так же, как над открытым текстом.

Конфиденциальные переводы используют шифрование Twisted ElGamal и Sigma Protocols для безопасных приватных транзакций без раскрытия конфиденциальной информации. 

Небольшое пояснение:

• Шифрование Twisted ElGamal — простой вариант стандартной схемы шифрования ElGamal, в котором шифротекст разделён на обязательство Педерсена для зашифрованного сообщения и дескриптор расшифровки, позволяющий выполнять скрытые математические операции над шифротекстом
• Sigma Protocols используются для проверки конфиденциальных переводов. Это особый класс доказательств с нулевым разглашением, в котором одна сторона (доказывающая) может подтвердить другой стороне (проверяющей), что знает определённую информацию, не раскрывая её

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

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

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

Поддержка командной строки

Также доступна поддержка конфиденциальных переводов в интерфейсе командной строки (CLI) через крейт spl-token. После активации команда create-token будет расширена флагом –enable-confidential-transfers auto. Он позволит выпускать токены с включённым расширением конфиденциальных переводов. Доступен и ряд других полезных команд:

• configure-confidential-transfer-account — настраивает существующий аккаунт для конфиденциальных переводов. Настроить их может только владелец аккаунта
• deposit-confidential-tokens — переводит токены с неконфиденциального аккаунта на конфиденциальный. После внесения токены полностью переходят в конфиденциальный баланс и больше не отображаются в неконфиденциальном балансе аккаунта
• apply-pending-balance — переводит баланс из «Ожидающего» в «Доступный». Это необходимо, поскольку полученные в результате перевода или пополнения конфиденциальные токены сначала отображаются в «Ожидающем» балансе аккаунта. Пользователи не получают немедленного доступа к средствам и должны применить ожидающий баланс
• transfer (с включённым флагом –confidential) — переводит токены на другой аккаунт, настроенный для конфиденциальных переводов. Эта операция может занимать больше времени, чем обычный перевод токенов, поскольку требует нескольких зависимых транзакций
• withdraw-confidential-tokens — выводит токены с конфиденциального баланса аккаунта на его неконфиденциальный баланс. Чтобы вывести все ожидаемые токены, перед выполнением команды примените любой ожидающий баланс
• update-confidential-transfer-settings — обновляет конфигурацию конфиденциальных переводов для указанного минта токена. Команда позволяет автоматически задавать политики одобрения конфиденциальных переводов (флаг –aprove-policy) и открытый ключ аудитора (флаг –auditor-pubkey). Также предусмотрены дополнительные флаги для указания хеша блока, полномочий конфиденциальных переводов, файлов конфигурации, данных плательщика комиссии, URL JSON RPC, данных nonce-аккаунта, формата вывода и ID программы токена

Совместимость 

Следующие сочетания расширений либо не работают, либо не имеют смысла вместе с конфиденциальными переводами:

• Конфиденциальный перевод + непередаваемый токен
• Конфиденциальный перевод + комиссии (не будет работать до версии 1.18)
• Конфиденциальный перевод + Transfer Hooks (такие переводы видят только исходный аккаунт или аккаунт назначения, поэтому не могут выполнять действия с переводимой суммой)

Аудиты

Конфиденциальные переводы и программа Token-2022 в целом прошли масштабные аудиты таких компаний, как Halborn, Zellic, Trail of Bits, NCC Group и OtterSec (дважды: первый аудит был посвящён Token-2022, а второй аудит — непосредственно конфиденциальным переводам).

Системные вызовы Poseidon

Poseidon — семейство хеш-функций, оптимизированных для доказательств с нулевым разглашением. Хеш-функции Poseidon применяются в большинстве блокчейн-проектов на основе ZK, включая Zcash, Mina и Light Protocol от Solana. Сейчас вычисление хешей Poseidon в Solana слишком затратно для одной транзакции. Системные вызовы Poseidon должны это изменить. Их выпуск сейчас запланирован в v1.17.5 с ожиданием активации в testnet.

Объяснение простыми словами

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

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

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

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

Характеристики, удобные для ZK

Хеш-функции Poseidon считаются удобными для доказательств с нулевым разглашением по нескольким причинам. В частности:

• Poseidon разработан для эффективного выполнения арифметических операций, часто используемых в вычислениях доказательств с нулевым разглашением: сложения, умножения и возведения в степень
• Системы доказательств с нулевым разглашением требуют преобразования вычислительной логики в криптографическое доказательство. Благодаря ориентации на арифметические операции, оптимизированному S-box, настраиваемым параметрам и небольшому числу раундов архитектура Poseidon обеспечивает меньшую сложность схемы по сравнению с другими хеш-функциями. Раунд — это последовательность операций над входными данными или внутренним состоянием хеш-функции, выполняемая итеративно. Поэтому для создания доказательства для заданных данных требуется меньше шагов
• Хеш-функции Poseidon основаны на губчатой конструкции. Иными словами, Poseidon использует класс алгоритмов, которые принимают последовательность битов любой длины и формируют результат любой длины. Поэтому хеш-функции Poseidon очень легко интегрировать в различные приложения с нулевым разглашением.

Сравнение с традиционными хеш-функциями

Вычислительная эффективность Poseidon, адаптированная к доказательствам с нулевым разглашением, даёт явное преимущество перед более универсальными и ресурсоёмкими операциями традиционных хеш-функций, таких как SHA-256. 

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

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

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

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

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

Детали реализации

v1.17 добавляет системный вызов sol_poseidon — системный вызов, который принимает двумерный срез байтов и вычисляет соответствующий хеш Poseidon. Он использует кривую BN254 и следующие параметры Poseidon:

• x^5 S-box (то есть блоки подстановки)
• Входные данные, где 1 ≤ n ≤ 12
• Ширина, где 2 ≤ t ≤ 13
• 8 полных раундов и частичные раунды в зависимости от t: [56, 57, 56, 60, 60, 63, 64, 63, 60, 66, 60, 65]

Эти хеши Poseidon будут вычисляться с помощью крейта light-posiedon, который прошёл аудит и совместим с Circom. 

Обратите внимание: в следующем разделе мы рассматриваем добавление системных вызовов alt_bn128. BN254 часто называют BN128 (по числу битов безопасности), а также alt_bn128 или alt_bn_128. Во всех случаях речь идёт об одной кривой.

Системные вызовы alt_bn128

В v1.16 предлагалось расширить поддержку вычислений с нулевым разглашением в среде выполнения, в частности операций со 128-битными эллиптическими кривыми. Системные вызовы alt_bn128, необходимые для эффективного создания доказательств, должны были выйти в v1.16. Однако выпуск отложили. Согласно расписанию активации Feature Gate, системные вызовы alt_bn128 сейчас запланированы для v1.17.15 и ожидают активации в mainnet-beta, а сжатие alt_bn128 запланировано для v1.17.15 и ожидает активации в testnet.

Для тех, кому интересны подробности: alt_bn128 означает реализацию эллиптической кривой Баррето — Нэрига (BN-128). Это специальная эллиптическая кривая, удобная для спаривания и позволяющая эффективно применять zk-SNARK (краткий неинтерактивный аргумент знания с нулевым разглашением). Она считается «удобной для спаривания», поскольку позволяет эффективнее выполнять некоторые вычисления и доказательства с нулевым разглашением. В Solana системные вызовы alt_bn128 позволяют программам использовать эту кривую для упрощённой проверки доказательств с нулевым разглашением, повышая безопасность и приватность. Добавление системных вызовов g1 и g2 для alt_bn128 упрощает сжатие доказательств Groth16. Это значительно сокращает пространство, необходимое для каждого доказательства, и оптимизирует использование места программами Solana.

Добавление системных вызовов alt_bn128 помогает сократить разрыв в совместимости между Solana и контрактами на Solidity, которые используют предварительно скомпилированные контракты для операций с эллиптическими кривыми, описанных в EIP-196, EIP-197 и EIP-198. Эти операции (bn256Add, bn256ScalarMult, bn256Pairing) позволяют проверять zk-SNARK в пределах лимитов газа Ethereum. Контрактам Solidity, использующим эти операции с эллиптическими кривыми, теперь будет проще перейти на Solana или взаимодействовать с ней.

Улучшения Gossip

v1.17 повышает эффективность распространения сообщений Gossip за счёт улучшения передачи push-сообщений и снижения зависимости от pull-запросов. Оптимизация работы протокола Gossip сокращает потребление ресурсов валидаторами консенсуса.

Для контекста: служба Gossip Solana необходима для обмена информацией между валидаторами. Это данные о высоте реестра, контактные данные, голоса консенсуса и другая информация. Для обмена и проверки информации в сети используются push- и pull-сообщения. Такая система обмена сообщениями обеспечивает синхронизацию всех нод. 

Ранее AccountsHashVerifier отправлял хеши аккаунтов в Gossip. Однако ни один компонент сети не запрашивал эти данные, поэтому процесс был избыточным. После появления EpochAccountsHash отказались от прежних операций, включая сравнение хешей аккаунтов из Gossip со значениями известных валидаторов.  Метод RPC getHealth также переписали, чтобы он больше не зависел от хешей аккаунтов из Gossip. Подробнее об этом — в следующем разделе. Таким образом, начиная с v1.17 хеши аккаунтов из Gossip больше никто не запрашивает. AccountsHashVerifier изменили, чтобы он перестал отправлять аккаунты в Gossip, а функции отправки и получения хешей аккаунтов через Gossip удалили.

getHealth 

Ранее вызов RPC getHealth мог показывать неверное состояние ноды. Причиной было расхождение между командой CLI solana catchup и вызовом RPC getHealth: одна и та же нода могла одновременно отображаться как синхронизированная и отстающая. В результате исправные ноды могли ошибочно помечаться как неисправные и потенциально удаляться из пулов RPC.

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

Для команд wait-for-restart-window и exit также добавили флаг –skip-health-check, устраняющий проблемы с getHealth. Он позволяет валидаторам пропускать проверку состояния ноды.

QUIC

v1.17 добавляет возможность транслировать шарды и выполнять восстановление через QUIC. Конечные точки QUIC для Turbine и восстановления пока отключены, поскольку не нужны до полного перехода testnet на QUIC. Тем не менее это создаёт основу для перевода данных протоколов на QUIC. Для реализации базовой функциональности объединили несколько PR, в том числе:

• Добавление отложенного вытеснения для восстанавливающих соединений QUIC, чтобы число открытых соединений не росло неограниченно
• Добавление метрик для мониторинга конечной точки QUIC Turbine
• Добавление метрик для мониторинга восстановления конечной точки QUIC
• Предотвращение тайм-аутов соединений QUIC из-за редких запросов на восстановление

Асинхронные соединения TPU

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

Упрощённый запуск валидатора и обновление формата снимков

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

v1.17 добавляет новый флаг –use-snapshot-archives-at-startup. Он позволяет валидаторам ускорить запуск, выбрав локальные снимки, локальное состояние на диске или автоматически определив более свежий из этих двух вариантов. Флаг устраняет необходимость обрабатывать снимки, если состояние на диске новее, и тем самым ускоряет перезапуск.

Ранее Solana поддерживала различные форматы сжатия снимков: bz2, gzip, zstd, lz4, tar и отсутствие сжатия. В последнем обновлении выбор ограничили zstd и lz4, чтобы повысить эффективность и упростить поддержку. Остальные форматы объявлены устаревшими для аргумента –snapshot-archive-format, хотя валидаторы по-прежнему могут читать существующие снимки в этих форматах для обратной совместимости. Это также упрощает интерфейс командной строки для solana-validator и solana-ledger-tool. 

Заключение

Благодаря многочисленным новым функциям и быстрому устранению недавнего сбоя сети обновление Solana v1.17 стало значительным шагом вперёд. Оно предоставляет беспрецедентную поддержку и возможности для нулевого разглашения за счёт выпуска ZK Token Program, системных вызовов Poseidon и системных вызовов alt_bn128. Вместе с улучшениями валидаторов и эффективности сети это обновление закладывает прочную основу для следующей версии. Оно меньше v1.16 и соответствует целевому циклу выпуска новой версии раз в три месяца. Расписание выпуска 1.18 доступно здесь.

Если вы дочитали до этого места, спасибо, анон! Укажите свой адрес электронной почты ниже, чтобы не пропускать новости Solana. Хотите узнать больше? Читайте свежие статьи в блоге Helius и продолжайте знакомство с Solana уже сегодня.

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

• Отчёт о сбое Solana Mainnet Beta от 06.02.2024
• Расписание выпуска v1.17
• Poseidon: хеширование, удобное для ZK
• Аккаунт Solana Status в Twitter
• Валидаторы Solana переходят на обновление v1.17