Keychain предоставляет единый базовый интерфейс SolanaSigner для всех бэкендов, поэтому
для большинства из них выбор носит операционный, а не архитектурный характер: позже его можно изменить
через конфигурацию. Исключение — форма транзакции. Crossmint
и Fordefi в нативном автоматическом режиме подписывают и отправляют транзакции на стороне сервера, а Fordefi в нативном
ручном режиме перезаписывает транзакцию перед подписью, поэтому переход на любой
из них или с них меняет способ вызова подписанта. Именно поэтому отталкивайтесь от
своих требований, а не от продукта. Большую часть решения определяют два вопроса: где
хранится приватный ключ и кто вправе разрешать подпись с его помощью?
Все бэкенды, кроме Ledger, доступны на всех четырёх языках (Rust, TypeScript,
Python и Go). Ledger поддерживается только в Rust и включается опционально через функцию ledger.
Единственного лучшего бэкенда не существует. Каждый из них лучше подходит для определённого набора ограничений: облако, которое вы уже используете, желание самостоятельно эксплуатировать ключевую инфраструктуру, а также требования к хранению ключей и контролю подтверждений. Схема ниже сопоставляет эти ограничения с бэкендом.
Это руководство посвящено подписи на стороне бэкенда (сервера). Если ваши конечные пользователи подписывают собственные транзакции в браузере, используйте кошелёк через Wallet Standard. См. Подпись в продакшене.
Схема принятия решений
Для локальной разработки и тестов всё это не требуется: используйте бэкенд Memory для прототипирования, а затем перейдите на один из продакшен-бэкендов выше через конфигурацию.
Разбор вопросов
Вы подписываете транзакции для собственного приложения или для конечных пользователей?
Если вы создаёте кошельки, которыми владеют и управляют конечные пользователи (потребительские приложения, сценарии онбординга), используйте бэкенд встроенного / управляемого кошелька: Privy, Turnkey, CDP, Crossmint или Openfort. Они берут на себя управление кошельками отдельных пользователей и аутентификацию от вашего имени.
Если вы подписываете транзакции как собственное приложение (плательщик комиссий, казначейство, бэкенд- автоматизация), читайте дальше.
Нужны ли вам многосторонние подтверждения, институциональное хранение или регуляторный контроль?
Если подписи должны пройти политику подтверждений, лимит расходов или процесс комплаенса, прежде чем будут созданы, либо вам нужен регулируемый кастодиан, хранящий ключи, используйте бэкенд MPC / институционального хранения: Fireblocks, Dfns, Para, Utila или Fordefi. Они разделяют ключ или хранят его и ставят совместную подпись в соответствии с вашей политикой.
Если вам нужен лишь ключ, который подписывает по запросу, читайте дальше.
Вы хотите хранить ключ самостоятельно или доверить это провайдеру?
Если ключ должен храниться у облачного провайдера в аппаратно защищённой инфраструктуре, а ваша политика IAM определяет, кто может подписывать, используйте KMS этого облака:
- Работаете в AWS → AWS KMS
- Работаете в GCP → GCP KMS
Если вы хотите самостоятельно эксплуатировать ключевую инфраструктуру либо используете несколько облаков или on-prem, выберите HashiCorp Vault. Вы запускаете его и проводите аудит; ключ остаётся внутри Transit engine и подписывает по запросу.
Модели хранения
Бэкенды делятся на шесть моделей хранения ключей. Схема выше приводит вас к одной из них.
- Самостоятельное хранение (в процессе): ваше приложение хранит сам приватный ключ. Удобно для разработки, но непригодно для продакшена. Бэкенд: Memory.
- Самостоятельное хранение (аппаратный кошелёк): ключ никогда не покидает устройство Ledger, а человек подтверждает каждую подпись на его экране. Подходит для интерактивной подписи оператором, но не для работающих без присмотра сервисов. Только Rust, включается опционально и не охвачен аудитом. Бэкенд: Ledger.
- Самостоятельно размещаемое управление ключами: вы эксплуатируете ключевую инфраструктуру; ключ остаётся внутри неё и подписывает по запросу. Бэкенд: HashiCorp Vault.
- Облачный KMS / HSM: облачный провайдер хранит ключ в аппаратно защищённой инфраструктуре; ключ никогда не покидает сервис, а ваша политика IAM определяет, кто может подписывать. Бэкенды: AWS KMS, GCP KMS.
- MPC и институциональное хранение: ключ разделяется или хранится у провайдера, который ставит совместную подпись согласно вашей политике (подтверждения, лимиты). Бэкенды: Fireblocks, Dfns, Para, Utila, Fordefi.
- Встроенные и управляемые кошельки: провайдер управляет кошельками от вашего имени, часто для онбординга конечных пользователей. Бэкенды: Privy, Turnkey, CDP, Crossmint, Openfort.
Сравнение бэкендов
| Бэкенд | Модель хранения | Лучше всего подходит для | Примечания |
|---|---|---|---|
| Memory | Самостоятельное хранение (в процессе) | Локальная разработка, тесты, CI | Необработанный ключ в процессе; не используйте в продакшене |
| Ledger | Самостоятельное хранение (аппаратный кошелёк) | Интерактивная подпись оператором из инструментов на Rust | Только Rust, опциональная функция ledger, не проходил аудит; каждая подпись подтверждается на устройстве |
| HashiCorp Vault | Самостоятельное управление ключами | Команды, использующие собственную инфраструктуру ключей | Transit engine; вы сами управляете и проводите аудит |
| AWS KMS | Облачный KMS / HSM | Бэкенды, работающие на AWS | Ключ никогда не покидает KMS; IAM управляет подписью |
| GCP KMS | Облачный KMS / HSM | Бэкенды, работающие на GCP | Ключ никогда не покидает KMS; IAM управляет подписью |
| Fireblocks | MPC / институциональное хранение | Казначейства, биржи, регулируемое хранение | Движок политик и процессы согласования |
| Dfns | MPC-инфраструктура кошельков | Программные кошельки с контролем политик | Подпись Ed25519 |
| Para | MPC-кошельки | Приложения с кошельками на базе MPC | API-ключ + ID кошелька |
| Utila | MPC-хранение + со-подписант | Существующие кошельки Solana под управлением Utila | signMessage не поддерживается; транзакцию транслируете вы |
| Fordefi | MPC / институциональное хранение | Институциональное хранение ключей с управлением политиками | Чёрный ящик: отправляете вы. Нативный авторежим: Fordefi перезаписывает и отправляет. Нативный ручной режим: Fordefi перезаписывает, результат отправляете вы |
| Privy | Встроенные кошельки | Потребительские приложения для подключения пользователей к кошелькам | Встроенные кошельки под управлением приложения |
| Turnkey | Некастодиальное управление ключами | Программная подпись с контролем политик | Некастодиальное управление ключами |
| CDP | Управляемый кошелёк (Coinbase) | Приложения на платформе Coinbase Developer Platform | signMessage принимает только UTF-8 |
| Crossmint | Управляемые кошельки | Маркетплейсы и приложения с управляемыми кошельками | Только отправка: транслирует на стороне сервера, может перезаписывать транзакцию для спонсирования газа; signMessage не поддерживается |
| Openfort | Встроенные бэкенд-кошельки | Серверные кошельки | Ключи хранятся в TEE |
Форма возможностей
Помимо модели хранения, у каждого бэкенда есть своя форма транзакции, и она определяет, как вы вызываете подписанта:
- Подпись: провайдер подписывает собранные вами байты, а вы отправляете их в сеть. Большинство бэкендов, включая Ledger и режим «чёрного ящика» Fordefi.
- Перезапись и подпись: провайдер перезаписывает транзакцию, а затем подписывает её без отправки. Продолжайте работу с возвращённой транзакцией. Нативный ручной режим Fordefi.
- Подпись и отправка: провайдер подписывает и отправляет транзакцию на стороне сервера, поэтому ошибка не означает, что ничего не было записано в сеть. Crossmint и Fordefi в нативном авторежиме.
В таблице возможностей подписантов в README для каждого языка указана форма каждого бэкенда; в модели безопасности объясняется, что гарантирует каждая форма.
Корпоративные сценарии
Одному приложению часто требуется сразу несколько таких вариантов. Поскольку интерфейс общий, вы можете использовать разные бэкенды для разных ролей без изменения мест вызова, если у бэкендов одинаковая форма возможностей.
- Операции с казначейством — разделите операционный «горячий» подписант и «холодный» казначейский. Подкрепите казначейство MPC-хранилищем или облачным HSM и требуйте политики подтверждения перед подписанием крупных транзакций.
- Рабочие процессы согласования — бэкенды MPC и хранилища (например, Fireblocks) обеспечивают многостороннее согласование перед формированием подписи.
- Соответствие требованиям и аудит — облачные KMS (AWS/GCP) и Vault ведут журналы аудита подписания; институциональные кастодианы добавляют применение политик и отчётность.
- Регулируемые среды — храните ключевой материал в HSM, KMS или у институционального кастодиана, чтобы исходные ключи никогда не попадали в ваше приложение.
Ознакомьтесь с рекомендациями для production-среды по безопасной эксплуатации этих бэкендов.
Is this page helpful?