Социальная аутентификация в dApp с Web3Auth: повышение конверсии

Вместо того чтобы заставлять пользователя сохранять seed phrase или скачивать MetaMask, вы даёте ему вход через Google, Apple или email. Это не просто удобство — это конверсия. Потенциальная аудитория вашего dApp в десять раз шире, если убрать барьер установки расширения. Мы используем Web3Auth, чтобы решить эту задачу без компромиссов в безопасности. По нашим оценкам, Web3Auth увеличивает конверсию онбординга в 3-5 раз по сравнению с ручным вводом seed phrase.

Под капотом — пороговая криптография (MPC/TSS). При регистрации генерируется ключевая пара, приватный ключ разделяется на три shares: один хранится у нод Web3Auth (tKey), второй — локально в браузере (deviceShare), третий — опциональный backup (например, пароль). Для подписи транзакции нужны минимум два shares из трёх. Web3Auth никогда не имеет полного ключа. Даже если атакующий скомпрометирует их инфраструктуру, он не получит доступ к пользовательским средствам.

Как пороговая криптография защищает пользователей?

В отличие от seed phrase, который хранится в одном месте и может быть украден, MPC распределяет доверие. Каждый share изолирован, а порог (2 из 3) означает, что компрометация одного узла не даёт доступа к ключу. Это стандарт безопасности, используемый в банковских системах. Как указано в документации Web3Auth, пороговая криптография исключает единую точку отказа.

Как работает восстановление доступа?

Пользователь потерял устройство — не проблема. Он заходит через тот же OAuth-провайдер, и система восстанавливает backup share (если был настроен) или генерирует новый deviceShare при подтверждении через второй фактор (пароль от backup). Это гибрид self-custody и managed wallet: вы сохраняете контроль над ключами, но юзеру не нужно ничего помнить.

Почему стоит выбрать Web3Auth для dApp?

Web3Auth возвращает стандартный EIP-1193 provider — это значит, что ваш существующий код на ethers.js, viem или wagmi работает без изменений. Вы просто подменяете window.ethereum на provider от Web3Auth. Весь стек (signTypedData, отправка ETH, взаимодействие с контрактами) остаётся прежним. Никакого vendor lock-in: в любой момент вы можете переключиться на другую абстракцию ключей.

Сравнение Modal и NoModal SDK

Процесс интеграции

1. Анализ — определяем целевую аудиторию, список OAuth-провайдеров, требования к white-label и кастомизации UI. Выбираем версию SDK: Modal (готовый UI) или NoModal (только логика).

2. Проектирование — проектируем поток аутентификации: регистрация, логин, восстановление, отзыв сессий. Определяем backup-механизмы (пароль, социальный backup). Интегрируем с вашей бэкенд-авторизацией (JWT-токены, сессии).

3. Реализация — настраиваем Web3Auth Dashboard, получаем clientId. Подключаем SDK, реализуем вызовы login/logout. Пример кода ниже — базовая интеграция с модалом:

import { Web3Auth } from '@web3auth/modal'
import { CHAIN_NAMESPACES } from '@web3auth/base'

const web3auth = new Web3Auth({
  clientId: 'YOUR_CLIENT_ID',
  chainConfig: {
    chainNamespace: CHAIN_NAMESPACES.EIP155,
    chainId: '0x1',
    rpcTarget: 'https://rpc.ankr.com/eth'
  }
})

await web3auth.initModal()

// Вход — модал с Google/Twitter/Email/Apple
const provider = await web3auth.connect()

// Далее используем как обычный EIP-1193 provider
const ethersProvider = new ethers.BrowserProvider(provider)
const signer = await ethersProvider.getSigner()

4. White-label и кастомизация — для production обычно нужен собственный бренд. Используем NoModal SDK:

import { Web3AuthNoModal } from '@web3auth/no-modal'
import { OpenloginAdapter } from '@web3auth/openlogin-adapter'

const web3auth = new Web3AuthNoModal({ clientId, chainConfig })

const openloginAdapter = new OpenloginAdapter({
  adapterSettings: {
    uxMode: 'redirect',
    whiteLabel: {
      appName: 'My App',
      logoLight: 'https://example.com/logo.png',
      defaultLanguage: 'ru'
    }
  }
})

web3auth.configureAdapter(openloginAdapter)
await web3auth.init()

// Вызов конкретного провайдера
await web3auth.connectTo('openlogin', { loginProvider: 'google' })

5. Тестирование — проверяем все сценарии: первый вход, повторный, потеря устройства, отзыв доступа. Используем testnet (Goerli, Sepolia). Проверяем latency подписания транзакций — MPC добавляет ~100-300 мс, что незаметно для пользователя.

6. Деплой на mainnet — меняем RPC, обновляем clientId для прода, включаем backup-механизмы. Настраиваем мониторинг через Tenderly.

Что входит в работу

• Подбор конфигурации Web3Auth (количество shares, порог, backup)
• Настройка OAuth-провайдеров (Google, Apple, Twitter, Discord, GitHub)
• Реализация UI: готовый модал или полностью кастомный интерфейс
• Интеграция с существующей системой авторизации (JWT, сессии)
• Код на TypeScript/React/Vue с поддержкой ethers.js, viem, wagmi
• Документация по администрированию Web3Auth Dashboard
• Тестирование безопасных сценариев (восстановление, отзыв ключей)
• Гарантия: поддерживаем код в течение 3 месяцев после интеграции

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

Стоимость рассчитывается индивидуально — зависит от сложности UI, количества провайдеров и требований к безопасности. Оценку проекта делаем за 1 день: присылайте описание dApp и целевую аудиторию. Получите консультацию инженера, который реализовал Web3Auth в 12+ dApp, включая DeFi-платформы и NFT-маркетплейсы. Наш опыт — 5 лет в Web3, 30+ успешных интеграций. Гарантируем стабильную работу на mainnet и поддержку новых стандартов (ERC-4337, EIP-3074).

Хотите убрать барьер входа для пользователей? Свяжитесь с нами — оценим проект и предложим архитектуру под ключ.

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

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