Новости

Stellar представила Bell: три изменения Protocol 30

Обновление Bell для Stellar предлагает мультиплексированные адреса смарт-контрактов, проверку постквантовых подписей в Soroban и миллисекундное время реестра.

Stellar представила Bell: три изменения Protocol 30

Stellar Development Foundation описала Bell, Protocol 30 – планируемое обновление сети из трёх изменений для смарт-контрактов и времени реестра. Оно предлагает мультиплексированные адреса контрактов, проверку постквантовых подписей ML-DSA внутри Soroban и поддержку миллисекундного формата времени. На момент публикации обновление ещё не активировано: голосование за тестовую сеть назначено на 3 ноября, за основную сеть – на 23 ноября 2026 года.

Один контракт для разных клиентов

Первое предложение, CAP-84, добавляет мультиплексированный вариант адреса смарт-контракта. Классический muxed account использует один Stellar-аккаунт с числовым идентификатором, который позволяет бизнесу различать поступления разных клиентов, не создавая отдельную запись для каждого. Новый тип должен перенести похожий подход на smart accounts, где адрес принадлежит контракту с программируемыми правилами авторизации.

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

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

Проверка ML-DSA в смарт-контрактах

Второе изменение, CAP-87, добавляет функции проверки подписей ML-DSA для контрактов Soroban. ML-DSA – стандартизованный NIST алгоритм цифровой подписи, разработанный с учётом угрозы будущих квантовых вычислений. Смарт-аккаунт сможет использовать такую подпись как часть собственного правила авторизации, например при создании кошелька с несколькими условиями или политикой доступа.

Проверка ML-DSA требует больше вычислений, чем распространённые эллиптические подписи, поэтому Bell предлагает выполнять её на стороне Stellar Core через специальные функции среды, а не повторно реализовывать сложный алгоритм в коде каждого контракта. Это может упростить проверяемую интеграцию и использовать официальные тестовые векторы. Но наличие функции в протоколе не переключит автоматически все кошельки и ключи пользователей на постквантовую криптографию.

Сама команда отдельно уточняет границы изменения: транзакционные подписи сети остаются Ed25519 в этом обновлении. CAP-87 позволяет контрактам проверять ML-DSA для собственных правил, а нативный постквантовый подписант для классических аккаунтов относится к будущей работе. Поэтому некорректно говорить, что вся сеть Stellar уже стала постквантовой. Новость описывает строительный блок для отдельных сценариев смарт-аккаунтов.

Миллисекундное время ledger

Третья часть, CAP-88, меняет представление времени в заголовке реестра, чтобы поддержать миллисекундную точность. Сейчас поле времени Stellar отражает целые секунды, а протокол не может задавать интервал меньше одной секунды между закрытиями ledger. Предложение готовит более точную шкалу, которую будущие изменения смогут использовать для ускорения времени закрытия.

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

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

Даты, статус и подготовка

В объявлении Stellar указано, что релиз Core v30.0.0 доступен с 16 октября, а дополнительные версии SDK и инфраструктуры должны выходить в период с 16 по 23 октября. Голосование за тестовую сеть назначено на 3 ноября 2026 года, за основную – на 23 ноября, оба в 17:00 UTC. Эти даты относятся к предложенной процедуре; фактическая активация зависит от голосования валидаторов и может измениться.

Операторам Stellar Core, кошельков, бирж, шлюзов и индексаторов стоит читать инструкцию миграции для своей роли. Разработчикам нужно поддержать новые адресные варианты, обновить XDR и проверить SDK. Командам Soroban, которые хотят использовать ML-DSA, потребуется явно интегрировать новые функции после доступности нужных версий и учесть ограничения контракта.

Держателям XLM не следует воспринимать анонс как инвестиционное обещание или необходимость немедленно подписывать неизвестную транзакцию. Участие в обновлении относится в первую очередь к операторам и разработчикам, а обычные пользователи должны пользоваться официальными кошельками и подтверждать сеть. Основы проверки сетевого контекста объяснены в нашем материале о Chain ID и защите подписей, а различия между логами и состоянием контракта – в статье о событиях смарт-контрактов.

Bell объединяет улучшения для клиентских идентификаторов, криптографической авторизации и хранения времени. Каждое из них адресует отдельную инженерную задачу, а не меняет все пользовательские процессы одним шагом. Основные вопросы на ближайшие недели – примут ли валидаторы обновление, выпустят ли совместимые SDK и успеют ли сервисы обновить парсеры. До голосования корректнее говорить о предложенных возможностях, а не о функциях, которые уже действуют в основной сети.