EVM multisig по модели account abstraction

Multisig легко описать — требовать более одной подписи для перемещения средств — но способ его реализации заметно различается между блокчейнами. В Bitcoin multisig встроен в сам протокол. В Ethereum и других EVM-цепях это не так, и один лишь этот факт определяет, как работает любой серьёзный multisig-кошелёк на Ethereum, включая SSP. Эта статья объясняет, почему multisig в EVM устроен иначе, простым языком проводит по инструментарию account abstraction, который делает его возможным, и показывает, как именно SSP реализует настоящий 2-of-2 на Ethereum.

Если вы попали сюда с начала серии EVM, статья Ethereum в SSP закладывает основу; этот же материал — глубокое погружение в механику безопасности, лежащую под ней. Уровень изложения здесь на ступень выше — средний — потому что отдать должное теме означает честно затронуть ERC-4337 и агрегацию подписей, а не отделываться общими словами.

Почему multisig в EVM отличается от multisig в Bitcoin

Чтобы яснее всего понять SSP на Ethereum, сначала стоит увидеть, почему подход Bitcoin нельзя просто скопировать.

В Bitcoin есть нативный скриптовый multisig. Протокол включает опкод, который позволяет заблокировать средства за правилом вида «любые две из этих трёх публичных ключей должны подписать». Multisig-адрес в Bitcoin — это просто адрес с прикреплённым к нему правилом траты, и сеть применяет его напрямую. SSP использует это в Bitcoin и других UTXO-цепях через скриптовый multisig BIP-48: два ключа, один скрипт, требуются обе подписи. Если эта базовая модель для вас нова, начните со статьи что такое 2-of-2 multisig.

В Ethereum эквивалента нет. В EVM-цепи существует лишь два вида аккаунтов. Первый — это EOA, внешне управляемый аккаунт, контролируемый ровно одним приватным ключом. Один ключ, один подписант, и точка; нативного опкода, чтобы требовать две подписи на EOA, не существует. Второй — это аккаунт смарт-контракта, у которого вместо единственного управляющего ключа есть код, и он делает то, что этот код предписывает.

Поэтому в Ethereum «multisig» всегда означал кошелёк на смарт-контракте: контракт, запрограммированный высвобождать средства только при выполнении его правила множественной подписи. Именно эту модель ввели в обиход такие кошельки, как Gnosis Safe / Safe, и она хорошо работает. Платой за это является то, что классические on-chain multisig-контракты обычно хранят подпись каждого владельца и проверяют их по одной в сети, что стоит gas и растёт с числом подписантов. Account abstraction предлагает более чистый путь, и именно этот путь выбирает SSP.

Короткий и честный вводный курс по ERC-4337

Account abstraction — это идея о том, что ваш кошелёк должен быть смарт-контрактом, программируемым аккаунтом, а не обычной парой ключей. ERC-4337 — это стандарт, который реализует это на Ethereum, не меняя базовый протокол. Чтобы пользоваться SSP, овладевать им не нужно, но несколько терминов помогут уложить в голове остальную часть статьи. Полное изложение читайте в материале что такое account abstraction (ERC-4337); здесь же — карта на пользовательском уровне.

• Smart account. Ваши средства живут в smart account, чей код определяет, что считается действительной транзакцией. Поскольку это код, аккаунт может применять пользовательские правила — в том числе «требовать действительную подпись 2-of-2».
• UserOperation. Вместо отправки обычной транзакции smart account выражает своё намерение в виде UserOperation — структурированного запроса, который сообщает, что он хочет сделать, и несёт данные подписи, авторизующие это действие.
• Bundler. Bundler — это сервис, который собирает UserOperations, упаковывает их в настоящую on-chain-транзакцию и отправляет её. Он платит gas заранее и получает возмещение; он никогда не получает возможности перемещать ваши средства.
• EntryPoint. Единственный проверенный аудитом контракт EntryPoint — это доверенный on-chain-координатор. Он принимает упакованные UserOperations и вызывает каждый smart account, чтобы проверить, а затем выполнить его операцию.
• Paymaster. Необязательный контракт paymaster может спонсировать gas или позволять оплачивать комиссии в токене вместо нативной монеты. Он необязателен и независим от самого multisig.

Ключевая мысль: со smart account правило «кто может авторизовать транзакцию» — это управляемое вами программное обеспечение, а не фиксированное поведение протокола. Это ровно та свобода, которая нужна multisig в цепи, где нативного multisig нет.

Как SSP реализует 2-of-2 на EVM

SSP держит одно и то же обещание в каждой поддерживаемой цепи: два ключа на двух устройствах, и ни один из них в одиночку не может переместить ваши деньги. Ключ 1 живёт в браузерном расширении SSP Wallet; ключ 2 живёт в мобильном приложении SSP Key. Вы создаёте и подписываете транзакцию в расширении, а затем одобряете её на телефоне через push — требуются обе подписи.

В Bitcoin эта гарантия обеспечивается скриптовым multisig BIP-48. В EVM-цепях SSP воссоздаёт её как smart account ERC-4337, который проверяет агрегированную по Schnorr подпись 2-of-2. Вот эта идея на высоком уровне, оставленная общей там, где точное внутреннее устройство контракта не суть.

Каждый из ваших двух ключей формирует частичную подпись над транзакцией. Вместо того чтобы отправлять обе подписи в цепь по отдельности, два устройства объединяют их — используя агрегацию подписей в стиле MuSig2 — в одну компактную подпись. Smart account запрограммирован принимать UserOperation только тогда, когда эта агрегированная подпись проходит проверку относительно ожидаемого ключа кошелька. Поэтому цепь видит обычную на вид подпись, и тем не менее эту подпись математически невозможно создать без участия обоих ключей.

У такого подхода есть реальные преимущества перед хранением и проверкой N отдельных подписей в сети:

• Меньший след в сети. Одну агрегированную подпись дешевле проверять и хранить, чем две независимые, что обычно означает меньше gas за ту же безопасность.
• UX, идентичный кошельку с одним подписантом. Поскольку цепь проверяет единственную подпись, ваш smart account ведёт себя как любой обычный аккаунт с точки зрения сети. Отправка ETH, перемещение токенов ERC-20 или взаимодействие с DeFi ощущаются одинаково — вторая подпись тихо происходит между вашими двумя устройствами.
• Одна и та же модель повсюду. Schnorr и этот подход к агрегации опираются на хорошо изученную криптографию над secp256k1, и тот же дизайн smart account переносится на поддерживаемые SSP EVM-цепи, включая Ethereum, Polygon, Base, BNB Smart Chain и Avalanche.

Стоящие за этим смарт-контракты SSP были проверены аудитом Halborn в 2025 году. За более глубокой механикой account abstraction — как стыкуются EntryPoint, bundler и этап проверки — обращайтесь к материалу account abstraction (ERC-4337), а не считайте каноном какую-либо отдельную деталь контракта здесь.

Что это значит для вас как для пользователя

Криптография интересна, но в повседневности важна именно та защита, которую она покупает.

• Для перемещения средств требуются оба устройства. Транзакция действительна только после того, как расширение и SSP Key внесли каждый свою часть. Владения одним устройством — или одним ключом — недостаточно.
• Потеря одного устройства не означает потери ваших денег. Поскольку ни одно устройство не может подписать в одиночку, потерянный или стёртый телефон или переустановленный браузер не передают никому контроль над вашими средствами. Восстановление доступа — отдельная тема со своими мерами предосторожности; восстановление освещается в собственных руководствах, а не здесь.
• Один скомпрометированный ключ — это не единая точка отказа. Если вредоносное ПО или phishing захватят то, что лежит на одном устройстве, оно всё равно не сможет создать агрегированную подпись 2-of-2, которой требует smart account. Атакующему пришлось бы скомпрометировать оба ваших устройства одновременно — планка куда выше, чем опустошить кошелёк с одним ключом.

Это общие средства защиты, а не абсолютные гарантии; хорошая гигиена seed-фразы и безопасность устройств по-прежнему важны. Но структурный вывод остаётся в силе: прежде чем ценность сдвинется с места, два независимых фактора должны совпасть.

Нейтральное сравнение с кошельками EOA с одним ключом

Большинство кошельков Ethereum — это EOA с одним ключом. Они просты и широко поддерживаются, и для многих пользователей их достаточно. Платой является то, что один приватный ключ — это вся история целиком: тот, кто им владеет, может переместить всё, поэтому одна утёкшая seed-фраза или одна скомпрометированная машина могут оказаться роковыми.

Multisig на смарт-контракте меняет этот профиль риска, требуя согласия между двумя ключами вместо доверия одному. Существуют и другие multisig-кошельки на смарт-контрактах — Safe тому хорошо известный пример — и они решают ту же ключевую задачу по-своему. Особый выбор SSP — реализовать 2-of-2 через ERC-4337 с агрегированной подписью Schnorr, так что вы получаете безопасность multisig вместе со следом в сети и повседневным ощущением аккаунта с одним подписантом.

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

Если вам нужен концептуальный фундамент, прочтите что такое account abstraction (ERC-4337) и основополагающую статью что такое 2-of-2 multisig. Чтобы увидеть, как это вписывается в более широкую картину Ethereum в SSP, вернитесь к материалу Ethereum в SSP. А что касается самого стандарта, каноническими источниками являются спецификация ERC-4337 и обзор account abstraction от Ethereum Foundation. Сквозная мысль здесь та же, что проходит через каждую поддерживаемую SSP цепь: два ключа, два устройства, одна подпись — и вы у руля.