Предложение Solana об офлайн-подписи сохранит действительность одобрений после неудачных транзакций

План Solana по отказу от долговечных нонсов (durable nonces), которые позволяют подписывать транзакции офлайн и отправлять их позже, сохранит возможность подтверждения с использованием холодных ключей, но изменит адреса, контролирующие соответствующие активы. Для бирж, кастодианов и операторов казначейства, использующих этот метод подписи, предлагаемая замена добавляет программу между подтверждением холодного ключа и исполнением.

План Solana Foundation по отказу от долговечных нонсов в октябре предусматривает использование ончейн-программ-подписантов, которые проверяют офлайн-подпись и выполняют одобренные ею инструкции. Адрес, производный от программы (PDA), будет контролировать затронутые счета. Исходный ключ по-прежнему будет авторизовать действия, в то время как отдельный онлайн-оператор будет отправлять их и оплачивать сетевую комиссию.

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

Долговечные нонсы останутся доступными. Фонд не установил дату удаления и не принял окончательного решения между Programmatic Signer от Anza и Vector от Blueshift. Ориентировочное шестимесячное окно миграции зависит от готовности, аудита и запуска подходящей замены в основной сети.

Ключ продолжает подтверждать, но счет меняется

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

Отдельное обновление Solana до 200 мс на слот достигло финальной стадии в основной сети 9 октября. Ускоренное создание блоков оставляет меньше реального времени для обычных одобрений на основе хэша блока, хотя срок действия зависит от создания блока, а не от гарантированного таймера. В предыдущем материале CryptoSlate рассматривалось это изменение синхронизации; предложение по нонсам касается архитектуры, используемой для избежания короткого окна одобрения.

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

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

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

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

Два предлагаемых дизайна также по-разному обрабатывают нативный SOL. Производный счет SOL в Programmatic Signer принадлежит системе и может отправлять SOL через одобренный обычный перевод. Vector инициализирует счет, принадлежащий программе, и выводит SOL через собственную авторизованную операцию вывода или закрытия.

Что холодная подпись позволяет релееру

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

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

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

Programmatic Signer позволяет собрать контекст исполнения вокруг одобренного действия; Vector требует, чтобы окружающая последовательность инструкций была одобрена заранее. В обоих случаях оплата за трансляцию не дает права переписывать подписанное действие.

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

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

Vector явно предупреждает, что релеер может удержать транзакцию до изменения условий, или что подпись, раскрытая неудачной попыткой, может быть исполнена позже. Тайм-аут, включенный в подписанные инструкции, может отклонить исполнение после установленного срока. Отзыв требует продвижения нонса с отдельной авторизацией для его применения. Само отклонение по истечении срока действия не потребляет нонс, изменения которого откатываются вместе с неудачной транзакцией.

Доступ к приложениям — отдельный тест на кастодиальность

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

Затем приложения получают одобренные действия через межпрограммные вызовы (CPI): одна программа вызывает другую. Это может противоречить правилу приложения, согласно которому действие должно поступать непосредственно как инструкция верхнего уровня. Проверки, которые анализируют только инструкции верхнего уровня по погашению или проверке подписи, также могут пропустить действие, вложенное в программу-подписанта.

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

CPI Guard в Token-2022 показывает, почему совместимость требует точной оценки на уровне счета. При включенном защитнике CPI-переводы и сжигания требуют делегированного авторитета; одобрения через CPI запрещены, а изменение владельца запрещено даже вне CPI. Постоянные делегаты имеют исключения для переводов и сжигания.

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

Институциональные опасения, высказанные в марте, были сосредоточены на доступе к приложениям и контроле, под которым могут перемещаться средства. В обсуждении от 4 марта участник, представившийся как Майкл из Fireblocks, поддержал отказ от нонсов, но возразил против миграции CPI Passthrough, зависимости от контрактов и нагрузки на совместимость с DeFi. Он высказался в пользу транзакционных оболочек, с Sudo в качестве альтернативы, а не предлагаемого пути подписи на основе CPI.

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

Тестируемый дизайн все еще нуждается в пути миграции в продакшн

Текущая документация Programmatic Signer сообщает о развертывании в devnet и текущих аудитах, с необходимостью доработки перед выпуском v1 и любым развертыванием в основной сети. Его интерфейсы могут измениться. Документация по использованию по-прежнему отмечает симуляцию и отправку релеем как предстоящие, в то время как несколько операций миграции аналогично незавершены в руководстве.

Vector публикует код реализации и идентификаторы программ; в его README не указан статус аудита или развертывания в основной сети.

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

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

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