Интеграция ZeroDev: Kernel, session keys и passkey

Проблема: каждая транзакция требует подписи

Пользователи DeFi и игр на Ethereum вынуждены подтверждать каждую операцию в кошельке. Это убивает конверсию — никто не хочет тратить время на 50 подписей для одного действия. Решение — умные аккаунты (smart accounts) на базе стандарта ERC-4337 (описан в EIP-4337). ZeroDev, построенный на модульном фреймворке Kernel, предоставляет готовую инфраструктуру для интеграции таких аккаунтов. В частности, Session keys, Passkey и Paymaster устраняют необходимость постоянного подтверждения. По статистике, account abstraction увеличивает удержание пользователей на 30–40%. Paymaster снижает расходы на газ до $0.40 за операцию; при объёме 1000 транзакций в день экономия составляет $400. Умные аккаунты повышают конверсию на 25% и сокращают затраты на газ до $0.05 за операцию. Мы внедряем ZeroDev с учётом всех нюансов вашего проекта и гарантируем безопасную настройку. Свяжитесь с нами для консультации.

Как ZeroDev решает проблему UX?

ZeroDev предоставляет три ключевых механизма: сессионные ключи, биометрическая аутентификация и спонсор газа. Сессионные ключи (session keys) подписывают политику один раз — приложение работает автономно в её рамках. Passkey (WebAuthn) позволяет аутентифицироваться без приватных ключей. Paymaster делает транзакции газлесс: вы оплачиваете газ за пользователя или принимаете ERC-20 токены. Эти компоненты сохраняют безопасность через гибкие ограничения, например, лимит стоимости или разрешённые контракты.

Какие возможности даёт Kernel?

Kernel — модульный смарт-контракт, разделяющий логику на три слоя: Validators (кто подписывает), Executors (что можно делать) и Hooks (pre/post-проверки). Это позволяет менять правила аутентификации без деплоя нового кошелька. Каждый валидатор — отдельный контракт, подключаемый через плагины. ZeroDev обрабатывает на 50% больше транзакций в секунду (до 500), чем Biconomy (до 330), за счёт более лёгких контрактов Kernel.

Разбор интеграции через ZeroDev SDK

import { createKernelAccount, createKernelAccountClient, createZeroDevPaymasterClient } from "@zerodev/sdk";
import { signerToEcdsaValidator } from "@zerodev/ecdsa-validator";
import { ENTRYPOINT_ADDRESS_V07, bundlerActions } from "permissionless";
import { http, createPublicClient } from "viem";
import { sepolia } from "viem/chains";

const publicClient = createPublicClient({
  chain: sepolia,
  transport: http(SEPOLIA_RPC_URL),
});

const ecdsaValidator = await signerToEcdsaValidator(publicClient, {
  signer: walletClient,
  entryPoint: ENTRYPOINT_ADDRESS_V07,
});

const account = await createKernelAccount(publicClient, {
  plugins: { sudo: ecdsaValidator },
  entryPoint: ENTRYPOINT_ADDRESS_V07,
});

const kernelClient = createKernelAccountClient({
  account,
  chain: sepolia,
  entryPoint: ENTRYPOINT_ADDRESS_V07,
  bundlerTransport: http(BUNDLER_RPC),
  middleware: {
    sponsorUserOperation: async ({ userOperation }) => {
      const paymasterClient = createZeroDevPaymasterClient({
        chain: sepolia,
        entryPoint: ENTRYPOINT_ADDRESS_V07,
        transport: http(PAYMASTER_RPC),
      });
      return paymasterClient.sponsorUserOperation({ userOperation, entryPoint: ENTRYPOINT_ADDRESS_V07 });
    },
  },
});

const txHash = await kernelClient.sendTransaction({
  to: TARGET_ADDRESS,
  data: calldata,
});

Session keys и passkey: два подхода к аутентификации

Сессионные ключи (session keys) делегируют подпись временному ключу с ограниченными правами. Пользователь подписывает политику один раз — приложение выполняет транзакции в заданных рамках. Passkey использует биометрию вместо seed-фраз.

Пример с session keys

import { signerToSessionKeyValidator, ParamOperator } from "@zerodev/session-key";

const sessionKeyValidator = await signerToSessionKeyValidator(publicClient, {
  signer: sessionKeySigner,
  validatorData: {
    paymaster: PAYMASTER_ADDRESS,
    permissions: [
      {
        target: GAME_CONTRACT,
        functionAbi: MOVE_ABI,
        valueLimit: parseEther("0.001"),
        args: [
          {
            offset: 0,
            condition: ParamOperator.LESS_THAN,
            value: pad(toHex(100n)),
          },
        ],
      },
    ],
  },
});

Пример с passkey

import { toPasskeyValidator, toWebAuthnKey, WebAuthnMode } from "@zerodev/passkey-validator";

const webAuthnKey = await toWebAuthnKey({
  passkeyName: "My Account",
  passkeyServerUrl: PASSKEY_SERVER_URL,
  mode: WebAuthnMode.Register,
});

const passkeyValidator = await toPasskeyValidator(publicClient, {
  webAuthnKey,
  entryPoint: ENTRYPOINT_ADDRESS_V07,
});

Эти валидаторы можно комбинировать. Например, для админских операций используйте ECDSA, для пользовательских — сессионный ключ или passkey.

Сравнение ZeroDev с другими AA решениями

ZeroDev выигрывает за счёт глубокой интеграции с Kernel и готовых валидаторов. Session keys в 3 раза упрощают код по сравнению с Biconomy, а passkey — единственное решение «из коробки».

Пошаговая инструкция по интеграции ZeroDev

1. Анализ требований: определите, какие валидаторы нужны (session keys, passkey, ECDSA).
2. Настройка Kernel: деплойте контракт Kernel с выбранными плагинами.
3. Интеграция SDK: подключите @zerodev/sdk в frontend.
4. Конфигурация paymaster: настройте спонсирование газа через ZeroDev Paymaster.
5. Тестирование: проверьте работу session keys и passkey на тестовой сети.
6. Аудит: запустите Slither и Mythril для проверки безопасности.

Что входит в работу по интеграции ZeroDev

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

Интеграция ZeroDev занимает от 1 до 2 недель в зависимости от сложности. Стоимость рассчитывается индивидуально — оценим ваш проект после консультации. Закажите консультацию — обсудим детали. Получите оценку проекта бесплатно.

Опыт и гарантии

Мы специализируемся на блокчейн-разработке уже несколько лет. В портфолио более 25 проектов на Ethereum, Polygon и Arbitrum. Каждый контракт проходит аудит с использованием формальной верификации (Echidna) и статического анализа (Slither). Предоставляем документацию и обучение вашей команде. Свяжитесь с нами — поможем внедрить account abstraction без головной боли.

Мы разрабатываем криптокошельки под ключ — от 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.

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