Внутри архитектуры абстракции аккаунтов SSP

SSP — это некастодиальный кошелёк, построенный вокруг multisig 2-из-2. Один ключ хранится в браузерном расширении SSP Wallet, второй — в мобильном приложении SSP Key, и ни одна транзакция не исполняется, пока её не одобрят оба устройства. На EVM-цепочках SSP обеспечивает эту гарантию с помощью account abstraction по ERC-4337: кошелёк представляет собой smart account, логика проверки которого принимает единую агрегированную подпись Schnorr, построенную из двух ключей. Эта статья проходит по всей архитектуре от начала до конца — каждый компонент, точный поток подписания и порождаемое им свойство безопасности.

Если account abstraction для вас в новинку, начните с Абстракция аккаунтов с первых принципов и сфокусированного разбора ERC-4337. Здесь мы предполагаем, что вы примерно представляете, что такое smart account и UserOperation, и сосредотачиваемся на том, как SSP связывает их вместе.

Компоненты, на которые опирается SSP

Прежде чем прослеживать поток, полезно назвать компоненты и то, что делает каждый из них:

• Smart account. На EVM-цепочках ваш кошелёк SSP — это не EOA, управляемый одним ключом. Это smart account по ERC-4337 — контракт, который хранит ваши средства и содержит собственную логику проверки. Эта логика и есть сердце конструкции: она принимает транзакцию только тогда, когда предоставленная подпись совпадает с ожидаемым агрегированным ключом кошелька.
• Два устройства. Ключ 1 хранится в браузерном расширении SSP Wallet. Ключ 2 хранится в мобильном приложении SSP Key. Каждое устройство держит одну долю и производит одну частичную подпись. Ни одна доля не может авторизовать что-либо в одиночку.
• UserOperation. Вместо обычной транзакции расширение выражает ваше намерение как UserOperation — структурированный объект, описывающий, что должен сделать account, и подпись, которая это авторизует.
• bundler. bundler забирает UserOperation из выделенного mempool, упаковывает её в настоящую он-чейн транзакцию и платит gas базового уровня, чтобы её отправить.
• EntryPoint. Единый прошедший аудит контракт EntryPoint — это он-чейн вход для каждой операции ERC-4337. Он вызывает ваш smart account, чтобы выполнить логику проверки этого account, а затем запускает исполнение, если проверка пройдена.

paymaster может опционально покрыть gas для UserOperation; это отдельная тема, рассматриваемая в Спонсирование gas и paymaster-ы простыми словами.

Точный поток подписания

Вот что происходит, шаг за шагом, когда вы отправляете транзакцию из SSP на EVM-цепочке:

  SSP Wallet extension (key 1)          SSP Key mobile app (key 2)
        |                                     |
        | 1. initiate tx                      |
        | 2. build UserOperation              |
        | 3. partial Schnorr sig  --- push -->| 4. approve
        |                                     | 5. partial Schnorr sig
        |                                     |
        |        6. aggregate (MuSig2 / secp256k1)
        |                v
        |        ONE Schnorr signature
        |                |
        v                v
  7. UserOperation --> 8. bundler --> 9. EntryPoint --> smart account
                                                  |
                                          validate aggregate sig
                                                  |
                                         valid? --> execute call

В виде прозы:

1. Вы инициируете транзакцию в браузерном расширении SSP Wallet, где хранится ключ 1.
2. Расширение собирает UserOperation по ERC-4337, описывающую действие.
3. Ключ 1 производит частичную подпись Schnorr над этой операцией.
4. Запрос передаётся в мобильное приложение SSP Key (ключ 2) для одобрения.
5. Ключ 2 производит собственную частичную подпись.
6. Две частичные подписи агрегируются в стиле MuSig2 над secp256k1 в одну подпись Schnorr.
7. UserOperation, теперь несущая эту единую агрегированную подпись, готова к отправке.
8. Она идёт к bundler, который упаковывает её в транзакцию и платит gas.
9. bundler отправляет её в контракт EntryPoint, который вызывает smart account SSP. Account проверяет единую агрегированную подпись против ожидаемого агрегированного ключа кошелька и, если она действительна, исполняет вызов.

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

Почему цепочка видит лишь одну подпись

Деталь, делающая конструкцию SSP изящной, — это агрегация на шаге 6. Расширение и телефон не прикрепляют к операции каждый свою отдельную подпись. Их две частичные подписи Schnorr объединяются — в стиле MuSig2, над той же кривой secp256k1, которую Ethereum уже использует — в одну подпись Schnorr. Smart account проверяет эту одну подпись против одного ожидаемого агрегированного ключа.

У этого есть два следствия, на которых стоит задержаться:

• Он-чейн след остаётся небольшим. UserOperation несёт одну подпись, а не две. Нет списка подписантов, который надо хранить или перебирать, и нет цикла проверки по каждому подписанту. Контракт выполняет ровно такой же объём работы по проверке, как и для одиночного подписанта.
• Цепочка не может определить, что это multisig. То, что попадает в EntryPoint, выглядит как обычная подписанная операция. Принуждение к 2-из-2 заключено в том, как подпись была произведена — на двух устройствах, — а не в какой-либо видимой на цепочке многосторонней структуре. Для внешнего наблюдателя кошелёк ведёт себя как любой другой smart account.

Именно в этом разница между подходом SSP и наивным multisig, который публикует N отдельных подписей и проверяет каждую. Механика реализации multisig таким образом на EVM подробнее разобрана в Multisig на EVM в стиле абстракции аккаунтов.

Что на самом деле защищает каждое устройство

Стоит быть точным насчёт свойства безопасности, потому что в нём и состоит весь смысл архитектуры.

• Ни один ключ в одиночку не может перемещать средства. Ключ 1 в расширении может собрать UserOperation и подписать свою половину, но половинная подпись агрегируется в нечто, что контракт не примет. Ключ 2 на телефоне может одобрить и подписать свою половину, но не может самостоятельно инициировать или завершить перевод.
• Компрометации одного устройства недостаточно. Злоумышленник, полностью контролирующий ваше браузерное расширение, всё равно не сможет потратить средства, потому что без телефона он не сможет произвести частичную подпись ключа 2. Обратное также верно. Модель угроз, которую EOA с одним ключом не переживает — один утёкший ключ, полная потеря, — здесь неприменима.
• Одобрение явное и на втором экране. Поскольку шаг 4 передаёт запрос в приложение SSP Key, вы видите и одобряете операцию на физически отдельном устройстве, прежде чем её можно будет агрегировать и отправить.

Это то же свойство 2-из-2, описанное в Что такое multisig 2-из-2?, реализованное на EVM-цепочках через абстракцию аккаунтов, а не через нативный multisig-опкод.

Преимущества, кратко

Сводя нити воедино, архитектура даёт пользователям SSP конкретное сочетание, которое иначе получить трудно:

• Безопасность multisig на каждой поддерживаемой EVM-цепочке. Та же конструкция 2-из-2 работает на Ethereum, Polygon, Base, BNB Smart Chain и Avalanche, потому что ERC-4337 — это стандарт уровня контракта, а не функция, специфичная для конкретной цепочки.
• Небольшой он-чейн след. Одна агрегированная подпись означает, что smart account проверяет так же, как одиночного подписанта, оставляя проверку лёгкой.
• UX как у одиночного подписанта. С вашей стороны это ощущается как одобрение транзакции на двух устройствах, а не как сбор комитета. Нет адресов сосписантов, которыми надо управлять, и нет отдельного multisig-контракта, который надо настраивать под каждый перевод.
• Никаких изменений протокола не требуется. Поскольку всё держится на ERC-4337, SSP получает всё это, не дожидаясь, пока абстракция аккаунтов на базовом уровне будет выпущена.

Замечание об аудите

Архитектура безопасности заслуживает доверия ровно настолько, насколько проверена. Smart contracts SSP прошли аудит Halborn в 2025 году. Внешний аудит не делает ни одну систему безупречной, но он является значимым сигналом доверия для логики контракта, которая обеспечивает описанное выше правило 2-из-2.

Куда двигаться дальше

Эта статья проследила абстракцию аккаунтов SSP от начала до конца. Чтобы глубже разобраться в окружающем стандарте и понятиях:

• Абстракция аккаунтов с первых принципов — почему EOA ограничивают и что означает абстракция аккаунтов.
• Что такое абстракция аккаунтов (ERC-4337)? — стандарт сам по себе, включая роли UserOperation, bundler и EntryPoint.
• Спонсирование gas и paymaster-ы простыми словами — как paymaster может покрыть gas для UserOperation.
• Multisig на EVM в стиле абстракции аккаунтов — механика multisig на EVM подробнее.

За формальной спецификацией обратитесь к EIP-4337; за более широкими усилиями — дорожная карта абстракции аккаунтов Ethereum отслеживает, куда всё движется. Вывод: SSP превращает абстрактное обещание программируемого account в конкретный кошелёк 2-из-2, где два устройства производят одну подпись, а цепочка просто видит действительную операцию.