Продвинутые кошельки

Концепции: Why Advanced Wallets, Multisig: Safe, Account Abstraction: ERC-4337, Smart Account Features, Social Recovery, MPC Wallets, Choosing Your Strategy

:::section{mins=5} Зачем нужны продвинутые кошельки :::

:::lead Один ключ – одна точка отказа. Multisig добавляет ещё ключи, но Bybit 21 февраля 2025 показал: атаковать можно слой между ключом и подписанным. Архитектура решений – это не «больше ключей», а разные плоскости защиты. :::

:::p{html} В карточке 3.1 мы рассмотрели кошелёк как пару ключей плюс способ хранить приватный ключ: где он лежит, кто его держит, какой объём бытовых процедур вокруг него выстроен. Это описание полно для большинства пользовательских сценариев: hot+hardware связка (3.1 §5) закрывает $5K–$100K при разумных привычках. Но у самой модели «один ключ контролирует всё» есть архитектурный потолок. Подписанная транзакция уходит в сеть и становится необратимой: у [[gloss:eoa|EOA]] нет встроенного лимита на сумму, задержки на «передумать», возможности добавить второго согласующего. Это не плохой UX и не отсутствие фич – это следствие того, как Ethereum валидирует транзакции на уровне консенсуса. :::

:::p{html} 21 февраля 2025 года, 14:13 UTC – биржа Bybit запускает рутинный перевод 30 000 ETH с холодного кошелька на тёплый. Кошелёк – Safe{Wallet}, [[gloss:multisig|multisig]] 3-из-6. Три подписанта на своих рабочих местах открывают приложение Safe, видят знакомую транзакцию: адрес получателя, сумма ETH, обычный перевод. Каждый подписывает на своём аппаратном кошельке. Через несколько минут с холодного кошелька выводят не 30 000 ETH, а 401 347 ETH, примерно $1,46 миллиарда. Это крупнейший крипто-взлом в истории. Multisig сработал точно как задумано: три подписи собраны, каждая криптографически валидна, контракт исполнил то, что было подписано. Атака произошла на другом слое: на web-интерфейсе Safe{Wallet}, JavaScript-код которого был подменён через скомпрометированную инфраструктуру AWS за два дня до атаки. Подписанты видели одну транзакцию, подписывали другую. Аппаратные устройства показывали хеш (нечитаемую строку), и три человека независимо нажали «Подтвердить». :::

:::p{html} Урок из этой истории не «multisig не работает». Multisig сработал. Урок другой: безопасность не сводится к одному параметру (количеству ключей), а распределяется по нескольким плоскостям: где живёт ключ, кто его держит, что показывает интерфейс, что валидирует контракт, как восстанавливается доступ при потере. Криптоиндустрия за десять лет выработала четыре основных класса решений, каждый из которых усиливает свою плоскость. Multisig делит ответственность по подписи между несколькими держателями ключей, защищая от компрометации одного ключа. [[gloss:account abstraction|Account Abstraction]] (ERC-4337, март 2023; [[gloss:eip-7702|EIP-7702]], май 2025) выносит логику валидации в смарт-контракт, и через этот код можно добавить лимиты, batching, программируемые правила. Social recovery возвращает доступ при потере ключа через доверенных guardians. MPC (Multi-Party Computation, многосторонние вычисления) разбивает приватный ключ на шарды, которых нигде нет целиком. В остальных секциях карточки мы разбираем каждую плоскость отдельно: что она реально защищает, какие у неё пределы, и в каких комбинациях они работают на практике. :::

:::callout Система оценки знаний в школе устроена похоже. Если бы был только один итоговый экзамен с одной попыткой, это была бы модель EOA: завалил – и отчислен, повезло с билетом – и диплом. Но школа за столетия выработала несколько разных слоёв оценки: накопительная система за семестр (один плохой день не обнуляет всё), экзаменационные комиссии из нескольких преподавателей (один человек не может поставить «два» из неприязни), пересдача с задержкой и подготовкой (есть шанс исправиться без полного перезапуска), параллельные формы контроля: устный, письменный, практический (одна форма ошибки не скроет пробел). Ни один слой не делает учеников умнее. Каждый снижает риск, что одна точка отказа уничтожит результат многолетней работы. Продвинутые кошельки устроены ровно так же: каждый класс решений – это отдельный слой страховки от своего типа сбоя, не «улучшение» обычного кошелька в целом. :::

:::keypoints{label="КЛЮЧЕВЫЕ МОМЕНТЫ"} html: EOA в Ethereum – это один [[gloss:ecdsa|ECDSA]]-ключ secp256k1 и одно правило валидации: sender == ecrecover(tx_hash, signature). Это правило вшито в исполнительный слой протокола, изменить его на уровне EOA невозможно. Никакой логики «выше» подписи на самом аккаунте: нельзя добавить лимит на сумму, batching нескольких операций, оплату газа в USDC, выбор «кто ещё должен согласиться». Это архитектурное ограничение, и продвинутые кошельки – это разные способы обойти его, не меняя самого Ethereum. html: Bybit, 21 февраля 2025, $1,46 миллиарда: multisig 3-of-6 сработал штатно. Подписанты подписали транзакцию, которая прошла валидацию контракта. Атака была на слой между ключом и подписанным: web-интерфейс Safe{Wallet}, в который Lazarus Group (DPRK) внедрила вредоносный JavaScript через скомпрометированную инфраструктуру AWS. Подписанты думали, что переводят 30 000 ETH; подписали подмену реализации Safe на вредоносный контракт. Аппаратные устройства показывали только хеш – без декодирования – что превратило подпись в blind signing (см. 3.1 §5). html: Четыре класса решений появились в разное время и в разных контекстах: Bitcoin-multisig (BIP-16, 2012), Safe (Ethereum, 2017), MPC-кастоди (Fireblocks, 2018), ERC-4337 AA (2023), EIP-7702 (Pectra, 2025). Они не образуют лестницу «каждый следующий лучше». Это разные ответы на разные классы рисков: компрометация одного ключа (multisig), бесконтрольная подпись (AA добавляет лимиты, batching), потеря доступа (social recovery), концентрация секрета в одной точке (MPC). В конкретном сетапе они обычно комбинируются по слоям: multisig поверх аппаратных кошельков, social recovery как «полис» от потери всех владельцев, MPC у институционального кастодиана с регуляторными требованиями. html: «Чистая» стратегия одного класса в 2026 году встречается редко. На практике стандарт – комбинация по уровням ценности: hot+hardware из 3.1 для повседневных операций ($5K–$100K), Safe multisig 2-of-3 для крупных сумм ($100K–$10M), social recovery как «страховка» для долгосрочного хранения. При этом никакая комбинация не заменяет ручную проверку: сверить адрес, сумму и сопоставить с тем, что показывает экран аппаратного устройства. :::

:::details{badge=Глубже title="Что именно подписали в Bybit: один параметр на $1,46 миллиарда"} :::p{html} Что было в инфраструктуре Safe до 21 февраля. К моменту атаки злоумышленники уже две недели имели тайный операционный доступ к AWS-облаку Safe – то есть могли читать и записывать файлы во внутренних хранилищах от имени легитимного разработчика. Точка входа была 4 февраля: через социальную инженерию заставили разработчика Safe{Wallet} запустить вредоносный Docker-проект («MC-Based-Stock-Invest-Simulator») на его macOS-машине, что её скомпрометировало и дало атакующим его AWS access-токены. Они нашли S3 bucket, обслуживающий статические файлы Safe{Wallet} (фронтенд на Next.js), скачали bundled JavaScript и потратили почти две недели на его изучение: искали момент, в котором transaction object передаётся из UI в функцию хеширования (EIP-712) перед отправкой на Ledger. Когда нашли, внедрили хирургически точный JavaScript с тремя свойствами: (1) активация только при определённых адресах from (Bybit cold wallet 0x1Db92e2E…CD2dFCF4 и адрес test-кошелька атакующих); (2) подмена transaction object между «нажал Sign в UI» и «hash ушёл на Ledger»; (3) восстановление оригинального вида в UI сразу после возврата подписи. Для любого другого пользователя Safe всё работало идеально нормально – поэтому атаку не обнаружили заранее. :::

:::p{html} Что произошло, когда пропозер Bybit нажал Sign. Пропозер создал в Safe UI рутинный transfer 30 000 ETH с холодного кошелька на тёплый: {to: hotWallet, value: 30000 ETH, data: 0x, operation: 0}. Внедрённый скрипт проверил from, нашёл совпадение и переписал объект перед подписанием: to: 0x9622…7242 (контракт атакующих), value: 0, data: 0xa9059cbb…, operation: 1. Первые четыре байта data – это селектор стандартного ERC-20 transfer(address, uint256), выбран намеренно, чтобы при беглом просмотре выглядело как обычный токен-перевод. На экраны трёх Ledger подписантов ушёл хеш именно этого подменённого объекта. Они переключались в Safe UI, чтобы свериться визуально, – а UI к этому моменту уже отрисовал назад оригинальный 30 000 ETH transfer. Подписант смотрел поочерёдно: хеш на Ledger → транзакция в UI → «совпадает» → Confirm. На самом деле хеш в UI и хеш на Ledger в этот момент не совпадали, но человек видит их не одновременно. Дополнительный фактор: operation: 1 отображался на Ledger отдельным полем «1», но за неделю до этого Bybit уже подписывал легитимный delegatecall для mETH staking, поэтому единица в этом поле для подписантов не была сигналом тревоги. :::

:::p{html} Что сделала on-chain транзакция и как замели следы. Когда собрались 3 подписи из 6, исполнитель отправил execTransaction(...) on-chain. Safe Proxy увидел operation: 1 и сделал delegatecall в контракт атакующих 0x9622…7242. Ключевая семантика delegatecall: код вызываемого контракта исполняется в storage самого Safe Proxy, а не в своём. Внутри 0x9622… была функция с сигнатурой transfer(address, uint256) (тот же селектор 0xa9059cbb, что у ERC-20), но делала она ровно одно: stor0 = _to, то есть записывала первый параметр в свой slot 0. Через delegatecall «своего» не было: запись пошла в slot 0 Safe Proxy, где хранится masterCopy – адрес контракта с легитимной логикой Safe. Slot 0 был 0x34CfAC…3F5F (Safe L2 v1.3.0); стал 0xbDd077…9516 – новый «implementation» атакующих, содержащий функции sweepETH(receiver) и sweepERC20(token, receiver), выводящие любые средства без проверки подписей. Атакующие сразу вызвали sweepETH и забрали 401 347 ETH. Через две минуты после исполнения они удалили вредоносный JavaScript из S3 bucket Safe и заменили его обратно на чистую версию; поэтому компрометацию инфраструктуры обнаружили только при расследовании инцидента через несколько дней. Этой атаки не могло бы быть, если бы хоть один из подписантов имел независимый канал верификации содержимого транзакции: отдельный сервис, парсящий calldata из подписываемого хеша, или второй экран, читающий ABI контракта-получателя. Это и есть то, что Safe начали внедрять после февраля 2025 (подробнее в §2); и почему индустрия идёт к архитектурам, где сам класс «доверие к единому UI» отсутствует (см. §5 о MPC). ::: :::

:::further{label="Для углублённого изучения"}

:::quiz{id=q-3-2-s1 label="Проверь себя" correct=2 explanation="Верно. Все три подписанта видели в Safe{Wallet} обычный перевод 30 000 ETH на тёплый кошелёк и подписывали именно его – на хеш-уровне. Но web-интерфейс Safe был скомпрометирован: JavaScript-код, обслуживающий приложение с AWS S3, был подменён за два дня до атаки через взлом машины разработчика Safe. Подписанты, не имея возможности декодировать сложную транзакцию на экранах аппаратных устройств (см. 3.1 §5, blind signing), подписали не перевод, а подмену реализации Safe на вредоносный контракт – после чего средства были выведены через функцию sweepETH(). Сам смарт-контракт Safe не имел уязвимости и сработал штатно; ключи не были скомпрометированы, владельцы сохранили над ними контроль. Атака была на слой между подписантами и контрактом – на UI, которому все участники доверяли."} 21 февраля 2025 года Bybit потерял $1,46 миллиарда из multisig-кошелька 3-of-6. Что было главной причиной взлома?

  • Все шесть ключей кошелька были скомпрометированы атакующими
  • Threshold в 3 подписи был слишком низким для cold-кошелька с такой суммой
  • Подписанты подписали транзакцию, отличавшуюся от того, что показывал интерфейс Safe{Wallet}
  • Smart-контракт Safe содержал ранее неизвестную уязвимость, которую и эксплуатировали :::

:::section{mins=6} Multisig: совместная подпись :::

:::lead Bybit был не первым. За четыре месяца до него у Radiant Capital из Safe-multisig 3-of-11 вывели $50 миллионов тем же паттерном: скомпрометированный UI, валидные подписи, blind signing на Ledger. Индустрия знала, но не успела перестроиться. Вопрос не в multisig, а в его тонкой настройке. :::

:::p{html} Multisig – это требование собрать N подписей из M возможных для исполнения операции. Идея древняя: банковские сейфы с двумя ключами, ядерные коды с двумя офицерами. В крипту она пришла рано и через две архитектурно разные двери. Bitcoin получил multisig нативно ещё в начале 2012 года: соответствующая операция была вшита в скриптовый язык протокола, и условие «N из M подписей» стало встроенным правилом расходования монет. Никакой произвольной логики кошельку Bitcoin задать нельзя: проверка подписей – единственное, что он умеет. Сужение по дизайну, но и защита: атаки вроде Bybit, где злоумышленник подменяет содержимое подписываемой транзакции, в Bitcoin структурно невозможны, потому что там нечего подменять. :::

:::p{html} Ethereum пошёл другим путём: нативной поддержки multisig в виртуальной машине нет, и реализация – это смарт-контракт, который любая команда может развернуть. Подписи владельцев собираются вне сети (через структурированное подписание, удобное для аппаратных кошельков), а на блокчейн уходит одна транзакция с приложенным массивом подписей. Контракт проверяет, что подписей достаточно и они валидны, и исполняет действие. Эта гибкость открывает богатые возможности (любая операция, любая логика, любая интеграция с другими контрактами) и одновременно раздувает поверхность атаки – то, что мы видели в §1. :::

:::p{html} На Ethereum стандартом де-факто стал Safe (бывший Gnosis Safe). Продукт начался как Gnosis Multi-Sig Wallet в 2017 году, эволюционировал в Gnosis Safe (2018) и выделился в отдельную команду Safe после спин-оффа из Gnosis в 2022 году. На начало 2026 года через Safe идёт серьёзная часть всей Ethereum-экономики: :::

:::p{html} Среди пользователей – Ethereum Foundation, Uniswap, Aave, Lido. Технически Safe устроен так, что заводить новый кошелёк стоит копейки: вся «умная» логика (проверка подписей, исполнение транзакций) живёт в одном общем смарт-контракте, развёрнутом в сети один раз. Каждый отдельный Safe – это маленький «указатель» (~50 байт), который при любом обращении говорит: «иди ко мне за логикой в этот общий контракт». Состояние конкретного кошелька (список владельцев, требуемое число подписей, история) хранится у самого «указателя», а вычисления делаются в общем. Подписи же собираются вне сети: каждый владелец подписывает структурированное сообщение в интерфейсе Safe, оно лежит там, пока не наберётся нужное число подписей, и только после этого один человек шлёт одну on-chain транзакцию с массивом подписей. Это даёт одну плату за газ вместо N и не требует синхронизации всех владельцев в один момент. :::

:::p Выбор главного параметра – порога – определяется тем, что защищается: :::

:::p{html} Multisig – мощный, однако узкий инструмент. Он надёжно защищает от: компрометации одного ключа (атакующий с одним ключом из набора владельцев не выведет ничего), внутреннего мошенничества (один владелец не может перевести себе деньги), потери одного устройства (остальные владельцы переназначат ownership и восстановят доступ). Но не защищает от другого класса угроз: :::

:::p{html} Главный риск, который часто недооценивают, – слишком низкий порог. У Radiant Capital было 3 подписи из 11, то есть всего 27%; атакующему с месяцем подготовки оказалось достаточно скомпрометировать треть владельцев. После хака протокол перенастроился на 4 из 7 (57%) и добавил независимый канал верификации поверх подписей. Разумная практика 2026 года для операций с критически важными контрактами: порог не ниже 60% владельцев, при этом сами владельцы должны быть разнородными по операционным системам, юрисдикциям и людям. Однородный набор уязвим к одной фишинговой кампании, как показал Radiant. :::

:::callout Закрытая премьера в театре устроена по тому же принципу. Чтобы поднять занавес, трое ключевых работников должны одновременно дать «готово»: режиссёр, художник по свету, звукорежиссёр. Если кто-то заболел или не пришёл – спектакль не начнётся. Это устраняет единоличное решение: один человек не может ни сорвать показ, ни запустить его в обход остальных. Но эта конструкция не защищает от того, что между утренней проверкой и вечерним выходом кто-то за кулисами подменил декорации. Все трое смотрят на сцену через свои мониторы, всё в порядке, все дают «готово» – и в момент поднятия занавеса перед зрителями оказывается совсем другая постановка. Multisig – это коллективное «готово», но не защита от подмены того, что считаешь готовым. :::

:::keypoints{label="КЛЮЧЕВЫЕ МОМЕНТЫ"} html: Bitcoin-multisig работает с 1 апреля 2012 года – 14 лет без серьёзных атак на сам механизм. Институциональные кастодианы (Coinbase Custody, BitGo, Gemini) держат основные резервы именно в нём: меньшая поверхность атаки. Safe появился в 2017-м и за восемь лет получил Radiant и Bybit – оба удара пришлись не на криптографию multisig, а на слой между ключами и контрактом. html: Safe – модульный: к базовому «N из M» можно прикрутить лимиты на дневные траты, отложенное исполнение, разные пороги для разных категорий. Адреса детерминированные – один и тот же Safe разворачивается на любом EVM-чейне. И в отличие от MPC (см. §5), Safe полностью on-chain: нет третьей стороны, у которой лежит часть ключа или правила доступа. html: У высокого порога – свой риск, симметричный низкому. Низкий (Radiant 3 из 11) делает компрометацию катастрофичной; высокий (7 из 9) парализует кошелёк, как только несколько владельцев недоступны. Поэтому Radiant после хака не просто поднял порог, но добавил параллельный слой: Snapshot-голосование и 48-часовой timelock – независимый канал, не связанный с порогом вообще. html: Safe после Bybit выкатил десять UI-изменений: декодирование calldata, обязательное подтверждение для operation: 1, валидации для крупных транзакций. Но это полумеры, не лечение: половина проблемы – вне Safe. Безопасное отображение сложной транзакции на экране Ledger требует обновления прошивки аппаратного кошелька, а не интерфейса Safe. Архитектурный класс «доверие к единому frontend» остаётся. :::

:::details{badge=Глубже title="Архитектура Safe: minimal proxy, EIP-712, и что изменилось после Bybit"} :::p{html} Minimal proxy и singleton implementation. До 2018 года каждый новый multisig-кошелёк на Ethereum деплоился как полный контракт – это стоило 700 000 газа ($5–50 в зависимости от gas price). Gnosis Safe ввёл EIP-1167 minimal proxy: на цепь деплоится один полнофункциональный implementation-контракт (Safe L2 v1.3.0 на адресе 0x34CfAC…3F5F), а каждый новый Safe – это крошечный proxy размером ~50 байт. Этот proxy содержит ровно одну инструкцию: «всё, что мне присылают, передавай через delegatecall в адрес из моего slot 0». В slot 0 записан адрес singleton implementation. В последующих ячейках storage – owners, threshold, nonce, и другое состояние конкретного Safe. Развёртывание нового кошелька стоит ~50 000 газа вместо 700 000. Эта же архитектура – причина, по которой Bybit-атака стала возможна: один параметр operation: 1 + delegatecall в контракт атакующих + запись по адресу slot 0 = смена implementation для всего proxy. Атакующий не «взломал» Safe; он использовал штатный механизм апгрейда через proxy. :::

:::p{html} EIP-712 и off-chain координация подписей. При обычном multisig N-of-M подписей в лоб каждый владелец слал бы on-chain транзакцию «голосую за X», и контракт ждал бы N таких голосов. Это N gas-fees и N nonce-конфликтов. Safe пошёл иначе: использует EIP-712 structured signing. Координирующее приложение (обычно Safe UI) создаёт TypedData – структурированное сообщение с namespace EIP712Domain, типом SafeTx, и полезной нагрузкой (to, value, data, operation, gas-параметры, nonce). Каждый владелец подписывает off-chain (Ledger показывает структуру полей, а не голый хеш). Подписи накапливаются в координирующем приложении до достижения threshold. Затем любой исполнитель (не обязательно владелец, не обязательно вообще участник multisig) шлёт одну транзакцию execTransaction(...) с массивом подписей. Результат: одна gas-fee на весь multisig, асинхронная координация (не нужны синхронные звонки между всеми владельцами), отсутствие гонок nonce. Цена этой элегантности – единая точка координации: если Safe UI скомпрометирован, все подписанты видят одинаково подделанные данные. Bybit и Radiant – две реализации этого риска. :::

:::p{html} Что Safe изменили после февраля 2025. 23 февраля Safe ввели режим блокировки и переустроили инфраструктуру обслуживания; 3 марта Martin Koeppelmann (сооснователь Safe) опубликовал, что команда выкатила десять изменений в интерфейсе и backend. Среди подтверждённых: более строгое декодирование calldata (интерфейс пытается распознать формат data до показа подписанту), явные предупреждения на operation: 1 с обязательным двухшаговым подтверждением, дополнительные валидации для крупных транзакций, улучшенная интеграция с Tenderly-симуляцией. Чего эти изменения не решают: проблему декодирования ABI на аппаратных устройствах (для этого нужно обновление прошивки Ledger/Trezor, не Safe), физическое ограничение размера экрана аппаратных кошельков, доверие к общей цепочке поставки (тот же JS-frontend на S3 всё ещё единая точка для всех Safe-аккаунтов). Поэтому разумная практика 2026 года для хранения крупных сумм: локальное развёртывание собственного Safe-интерфейса (свой frontend в собственной инфраструктуре), независимая проверка правил безопасности (вторая система разбирает содержимое транзакции независимо от интерфейса), и обязательная симуляция транзакции на отдельной машине перед подписанием. Дальше в карточке: §5 (MPC) показывает альтернативный архитектурный класс, где сама поверхность атаки multisig-смарт-контракта отсутствует. ::: :::

:::further{label="Для углублённого изучения"}

:::quiz{id=q-3-2-s2 label="Проверь себя" correct=2 explanation="Верно. A, B и D – это именно те риски, против которых multisig устроен. Один скомпрометированный ключ из 2-of-3 ничего не даёт атакующему; один владелец не может перевести себе средства без согласия остальных; потеря одного устройства из M некритична, потому что M-1 могут переназначить ownership. C – другое: UI-атака на frontend подменяет данные между подписантом и контрактом, и все N подписантов видят одинаково подделанные данные на одном и том же скомпрометированном UI. Multisig здесь сработает «штатно» – соберёт валидные подписи под подделанной транзакцией. Radiant Capital (16 октября 2024, $50M) и Bybit (21 февраля 2025, $1,46 миллиарда) – два эпизода одного класса риска с интервалом в 4 месяца. После Bybit Safe внедрили серию заплаток в UI, но архитектурный класс «доверие к единому frontend» остался."} Что Safe-multisig не защищает по архитектуре?

  • Компрометацию одного приватного ключа из threshold-set
  • Внутреннее мошенничество одного владельца
  • Подмену UI кошелька через скомпрометированную supply-chain инфраструктуру
  • Потерю одного аппаратного устройства из M владельцев :::

:::section{mins=6} Account Abstraction: программируемые правила :::

:::lead В §1 мы видели архитектурный потолок EOA: один ключ, одно безусловное действие. Account Abstraction снимает его, вынося логику валидации в смарт-контракт. К 2026 году подход работает в масштабе: десятки миллионов smart-аккаунтов. Но та же гибкость, которая даёт защиту, открывает и новый класс фишинга. :::

:::p{html} Снять архитектурный потолок EOA – задача не очевидная. С 2015 года индустрия пробовала это сделать минимум трижды, и каждая попытка разбивалась об одну и ту же стену: необходимость изменить консенсус Ethereum. EIP-86 (Виталик, 2015) предлагал валидацию через произвольный код. EIP-2938 (2020) добавлял новый тип транзакции AA_TX_TYPE. EIP-3074 (2021) пробовал опкоды AUTH и AUTHCALL. Все три требовали хардфорка всего протокола. Ни один не дошёл до mainnet – каждый годами застревал в governance. :::

:::p Зачем это нужно пользователю, у которого уже работает обычный кошелёк? Account Abstraction решает несколько проблем, которые в EOA принципиально не решаются: :::

:::p{html} Технически всё это работает так. ERC-4337 не меняет консенсус Ethereum, а строит посреднический слой поверх него – на одних только смарт-контрактах. Идея в трёх шагах: :::

:::p{html} На цепи всё приходит в один общий контракт-диспетчер – EntryPoint, развёрнутый по одному и тому же адресу на любой EVM-сети (Ethereum, Arbitrum, Optimism, Base, Polygon, zkSync). Он проверяет подписи, направляет каждое намерение в соответствующий смарт-аккаунт и берёт на себя оплату газа. :::

:::p На Q1 2026 результат осязаемый: более 40 миллионов развёрнутых smart-аккаунтов, более 100 миллионов исполненных UserOperations, ERC-4337 работает на любой крупной EVM-совместимой сети. Но для всего этого нужно было мигрировать на новый адрес smart-аккаунта – и здесь появился следующий шаг. :::

:::p{html} EIP-7702 в составе Pectra (7 мая 2025 года) решил проблему миграции: существующий EOA может временно делегировать свой code-slot смарт-контракту через новый тип транзакции 0x04 SET_CODE_TX_TYPE без смены адреса. Подписал tuple авторизации, и с этого момента любой вызов твоего EOA исполняется через код контракта-делегата. Адрес тот же, баланс тот же, история та же. Но вместе с этим пришёл новый вектор атаки. Та же делегация, благодаря которой MetaMask может предложить «переключись на smart-аккаунт ради одного swap», даёт и фишинговому сайту возможность убедить пользователя подписать одну авторизацию, чтобы получить постоянный proxy в контракт атакующих. К концу 2025 года Wintermute и GoPlus Security зафиксировали: 80–90% наблюдаемых делегаций EIP-7702 связаны с вредоносными sweeper-контрактами; группа Inferno Drainer использовала официальный Delegator-адрес MetaMask как прикрытие в инцидентах на $146K и $1,54M. Обещание AA (улучшенный UX, batching, recovery) пришло с симметричной поверхностью атаки. Остальная часть этой секции объясняет, откуда идёт и выигрыш, и риск. :::

:::callout Это разница между обычной дебетовой картой и кредиткой с правилами. EOA – дебетовая: есть подпись (или PIN), есть остаток – если хватает, платёж проходит. Никаких «не больше X в день без подтверждения», никакого chargeback, никаких подписей второго человека. Что подписал, то и ушло. Smart-аккаунт – кредитная карта со встроенными правилами: дневной лимит, лимит на онлайн-покупки, SMS-подтверждение на крупные суммы, chargeback при мошенничестве, добавочные карты для семьи со своими лимитами. Тот же физический «носитель», но программируемые правила определяют, что можно. ERC-4337 – это выпустили новую кредитку: получаешь новый номер, переводишь автоплатежи, переоформляешь подписки. EIP-7702 – другое: твоя дебетовая теперь умеет работать как кредитная, номер не меняется. Удобно. Но та же гибкость, на которой держится удобство (онлайн-оплата, моментальное подтверждение, программируемые лимиты), открывает фишинг: жертве звонят, она диктует одноразовый код – и с карты с «умными правилами» уходит сумма, которую обычная дебетовая не пропустила бы без подтверждения вживую. Чем умнее карта, тем больше способов в неё пролезть. :::

:::keypoints{label="КЛЮЧЕВЫЕ МОМЕНТЫ"} html: ERC-4337 – это сознательный компромисс на 8 лет. Виталик предложил Account Abstraction в EIP-86 ещё в 2015 году; три попытки протолкнуть её через изменения консенсуса застряли в governance до 2023-го. 4337 решил пойти не «правильным» (на уровне протокола), а прагматичным путём: получить AA через посредников и overhead-газа вместо изменений ядра. Цена – каждая UserOp на 30–50% дороже обычной EOA-транзакции. Выигрыш – AA на mainnet без хардфорка через 5 лет ожидания. html: У ERC-4337 есть новый класс централизации, которого нет у обычной Ethereum-транзакции. Bundler-ы – не валидаторы Ethereum, это отдельный коммерческий слой со своим mempool и своей экономикой. Pimlico на Q1 2026 держит около 30% всех UserOps, Coinbase и Stackup – большую часть остального. Если один доминирующий Bundler ляжет, треть AA-операций на mainnet остановится. На L2 это решается переносом EntryPoint в сам протокол (RIP-7560 в Arbitrum, zkSync), но на mainnet 4337 остаётся. html: У EIP-7702 есть архитектурная особенность, которая расширяет поверхность атаки: подпись авторизации может быть chain-agnostic (с chain_id = 0). Это значит – одну и ту же подпись можно повторить на нескольких EVM-сетях. Композируемость с ERC-4337 усиливает риск: EntryPoint в любой сети может вызвать делегированный EOA как обычный smart-аккаунт без новых действий жертвы. Одна подпись → потенциальный drain на нескольких цепях. html: У AA есть структурное свойство, работающее в обе стороны: программируемые правила позволяют любое поведение – доверенное или враждебное. У ERC-4337 это смягчается миграцией: жертва должна сознательно завести smart-аккаунт на новом адресе. У EIP-7702 такого порога нет – одна подпись на знакомом адресе превращает EOA в proxy. Ответ MetaMask – whitelist делегаторов и обязательное подтверждение апгрейда внутри кошелька, а не через DApp. :::

:::details{badge=Глубже title="Анатомия UserOperation, экономика Bundler-ов и механика EIP-7702"} :::p{html} Анатомия UserOperation и три фазы. UserOperation – это структурированный объект с полями, которые EVM в обычной EOA-транзакции собирает самостоятельно: :::

Исполнение проходит три фазы:

Разделение между валидацией и исполнением – главный архитектурный выигрыш: правила аккаунта могут отказать в действии до того, как оно начало что-то стоить.

:::p{html} Экономика Bundler-ов и RIP-7560. Bundler – не валидатор Ethereum; это отдельная инфраструктура со своим mempool, своими MEV-стратегиями и своим ценообразованием. Рынок на Q1 2026: Pimlico держит около 30% обрабатываемых UserOps, оставшаяся часть распределена в основном между Coinbase и Stackup. Bundler-ы зарабатывают на тонкой марже с газа каждого UserOp: они авансом платят газ mainnet-у, EntryPoint возмещает им при успехе. Цена этой архитектуры: каждый UserOp платит overhead валидации EntryPoint поверх собственно вызова – поэтому ERC-4337 транзакции примерно на 30–50% дороже эквивалентных нативных EOA-транзакций. RIP-7560 (это Rollup Improvement Proposal, а не Ethereum L1 EIP) решает эту проблему на L2-ах, перенося логику EntryPoint в сам протокол: Arbitrum и zkSync обрабатывают UserOperations как нативные типы транзакций, обходя overhead контрактного уровня. Mainnet, по всей видимости, останется на 4337 в обозримом будущем – но L2 с поддержкой 7560 получают существенно более дешёвые smart-аккаунты. :::

:::p{html} Механика EIP-7702 и почему 80% делегаций вредоносные. Транзакция типа 0x04 SET_CODE_TX_TYPE встраивает в себя authorization list – кортежи вида (chain_id, address, nonce, y_parity, r, s), где подпись авторизует установку delegation designator 0xef0100 || delegator_address в code-slot EOA. После установки любой вызов EOA исполняется через fallback() делегата. В работе arxiv 2512.12174 идентифицированы три устойчивых сценария атаки: :::

:::p{html} Композируемость с 4337 – главная причина опасности второго и третьего сценариев: одна подпись авторизации даёт возможность повторного drain без новых действий пользователя. Защита MetaMask – whitelist делегаторов: по умолчанию разрешён только их собственный аудированный Delegator-контракт (0x63c0c19a282a1B52b07dD5a65b58948A07DAE32B), а апгрейд через интерфейс требует ручного подтверждения внутри кошелька. Отзыв возможен через новый SET_CODE с address(0). Архитектурный предел: у авторизации нет scope – делегация работает на уровне кода, а не на уровне вызова, поэтому нельзя ограничить «только этот контракт» или «только эту сумму». Либо делегат доверен полностью, либо его не должно быть установлено. ::: :::

:::further{label="Для углублённого изучения"}

:::quiz{id=q-3-2-s3 label="Проверь себя" correct=2 explanation="Верно. A неверно: EIP-7702 и ERC-4337 – это разные механизмы. 4337 – отдельный smart-аккаунт по новому адресу, 7702 сохраняет исходный адрес EOA. B неверно: это ключевая ловушка EIP-7702. Делегация персистентна – действует на каждую последующую транзакцию, пока пользователь не подпишет новый SET_CODE с address(0) для отзыва. Именно эта персистентность делает фишинговый вектор столь эффективным: одной подписи авторизации достаточно, чтобы навсегда перенаправлять любые будущие вызовы в контракт атакующих. D неверно: EIP-7702 создавали специально, чтобы избежать миграции, требовавшейся у 4337. Правильный ответ – C."} Какое из следующих утверждений про EIP-7702 верно?

  • EIP-7702 – это альтернативное название ERC-4337
  • Делегация EIP-7702 действует только на одну транзакцию и отменяется автоматически
  • Подпись авторизации EIP-7702 устанавливает постоянную делегацию code-slot EOA до явного отзыва
  • EIP-7702 требует миграции на новый адрес smart-аккаунта :::

:::section{mins=5} Social Recovery: восстановление через доверенных :::

:::lead Стефан Томас заблокировал в IronKey 7 000 BTC – больше $700 миллионов, ушедшие из обращения навсегда. По оценкам Chainalysis, около 20% всего биткоина потеряно так же: забытые seed-фразы, повреждённые диски, умершие владельцы без доступа для наследников. Social recovery – попытка ответить на этот класс потерь. :::

:::p{html} 11 января 2021 года Виталик опубликовал заметку «Why we need wide adoption of social recovery wallets». В ней он назвал то, что криптосообщество долго считало неотъемлемой ценой self-custody: стоит потерять seed, и аккаунт исчезает навсегда, без второго шанса. Виталик назвал это не философией, а техническим долгом: исправимой ошибкой дизайна, а не неотъемлемой чертой децентрализации. Аналогия у него простая: банк восстанавливает доступ через документы, подписи, заявления; почему крипто требует всё-или-ничего? За несколько недель до этой публикации CEO Nexus Mutual Хью Карп потерял около $8 миллионов в NXM через targeted-атаку на аппаратный кошелёк. Эта история и история Стефана Томаса с 7 000 BTC стали катализатором. :::

:::p{html} Почему «3-of-5 guardians» – это не то же самое, что multisig? Потому что guardians не подписывают повседневные транзакции. Social-recovery кошелёк имеет один signing key для повседневности (UX как у обычного кошелька, одна подпись на транзакцию) и список guardians, которые всё это время находятся в спящем режиме. Guardians активируются ровно в одном сценарии: вы потеряли подписывающее устройство и нужен новый ключ. Вот как выглядит recovery на практике: :::

:::p{html} Первое продакшен-применение – Argent, запущенный в 2018 на Ethereum L1. Тот самый Argent, основателю которого Виталик в начале своей заметки 2021 года выразил благодарность. Создание кошелька на L1 стоило около $120 газа, что ограничивало массовое применение. В 2023 году Argent перешёл на Starknet, ZK-rollup, где тот же кошелёк стоит копейки. На 2026 год у Argent два продукта: Argent Mobile на Starknet и Argent X как browser-расширение. Оба комбинируют default Argent Guardian (сервис, который держит сам Argent, можно убрать из кошелька) с добавленными пользователем guardians: друзьями, семьёй или своим же аппаратным кошельком на другом адресе. Coinbase Smart Wallet (2024) пошёл другим путём: вместо людей-guardians используются passkeys, синхронизированные через iCloud Keychain или Google Password Manager. Две философии одной проблемы – одна доверяет людям, другая безопасности аккаунта в облаке. Каждая закрывает свой класс отказа; ни одна не «лучше» в целом. :::

:::p{html} Social recovery вводит угрозы, которых нет у seed-фразы: социальная инженерия против guardians, риск их сговора, риск что они сами одновременно потеряют доступ. Но эти угрозы исчисляемы и обратимы. Guardians можно поменять, неавторизованное recovery отменить во время окна задержки, можно структурировать кто имеет полномочия. У потерянной seed-фразы ни одного из этих свойств нет. :::

:::callout Завещание и душеприказчики устроены по той же схеме. Пока ты жив и в здравом уме, ты сам подписываешь все свои документы – никто другой не нужен. Но ты назначил трёх-пятерых душеприказчиков, людям, которым доверяешь, и они никогда не вмешиваются в твои дела, пока ты способен действовать сам. Если что-то случится – ты потерял дееспособность, умер, просто не можешь добраться до своих счетов – душеприказчики вместе запускают процедуру передачи доступа наследникам. Закон даёт окно оспаривания: процедура не моментальна, есть 30-90 дней, в течение которых её можно отменить, если это ошибка или мошенничество. Пока ты жив и в порядке, ты можешь в любой момент сменить душеприказчиков, отменить начатую процедуру, изменить условия. Social recovery работает так же: guardians не со-подписанты твоей повседневной жизни – это люди, которые могут вернуть тебе доступ, если ты его потерял, с окном для того, чтобы ты успел сказать «нет, это был не я». :::

:::keypoints{label="КЛЮЧЕВЫЕ МОМЕНТЫ"} html: Заметка Виталика 2021 года была переименованием, не техническим прорывом. Механика существовала с 2018 года (Argent). Что сделала заметка – взяла самый цитируемый авторитет индустрии и переклассифицировала «потерял seed – потерял всё» из неотъемлемого свойства self-custody в исправимый технический долг. Это переименование открыло дорогу для AA-инфраструктуры позже. html: Social recovery – это резервный канал, не операционный. Это и есть архитектурное отличие от multisig. Guardians не подписывают твои платежи, не одобряют сделки, даже не знают, что ты делаешь. Они активируются только для смены ключа – раз или два за всю жизнь кошелька, а то и ни разу. Поэтому можно ставить высокий порог (5-of-9, а не 2-of-3) – координация guardians бывает редко. html: Окно задержки – это критический механизм, не сам порог. Мгновенное recovery (атомарная смена ключа после голосования guardians) уязвимо к социальной инженерии: уговорил трёх – забрал всё. Задержка в 36 часов с многоканальными уведомлениями владельцу превращает это в «уговори трёх И продержи 36 часов так, чтобы владелец не заметил». Без задержки social recovery превращается в social attack. html: Argent и Coinbase Smart Wallet применяют противоположные подходы к одной проблеме. Argent распределяет доверие между людьми (голосование guardians). Coinbase Smart Wallet – по устройствам и облачным провайдерам (passkey + iCloud/Google sync). Они закрывают разные классы отказа: Argent выживает при потере устройств и облачного аккаунта; Coinbase предполагает, что облачный аккаунт цел. Правильный выбор зависит от того, что больше боишься потерять. :::

:::details{badge=Глубже title="Модель guardians у Argent, механика recovery и угрозы, которых нет у seed-фразы"} :::p{html} Контракт Argent: как устроена структура данных. Контракт кошелька Argent хранит четыре части состояния, важные для recovery: :::

:::p{html} Повседневные транзакции идут через execute() и проверяют только подпись owner – guardians не трогаются, газа уходит столько же, сколько у обычного кошелька. Recovery – отдельный путь: triggerEscape(newOwner) требует threshold-подписи guardians, выставляет recoveryTimestamp и эмитит событие, которое подхватывает сервис уведомлений Argent. В течение escape-периода исходный owner может вызвать cancelEscape() из любого своего канала (мобильное приложение, браузер, email-ссылка). Если прошло escapePeriod секунд без отмены, следующий вызов completeEscape() переписывает owner на newOwner, и подписывающий ключ кошелька сменился. На Starknet та же логика реализована в Cairo – дешевле на транзакцию, та же архитектурная форма. :::

:::p{html} Почему Виталик предложил именно такую форму, а не полный multisig на каждую транзакцию. Естественный вопрос: если ты доверяешь своим guardians, почему бы не требовать, скажем, 2-of-3 на каждую транзакцию вместо одиночной подписи? У Виталика аргумент был про UX. Multisig на каждое повседневное действие означает, что каждый платёж требует координации хотя бы с одним другим человеком, каждое игровое действие – второй подписи, каждый approve+swap+deposit тащит за собой двоих. Это ломает кошелёк для обычного использования. Разделение – одиночная подпись для повседневности, threshold guardians только для замены ключа – сохраняет удобство одно-ключевого кошелька и добавляет путь восстановления. ERC-4337 реализует это прямо внутри validateUserOp(): функция принимает обычную подпись owner для любой операции и threshold-подпись guardians только для специфической операции replaceOwner(). Две разные схемы подписей для двух разных путей через один и тот же контракт. :::

:::p{html} Угрозы, которых раньше не было, и как с ними бороться. У seed-кошелька одна угроза – потерять фразу. У social-recovery кошелька появляется несколько новых: :::

:::p{html} Практические меры: использовать guardians из разных социальных кругов (не три родственника), разных юрисдикций (не три американца), разных классов устройств (один телефон, один аппаратный кошелёк, один отдельный доверенный человек). Ставить порог выше N/2 и включать хотя бы одного технического guardian, например аппаратный кошелёк на отдельном адресе, иммунный к атакам на телефонный номер. Использовать многоканальные уведомления (email + push + on-chain событие, за которым следит сервис-наблюдатель). И ещё один архитектурный предел, который стоит проговорить вслух: social recovery защищает от потери, не от компрометации. Если атакующий украл ключ owner и вывел кошелёк до того, как ты заметил, никакое голосование guardians не вернёт средства. Для этого нужны лимиты трат, таймлоки, multisig на крупные операции, то есть инструменты из §2 и §3. Social recovery – один слой из нескольких, не замена остальным. ::: :::

:::further{label="Для углублённого изучения"}

:::quiz{id=q-3-2-s4 label="Проверь себя" correct=2 explanation="Верно. A неверно: guardians не участвуют в повседневных транзакциях – владелец подписывает один. Разделение между обычным подписанием и threshold-guardians-только-для-recovery и есть архитектурная суть. B неверно: окно задержки (обычно 24-36 часов) – это именно то, что делает social recovery устойчивым к социальной инженерии против guardians; без задержки три уговорённых guardian = кошелёк выведен. D неверно: multisig требует N-of-M подписей на каждую операцию; social recovery требует одну подпись владельца на всё и threshold-of-guardians только для смены ключа. C верно: вор, укравший ключ владельца и выведший кошелёк до того, как ты заметил, не отменяется голосованием guardians – для этого нужны лимиты трат, таймлоки, multisig на критические операции (инструменты из §2 и §3). Social recovery – один слой из нескольких."} Какое утверждение про social recovery wallets верно?

  • Guardians подписывают каждую транзакцию владельца
  • Recovery происходит мгновенно после голосования достаточного числа guardians, без задержки
  • Social recovery защищает от потери доступа, но не от компрометации основного ключа
  • Social recovery – это специальная форма multisig 2-of-3 :::

:::section{mins=5} MPC: ключ, которого нигде нет целиком :::

:::lead В §2 мы видели multisig: N отдельных подписей on-chain, видимая структура доверия. MPC (Multi-Party Computation, многосторонние вычисления) – другой класс: ключ существует только в виде разделённых частей, и подпись собирается так, что полный ключ нигде не появляется. К 2026 году через MPC-кастоди прошло больше $10 триллионов институционального капитала. :::

:::p{html} Multisig и MPC оба защищают от компрометации одного ключа, но делают это через принципиально разные архитектуры. Multisig – это несколько людей, несколько ключей, несколько подписей: у каждого владельца свой приватный ключ, каждый подписывает отдельно, контракт on-chain проверяет, что собралось достаточно подписей. Структура видна любому, кто читает блокчейн – владельцы, порог, история одобрений. MPC идёт другим путём: один ключ, разделённый на части, и полный ключ никогда не собирается ни в одной точке времени. Каждый участник держит свою часть (share) – фрагмент, бесполезный сам по себе и не раскрывающий ничего о полном секрете. Чтобы подписать транзакцию, t из n участников запускают распределённый криптографический протокол, который выдаёт обычную ECDSA- или Schnorr-подпись, и при этом ни у кого в памяти полного ключа не было. В блокчейне результат неотличим от обычной EOA-подписи. :::

:::p Зачем компании, у которой уже есть Safe multisig, переходить на MPC? Потому что на институциональном масштабе появляются четыре проблемы, которых нет у $50K личного кошелька: :::

:::p{html} Лидер рынка – Fireblocks, основанный в 2018 году в Израиле выходцами из военной кибербезопасности. К 2026 году через него прошло более $10 триллионов транзакций, обслуживается 2 400+ финансовых институтов, и протокол поддерживает 150+ блокчейнов – масштаб, какого у multisig-решений нет. Рядом работают BitGo (вышел на IPO в январе 2026 с оценкой $2 миллиарда, $90 миллиардов под управлением), Coinbase Custody (крупнейший регулируемый кастодиан крипты, $300 миллиардов под управлением) и Ledger Enterprise для тех, кто предпочитает аппаратное self-custody без MPC. :::

:::p{html} Есть оговорка, которую маркетинг провайдеров обходит стороной. «Никакая третья сторона не имеет ключа» – формально верно: полного ключа ни у кого нет. Но на практике провайдер обычно держит хотя бы одну долю ключа, инфраструктуру, на которой работает протокол (Intel SGX enclaves в случае Fireblocks), и систему правил одобрения, которая решает, можно ли подписать ту или иную транзакцию. Self-custody через MPC – это, по сути, доверие к конкретной реализации, а не отсутствие доверия вообще. Для регулируемой институции с отчётностью перед регулятором и службой безопасности, способной оценить аудиторскую историю поставщика, этот компромисс оправдан. Для личного кошелька на $50 000 – нет: операционная сложность перевешивает выигрыш, а Safe multisig из §2 уже закрывает соответствующую модель угроз. :::

:::callout Сейф банковского консорциума наглядно показывает разницу. У замка сложная комбинация, но вместо того чтобы один человек знал её целиком, комбинация разделена на пять частей между пятью участниками. Никто из них полной комбинации не знает. Чтобы открыть сейф, троим из пяти нужно присутствовать вместе и одновременно провернуть свои ручки в правильной последовательности – и замок откроется, хотя никто в комнате полную комбинацию никогда не видел. Стороннему наблюдателю видно только: сейф открылся. Сколько человек участвовало, кто именно, какой был порог – не видно. Сравни с multisig: это несколько отдельных замков на одной двери, каждый открывается своим ключом. Там можно сосчитать использованные ключи, узнать, чьи они, увидеть всю структуру одобрения. Та же цель – другой профиль видимости, другая поверхность атаки. :::

:::keypoints{label="КЛЮЧЕВЫЕ МОМЕНТЫ"} html: Путь MPC от теории к продакшену занял 36 лет. Эндрю Яо формализовал поле в 1982 году через «Millionaire's Problem»; первая продакшен-кастоди (Fireblocks) запустилась в 2018. Теория десятилетиями ждала рынок, достаточный, чтобы оправдать стоимость реализации, – институциональное принятие крипто наконец этот рынок дало. html: У MPC есть архитектурное преимущество, которого нет ни у одного другого класса: адрес кошелька сохраняется при смене подписантов. В multisig смена signers обычно означает новый адрес контракта и миграцию. В ERC-4337 смена owner – это on-chain транзакция. У MPC перегенерация долей делается чисто off-chain: ни миграции, ни нового адреса, ни on-chain следа. Для институций, которые ротируют команду custody поквартально, это разница между рутинной операцией и серьёзным проектом. html: «У третьей стороны нет ключа» – формально верно, на практике обманчиво. Fireblocks и BitGo не держат полного ключа, но обычно держат один share, инфраструктуру (Intel SGX enclaves) и движок политик. Self-custody через MPC означает доверие к конкретной реализации поставщика, а не отсутствие любого доверия. Протоколы поставщиков между собой несовместимы: кошелёк на Fireblocks MPC-CMP нельзя мигрировать на BitGo TSS (Threshold Signature Scheme) без полной перегенерации shares. html: MPC и multisig не конкурируют – они решают разные задачи. MPC выигрывает для институционального масштаба: много блокчейнов, частая ротация signers, высокий объём, операционная приватность. Multisig выигрывает там, где прозрачность – это feature: DAO-treasury с on-chain управлением, публичная верифицируемость «кто это одобрил». Потеря Bybit в §1 произошла не из-за того, что они использовали multisig, – а из-за blind signing на UI. Multisig был правильным инструментом; провал был в другом месте. :::

:::details{badge=Глубже title="Криптография TSS, архитектура Fireblocks и почему «Zero Proof» имел значение"} :::p{html} Threshold-подписи: как устроена математика. Threshold Signature Scheme (TSS) – это криптографический протокол, в котором t из n участников совместно производят цифровую подпись сообщения, и никто из них при этом не знает полного приватного ключа. У протокола две фазы. Distributed Key Generation (DKG): n участников вместе генерируют ключ в распределённой форме. Каждый получает share – функцию от (никогда не собранного) приватного ключа плюс вспомогательную информацию. Без «доверенного диспетчера», который бы раздавал части (сам диспетчер был бы точкой отказа). Подписание: t участников запускают многораундовый протокол, в котором каждый вычисляет partial signature из своего share, и partial signatures соединяются в финальную подпись, проверяемую стандартной ECDSA или Schnorr. Threshold-ECDSA до прорывов 2018 года был вычислительно тяжёлым; threshold-Schnorr (и EdDSA) структурно проще с самого начала – поэтому апгрейд Taproot в Bitcoin сделал Schnorr-MPC значительно дешевле. Индустриальный стандарт для threshold-ECDSA сегодня – MPC-CMP (Castagnos–Catalano–Mauromandi–Pailler), разработанный собственной криптокомандой Fireblocks и используемый в большинстве институциональных развёртываний. :::

:::p{html} Архитектура Fireblocks на практике. Fireblocks не просто реализует MPC-CMP – он встраивает протокол в стек, спроектированный под институциональные операции: :::

Trade-off, который стоит назвать: безопасность всей системы зависит от Intel SGX. У SGX была история side-channel уязвимостей (Spectre, Foreshadow, ÆPIC Leak), и любой будущий взлом SGX потребует фундаментальной переоценки MPC-кастоди-архитектур, на нём построенных. Чисто-программные MPC-реализации (без SGX) уходят от этой зависимости, но теряют гарантию аппаратной изоляции.

:::p{html} «Zero Proof» и как выглядят implementation-баги. В 2022 году исследователи Fireblocks раскрыли уязвимость в TSS-реализации BitGo, прозванную «Zero Proof»: она позволяла атакующему с доступом к одной скомпрометированной endpoint восстановить полный приватный ключ, опровергая центральное свойство безопасности MPC. Баг был в open-source библиотеке Lindell-Nof zero-knowledge proof, которую использовал BitGo; BitGo выпустил патч в феврале 2023 года. Средств не пропало (уязвимость была раскрыта до того, как её эксплуатировали), но эпизод иллюстрирует критическую вещь: безопасность MPC – это безопасность конкретной реализации, а не безопасность лежащей под ней криптографии. Математика TSS строгая и хорошо изучена. Каждая отгруженная реализация, однако, представляет собственную поверхность атаки: каждый раунд протокола, каждое zero-knowledge proof, каждый выбор сериализации share – место, где баг может обвалить модель безопасности. Ответ индустрии: тяжёлые инвестиции в сторонние аудиты, bug bounty и (аргумент Fireblocks) толчок к NIST-стандартизации. На Q1 2026 NIST IR 8214C всё ещё в draft, и формального американского стандарта на TSS нет. Этот пробел Fireblocks вместе с коалицией криптографов попросили агентство закрыть в 2025 году. ::: :::

:::further{label="Для углублённого изучения"}

:::quiz{id=q-3-2-s5 label="Проверь себя" correct=1 explanation="Верно. A описывает multisig, не MPC: в multisig у каждого владельца действительно свой приватный ключ, и контракт on-chain проверяет N отдельных подписей. C неверно: главное преимущество MPC на институциональном масштабе как раз в том, что он работает на любом блокчейне со стандартными ECDSA- или Schnorr-подписями – Bitcoin, Solana, что угодно. D – типичная маркетинговая ловушка: провайдер не держит полного ключа, но обычно держит один share, инфраструктуру (SGX-enclaves) и политический движок. B верно: это и есть архитектурное определение MPC – distributed key generation, threshold-подписание, полный секрет никогда не собирается."} Какое из утверждений про MPC верно?

  • Каждый участник MPC держит свой приватный ключ, и каждая транзакция требует N подписей on-chain
  • Ключ генерируется в распределённой форме; t из n участников совместно создают подпись, но полный ключ нигде целиком не существует
  • MPC работает только на Ethereum и EVM-совместимых сетях
  • В MPC у Fireblocks или другого провайдера нет никакого доступа к вашим средствам или инфраструктуре :::

:::section{mins=3} Стратегия: какой класс под какую задачу :::

:::lead Ни один класс не закрывает всё. Multisig падает при компрометации UI (Bybit); social recovery не помогает при краже основного ключа; MPC опирается на доверие к поставщику; AA через EIP-7702 открывает новый класс фишинга. Сильный сетап – это комбинация слоёв, подобранная под сумму и задачу, а не выбор одного класса. :::

:::p{html} Правильный сетап определяется тремя осями. Сумма в кошельке – она определяет, сколько операционной сложности экономически оправдано добавить. Частота операций – кошелёк, в который заходишь ежедневно, требует других инструментов, чем тот, что лежит десять лет. Структура контроля – один человек, семья, команда, корпорация, DAO. Эти три оси дают предсказуемые комбинации: :::

:::p{html} Задача не в том, чтобы выбрать одну строку. Каждый слой сетапа закрывает свою модель отказа: hardware защищает от malware на подписывающем устройстве; multisig – от компрометации одного ключа; social recovery – от потери ключа (не от компрометации); AA добавляет лимиты трат, batching и защиту от blind signing на крупном; MPC даёт институциональную инфраструктуру (мульти-чейн, off-chain ротация подписантов, непубличная структура одобрения), которую multisig не даёт. Комбинация классов – так реально устроены работающие treasury. :::

:::keypoints{label="КЛЮЧЕВЫЕ МОМЕНТЫ"} html: По умолчанию – комбинация, а не выбор. Реальный сетап семейного $5M выглядит так: аппаратные подписанты в трёх локациях + Safe 3-of-5 контракт + Argent social recovery как overlay + лимиты трат через AA-модуль + ежеквартальный процесс ревью. Пять слоёв, каждый закрывает свой класс отказа. «Выбрать один из четырёх классов» – это неверная постановка вопроса. html: Антипаттерны, которых стоит избегать. Недоинженерия: hot wallet с $5M (каждый клик на фишинг финален). Переинженерия: Fireblocks MPC для $10K (вы не подойдёте как клиент, а операционная стоимость превышает ценность). Multisig без recovery overlay для долгосрока (если все потеряли устройства, кошелёк мёртв). AA-кошелёк без whitelist делегаторов после EIP-7702 (см. §3 – одна подпись открывает постоянный бэкдор). html: При переходе через границу тира не мигрируйте всё одной транзакцией. По мере приближения баланса к следующему порогу разверните новый сетап параллельно на небольшой тестовой сумме, погоняйте его две-четыре недели, потом переводите средства частями. Один перевод $1M на свежеразвёрнутый Safe – идеальная цель для атакующего, наблюдающего за mempool. Несколько переводов поменьше, разнесённые по времени, – нет. html: Никакая комбинация классов не заменяет финальный шаг ручной проверки: прочитать адрес получателя и сумму на экране аппаратного кошелька перед нажатием Confirm. У Bybit (§1) был архитектурно правильный multisig; потеря произошла из-за того, что три подписанта доверились интерфейсу вместо экранов аппаратных устройств. :::

:::details{badge=Глубже title="Экономика стоимости, кейсы провалов по тирам и как выглядит сетап в несколько слоёв на $5M"} :::p{html} Экономика каждого класса. Стоимость развёртывания и накладные расходы на транзакцию определяют, когда каждый класс себя оправдывает: :::

Кривая стоимости и объясняет тиры: на $10K $5 за транзакцию в multisig – это 5% накладных на мелкий перевод, абсурд. На $1M те же $5 невидимы. На $10M с частыми операциями $50K в год Fireblocks – около 0,5%, нормальный порядок для институциональной безопасности.

:::p{html} Истории провалов по тирам – когда сетап не соответствовал сумме. У каждого масштаба свой характерный паттерн потерь: :::

:::p{html} Как выглядит реальный сетап семейного treasury на $5M. Грамотный сетап в несколько слоёв состоит из пяти отдельных компонентов, каждый закрывает свою модель отказа: :::

Ни один слой здесь не лишний. Удаление любого создаёт конкретный риск, который остальные слои не покрывают. Это и есть «комбинация слоёв» на практике. :::

:::further{label="Для углублённого изучения"}

:::quiz{id=q-3-2-s6 label="Проверь себя" correct=2 explanation="Верно. A неверно: MPC – это институциональная инфраструктура, экономически не оправданная ниже ~$10M, и как физлицо вы обычно не сможете даже стать клиентом Fireblocks. B неверно: MPC закрывает свой класс отказов (концентрация одного ключа, многоблокчейновые операции), но не заменяет восстановление от потери ключа или прозрачное on-chain управление. D неверно: на $1M+ один клик на фишинг финален, тир имеет значение. C верно – реальные кошельки построены как стеки слоёв, каждый закрывает свою модель отказа. Четыре класса из §2-§5 – это инструменты, а не альтернативы. Следующая карточка (3.3) разбирает, как транзакции фактически проходят через эти стеки – как слои взаимодействуют в момент подписания."} Какое утверждение про выбор стратегии кошелька верно?

  • Чем больше денег, тем больше слоёв – MPC правильный выбор для всего выше $100K
  • Если используешь MPC, multisig и social recovery становятся не нужны
  • Реальные сетапы – это комбинации слоёв: hardware как основа, multisig поверх, social recovery как backup, AA-лимиты где уместно
  • Hot wallet с биометрической разблокировкой достаточен для любой суммы при правильных привычках :::