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

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

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

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

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

В последние несколько месяцев v1.16 проходила строгие испытания. Релиз v1.16 работает в testnet с 7 июня 2023 года и прошёл множество стресс-тестов. Кроме того, начиная с 23 августа 2023 года небольшая группа волонтёрских нод обновилась до v1.16. Волонтёры смогли выявить и устранить различные проблемы, включая медленный запуск RPC-нод и ошибки общей защиты. Solana Labs также развернула несколько канареечных нод в mainnet-beta. Это позволило отслеживать стабильность нод v1.16 в реальных условиях. Чтобы ознакомиться с историей активности и результатами этих канареечных нод, посетите канал #canaries-monitoring в Solana Tech Discord.

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

Шлюзы функций

Важно отметить, что некоторые функции, о которых пойдёт речь в следующих разделах, пока недоступны в рабочей сети. Они внедряются постепенно с помощью системы шлюзов функций. Функции активируются в определённые эпохи с учётом их относительного приоритета и порядка активации в других сетях. До сих пор график активации шлюзов составлялся ситуативно на основе ряда критериев, с которыми можно ознакомиться здесь. Как правило, шлюзы сначала активируют в testnet, затем в devnet и только после этого в mainnet-beta. Чтобы активировать функцию, инженер с необходимой парой ключей отправляет транзакцию. После её обработки функция становится активной в следующей эпохе. Для обеспечения надлежащей производительности в каждой сети одновременно активируют только один шлюз. Некоторым функциям может потребоваться период наблюдения, что способно задержать активацию шлюзов с более низким приоритетом.

Система шлюзов функций нужна, чтобы изменения, нарушающие консенсус, не приводили к ответвлению валидатора с более новой версией от канонической цепочки и продолжению создания им блоков. Например, валидатор v1.14 не знает о новых функциях v1.16 и при возникновении разногласий может вызвать сбой сети. Коммит, добавленный на этой неделе в кодовую базу Solana, рекомендует оформлять документ Solana Improvement Document (SIMD) для всех изменений, нарушающих консенсус. Теперь шаблон задачи для шлюза функций будет содержать запрос на SIMD этой задачи. Это помогает стандартизировать процесс разработки и благодаря документации делает новые изменения более прозрачными.

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

Confidential Transfers — функция, представленная в Token2022. Она использует доказательства с нулевым разглашением для шифрования балансов и сумм транзакций SPL-токенов. Главная задача этой функции — повысить конфиденциальность пользователей, уделяя особое внимание сокрытию данных, а не анонимности.

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

Полезным дополнением к запуску Confidential Transfers стала поддержка интерфейса командной строки (CLI). Команда create-token теперь включает флаг --enable-confidential-transfers, который позволяет пользователям выпускать токены с поддержкой конфиденциальных переводов. Также добавлена команда update-confidential-transfer-settings для динамического изменения конфигурации конфиденциальных переводов конкретного выпуска токена. Она позволяет обновлять ключ аудитора и настройки одобрения.

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

Релиз v1.16 расширяет возможности Solana в области нулевого разглашения благодаря улучшенной поддержке вычислений с нулевым разглашением в среде выполнения, в частности операций со 128-битными эллиптическими кривыми. В v1.16 появились системные вызовы alt_bn128, необходимые для эффективного создания доказательств.

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

Syscall, или системный вызов, используется для запроса сервисов у ядра операционной системы. В контексте Solana системный вызов позволяет программам, выполняемым в Solana Virtual Machine (SVM), взаимодействовать с внешними ресурсами.

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

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

• bn256Add — выполняет сложение при операциях с эллиптическими кривыми
• bn256ScalarMult — выполняет скалярное умножение при операциях с эллиптическими кривыми
• bn256Pairing — выполняет операции спаривания эллиптических кривых для проверки zkSNARKs в пределах лимита газа блока

Эти операции стандартизированы в Ethereum с помощью EIP-196, EIP-197 и EIP-198. Появление системных вызовов alt_bn128 — важный шаг к устранению разрыва в совместимости. Контрактам Solidity, использующим эти операции с эллиптическими кривыми, теперь будет проще перейти на Solana или даже взаимодействовать с ней.

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

• Добавлены системные вызовы alt_bn
• Добавлены тесты системного вызова alt_bn128 и исправлены связанные проблемы
• Функция (системный вызов): добавлено сжатие altbn128 g1 и g2

Валидаторы

Обновление v1.16 значительно сокращает потребление оперативной памяти валидаторами. Ранее Solana использовала оперативную память для индексирования аккаунтов. Теперь система по умолчанию индексирует аккаунты на диске, что существенно снижает потребление оперативной памяти. Yanshu из Luganodes отмечает, что после выхода v1.16 их валидатор стабильно работает всего с ~39 ГБ оперативной памяти вместо ~120 ГБ в предыдущих версиях:

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

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

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

Запустить собственный валидатор стало проще, чем когда-либо. Тем, кто хочет управлять собственным валидатором, Solana предлагает Solana Validator Education — серию семинаров для валидаторов на YouTube-канале Solana.

Поддержка аккаунтов с изменяемым размером

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

Хеш аккаунтов эпохи

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

v1.16 решает эту проблему с помощью хеша аккаунтов эпохи. Это хеш всех аккаунтов, который создаётся в конце каждой эпохи, даже если с этими аккаунтами не взаимодействовали. Хеш аккаунтов эпохи позволяет сети выявлять и отделять ноды с повреждёнными данными, повышая целостность и безопасность Solana.

Настройка системы

Настройка системы — это процесс оптимизации операционной системы и конфигурации оборудования валидатора для достижения максимальной производительности. В релизе v1.16 параметр solana-sys-tuner удалён, и теперь рекомендуется ручное тестирование. Его удалили, поскольку в предыдущих версиях столбцы TransactionStatus и AddressSignature базы данных RocksDB очищались некорректно. Кроме того, периодическое уплотнение — процесс освобождения места в хранилище — по умолчанию было отключено. В результате эти столбцы неограниченно разрастались на нодах, запущенных с флагом --enable-rpc-transaction-history. Благодаря следующему коммиту пространство хранилища валидаторов, использующих этот флаг, теперь управляется эффективнее. Это существенное улучшение оптимизирует требования к хранилищу валидаторов, устраняя необходимость хранить ненужные статусы транзакций и подписи адресов.

Заключение

Релиз Solana v1.16 стал важной вехой и результатом десяти месяцев разработки. Его выход занял так много времени из-за приоритета QUIC, поэтому улучшения конфиденциальных переводов, поддержки нулевого разглашения и оптимизации валидаторов давно назрели. Тем не менее эти изменения можно назвать революционными. Релиз выводит эффективность и конфиденциальность Solana на новый уровень.

В дальнейшем Solana Labs переходит на более гибкий цикл разработки и планирует выпускать новые релизы примерно раз в три месяца. Будущие релизы будут значительно меньше v1.16. Это позволит быстрее вносить изменения и снизит риски при развёртывании. График выпуска v1.17 доступен здесь. Этот релиз также вызывает большой интерес благодаря ещё более развитой поддержке нулевого разглашения и возможному появлению системных вызовов Posidon.

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

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

• График активации шлюзов функций
• Процесс активации шлюзов функций
• Аудиты безопасности Solana
• Solana Beach — страница валидаторов

‍