Разработка multi-approval для институциональных кошельков

Один скомпрометированный ключ — и средства фонда уходят за минуты. Институциональные клиенты — DAO, хедж-фонды, family offices — не могут полагаться на single point of failure. Multi-approval система решает эту проблему: она сочетает on-chain multisig (Safe{Core}) с off-chain политиками, HSM-интеграцией и полным аудит-трейлом. У нас 5+ лет опыта в разработке таких систем для 20+ проектов. Мы гарантируем защиту активов и соответствие жестким требованиям compliance. Внедрение multi-approval позволяет предотвратить потерю миллионов долларов — как показывает статистика, 80% инцидентов с казначейскими счетами DAO происходят из-за отсутствия многоуровневого утверждения. Экономия от внедрения может достигать $500k в год при объёме транзакций от $10M, а средняя стоимость одного инцидента безопасности — $2M.

Технические сложности, которые устраняет multi-approval

Компрометация ключа — один приватный ключ не даёт полного контроля. Даже если злоумышленник получит доступ к одному approver, он не сможет вывести активы — нужно N подписей. Для HSM-ключей private key физически не покидает защищённое железо. Человеческая ошибка: ошибочная транзакция блокируется на этапе проверки политик. Policy Engine отклоняет перевод на незнакомый адрес или сумму сверх дневного лимита в $10k. Аудит и compliance: каждый шаг логируется — кто создал запрос, кто одобрил, с какого устройства. Экспорт логов в формате для аудиторов с интеграцией в SIEM через webhook. Гибкость управления: роли разделены (Admin, Initiator, Approver, Executor, Auditor). Политики меняются без переразвёртывания смарт-контрактов — обновление через API занимает минуты.

Как работает multi-approval для институциональных кошельков?

Мы используем два уровня: on-chain multisig и off-chain политики. On-chain обеспечивает неизменяемое исполнение транзакций при достижении порога подписей. Off-chain добавляет гибкость: лимиты по суммам, whitelist адресов, time-locks, правило четырёх глаз. Комбинация даёт безопасность и адаптивность.

Детальная архитектура системы

Policy Engine — сервис, хранящий и применяющий правила:

• Whitelist адресов-получателей
• Spending limits (дневной, недельный лимит по токену)
• Time-based rules (транзакции только в UTC рабочие часы)
• Amount thresholds (до $10k — 2 подписи, свыше $100k — 5 подписей)
• Asset-specific rules (операции с определёнными токенами требуют одобрения CFO)

Approval Workflow Engine — управляет состояниями запросов:

PENDING_APPROVAL → COLLECTING_SIGNATURES → READY_TO_EXECUTE → EXECUTED ↘ REJECTED ↙

Каждый переход логируется с timestamp и actor_id — обязательно для compliance.

Signature Aggregator — собирает подписи EIP-712 (или EIP-1271 для смарт-контрактов). Хранит частичные подписи до порога.

Notification Service — уведомляет approvers по email, Telegram, Slack с deep-link для быстрого одобрения.

HSM интеграция — для крупных институтов ключи approvers хранятся в AWS CloudHSM или Azure Dedicated HSM. Подпись внутри HSM без экспорта private key. Реализация:

import * as pkcs11js from "pkcs11js";

class HSMSigner {
  private pkcs11: pkcs11js.PKCS11;
  
  async sign(txHash: Buffer, keyLabel: string): Promise<Buffer> {
    const session = this.pkcs11.C_OpenSession(this.slotId, pkcs11js.CKF_SERIAL_SESSION);
    this.pkcs11.C_Login(session, pkcs11js.CKU_USER, this.pin);
    const privateKey = this.findKeyByLabel(session, keyLabel);
    this.pkcs11.C_SignInit(session, { mechanism: pkcs11js.CKM_ECDSA }, privateKey);
    const signature = this.pkcs11.C_Sign(session, txHash, Buffer.alloc(64));
    this.pkcs11.C_Logout(session);
    this.pkcs11.C_CloseSession(session);
    return this.convertToEthSignature(signature);
  }
}

Ключевое: private key никогда не покидает HSM.

Safe{Core} — де-факто стандарт для Ethereum. Транзакция требует накопления подписей off-chain и финального execute вызова. Структура транзакции:

struct SafeTx {
    address to;
    uint256 value;
    bytes data;
    Enum.Operation operation;
    uint256 safeTxGas;
    uint256 baseGas;
    uint256 gasPrice;
    address gasToken;
    address refundReceiver;
    uint256 nonce;
}

Почему стоит комбинировать on-chain и off-chain политики?

Чистый on-chain multisig медленно адаптируется к новым требованиям: любое изменение политики требует миграции контракта. Off-chain Policy Engine даёт гибкость в 10 раз быстрее — лимиты и роли меняются через API без газа. А on-chain исполнение гарантирует, что политики нельзя обойти. Для транзакций сверх порога — обязательный time-lock (например, 24 часа), в течение которого другие owners могут отменить. Emergency pause замораживает все исходящие при компрометации. Получите консультацию по архитектуре вашей системы — оценим риски текущего решения.

Процесс внедрения

1. Аудит требований: анализ текущей инфраструктуры, ролей, compliance-нужд. Оценка рисков.
2. Проектирование: выбор архитектуры (on-chain только Safe или с off-chain engine), дизайн политик, ролевая модель.
3. Реализация: разработка смарт-контрактов (Safe Modules), backend (Node.js + PostgreSQL), frontend (React + wagmi), HSM-интеграция.
4. Тестирование: unit-тесты, интеграционные тесты, fuzzing (Echidna), formal verification (SLither, Mythril).
5. Security audit: внешний аудит контрактов и всей системы. Исправления.
6. Деплой и обучение: развертывание в инфраструктуре клиента, настройка CI/CD, обучение команды.

Сроки и что входит в работу

Ориентировочные сроки:

• Базовая система (Safe + workflow + UI): 8–10 недель
• С HSM интеграцией: +3–4 недели
• С compliance/audit экспортом: +2 недели
• Security audit: +3–6 недель
• Итого production-ready: 4–5 месяцев

Отметим: что входит:

• Набор смарт-контрактов Safe Modules
• Backend (API Policy Engine + Workflow Engine)
• Frontend-панель управления
• Интеграция с HSM (AWS/Thales/Utils)
• Аудит-логи и экспорт
• Документация и обучение
• Поддержка после запуска (2 месяца)

Стоимость рассчитывается индивидуально после аудита требований. Экономия от внедрения multi-approval может достигать $500k в год при объёме транзакций от $10M, что подтверждается опытом наших проектов.

Закажите внедрение multi-approval системы сегодня. Получите консультацию — оценим риски вашего текущего решения и предложим архитектуру. Защитите активы с multi-approval системой, проверенной на 20+ проектах.

По данным Wikipedia, multisig используется для повышения безопасности криптовалютных кошельков.

Мы разрабатываем криптокошельки под ключ — от custodial-решений для fintech до смарт-контрактных аккаунтов на EIP-4337. 5+ лет на рынке блокчейн-разработки, 40+ реализованных проектов. Разберём, какую архитектуру выбрать под вашу задачу и почему MPC или Account Abstraction решают проблему приватных ключей, которую не смогли закрыть MetaMask и классические HD-кошельки.

Почему классические кошельки опасны для бизнеса?

Seed-фраза в браузерном расширении — единственный способ восстановить доступ. Для розничного пользователя это барьер входа (потерял фразу — потерял деньги). Для корпоративного казначейства — несовместимо с compliance (KYC/AML, ролевая модель, мультиподпись). Любая утечка одного ключа компрометирует все средства. Эти риски заложены в архитектуру, а не в плохой UX.

Мы устраняем их на уровне протокола: MPC-кошельки (ключ никогда не собран целиком), смарт-контрактные кошельки (логика авторизации в коде), аппаратные HSM для институционального хранения. Ниже — детали.

Custodial vs Non-custodial: в чём реальная разница

Custodial — провайдер хранит приватный ключ. Пользователь аутентифицируется через email/password/OAuth. Восстановление тривиально, KYC/AML встроены. Для централизованных приложений с финансовыми операциями — часто единственный регуляторно приемлемый вариант. Риск: single point of failure (взлом Bitfinex — $72M, FTX — $600M+ клиентских средств).

Non-custodial — ключи у пользователя. Провайдер не имеет доступа к средствам. Ответственность за хранение ложится на пользователя. Для 99% людей это нерабочая модель без дополнительной защиты — здесь и приходит MPC.

MPC-кошельки: ключ, которого нет

Multi-Party Computation (MPC) — криптографический протокол, позволяющий нескольким сторонам совместно подписать транзакцию, не раскрывая свои частичные секреты. Приватный ключ никогда не существует в собранном виде.

Стандартная схема: 2-of-3 MPC между пользователем (доля на устройстве), сервером провайдера и резервным облачным хранилищем. Транзакция подписывается двумя любыми из трёх сторон. Телефон потерян — восстановление через сервер + облако. Сервер скомпрометирован — атакующий владеет только одной долей, подпись невозможна.

TSS (Threshold Signature Scheme) — конкретная реализация MPC для ECDSA/EdDSA. Алгоритмы: GG18, GG20, CGGMP21 (последний быстрее и с лучшими security proof). Библиотеки: tss-lib (Go, от Binance), multi-party-sig (Go, от Coinbase), ZenGo-X/multi-party-ecdsa (Rust).

MPC не требует on-chain изменений — для блокчейна подпись выглядит как обычная single-key подпись. Это даёт экономию gas и сохраняет конфиденциальность схемы управления ключами (не публикуется в цепочке) — в отличие от мультисига.

Account Abstraction (EIP-4337): смарт-контракт как кошелёк

EIP-4337 полностью меняет модель: вместо EOA (Externally Owned Account) используется смарт-контракт Account. Логика авторизации — в коде контракта, не в криптографии протокола. Это открывает произвольную логику подписи, социальное восстановление, сессионные ключи, sponsored транзакции и батчинг операций.

Как работает стек EIP-4337:

User → UserOperation → Bundler → EntryPoint contract → Account contract
                                          ↑
                                    Paymaster (optional, pays gas)

UserOperation — новый тип объекта (не L1-транзакция). Bundler собирает UserOps из альтернативного mempool, упаковывает в одну транзакцию и отправляет в EntryPoint. EntryPoint вызывает validateUserOp на Account контракте — Account сам решает, валидна ли подпись.

Практические возможности:

Социальное восстановление. Контракт хранит список guardian'ов (другие адреса или сервис). Потеря ключа — guardians голосуют за замену. Argent использует схему с 2020 года.

Сессионные ключи. Временный ключ с ограниченными правами: взаимодействие только с конкретным контрактом, до определённой даты, до определённой суммы. Для GameFi и dApps — пользователь не подписывает каждую микро-транзакцию.

Paymaster. Сторонний контракт платит газ за пользователя. Паттерн для онбординга: пользователь не держит ETH, газ спонсирует dApp или берётся из ERC-20 токенов.

Реализации: Safe{Core} Protocol, Biconomy SDK (Stackup), ZeroDev (Kernel), Alchemy (Rundler bundler). На Ethereum mainnet, Polygon, Arbitrum, Optimism EntryPoint v0.6/v0.7 задеплоен и активен. Гарантируем совместимость с последними версиями контрактов.

Hardware Security Module для корпоративных кошельков

Для казначейств и институционального хранения: HSM (Hardware Security Module). Ключ генерируется и никогда не покидает защищённый чип. Подпись — внутри HSM. Поддерживается аппаратная аттестация. Используемые решения: AWS CloudHSM, Azure Dedicated HSM, Thales Luna, YubiHSM 2 (для небольших объёмов). Интеграция через PKCS#11 или cloud-specific API.

Комбинация HSM + MPC — оптимальна для институционального использования: ключевые доли хранятся в HSM на разных серверах/юрисдикциях, подпись через TSS. Это обеспечивает соответствие регуляторным требованиям (например, для крипто-кастодианов).

Интеграция с dApps: WalletConnect и стандарты

Любой кошелёк должен уметь взаимодействовать с dApps. Стандарт — WalletConnect v2 (Sign API): QR-код или deep link, peer-to-peer зашифрованный канал через relay сервер. Для браузерных расширений — EIP-1193 (Ethereum Provider API).

На фронтенде используем wagmi + viem — один интерфейс для MetaMask, WalletConnect, Coinbase Wallet, injected providers. Для Account Abstraction — EIP-5792 (wallet capabilities) и EIP-7677 (paymaster service).

Процесс разработки

1. Threat model — кто пользователь (B2C, B2B, institutional), какие операции, каков допустимый risk model. От этого зависит архитектура.
2. Выбор и проектирование схемы хранения ключей — MPC, HSM, мультисиг или их комбинация.
3. Разработка Account контракта (если EIP-4337) или интеграция MPC-библиотеки.
4. Backend — MPC-координация, управление сессиями, paymaster-сервис (если нужен).
5. Мобильное/браузерное приложение — UI с интеграцией WalletConnect, биометрии, QR.
6. Интеграция с dApps — EIP-1193, WalletConnect v2.
7. Аудит контрактов и криптографических реализаций — обязательный этап. MPC-библиотеки имеют известные уязвимости (GG18 подвержен атаке при malicious participant без abort protocol). Используем библиотеки с актуальными security review (CGGMP21). Опыт прохождения аудитов у Certik, Hacken, Trail of Bits — подтверждаем сертификатами.

Что входит в работу (deliverables)

• Исходные коды смарт-контрактов (Solidity/Rust) с документацией
• Backend-сервис MPC-координации (на Go или Rust) с API
• Мобильное приложение (iOS/Android) или браузерное расширение
• Интеграция с WalletConnect, Ledger/Trezor (по необходимости)
• Подготовка к аудиту безопасности (отчёт со списком уязвимостей)
• Документация администратора и пользователя
• Доступ к репозиторию, CI/CD, мониторинг (Tenderly, Etherscan API)
• Обучение вашей команды (2-3 сессии)
• Поддержка после запуска — 1 месяц

Сроки и стоимость

Стоимость рассчитывается индивидуально под ваш проект. Оценим за 1 день — напишите на почту или в Telegram. Предоставляем гарантию на код и timeline.

Типичные ошибки при разработке криптокошельков (и как их избежать)

• Использование устаревших MPC-библиотек — GG18 без abort protocol. Выбираем CGGMP21 или tss-lib с актуальными audit report.
• Жёсткая привязка к одному блокчейну — не закладывают абстракцию под L2/сайдчейны. Используем viem/wagmi для кросс-чейн.
• Игнорирование MEV-атак — при использовании мультисига без таймлоков. Добавляем tx simulation (Tenderly) и sandwitching protection.
• Отсутствие fallback-механизма восстановления — для Account Abstraction не настраивают social recovery. Закладываем с первого релиза.

Устраняем эти грабли на этапе проектирования — под каждый проект составляем threat model и security checklist.

Нужен надёжный кошелёк без компромиссов? Получите консультацию нашего архитектора — разберём вашу задачу и предложим архитектуру с точной сметой. Оставляйте заявку — ответим в течение дня.