Интеграция Magic Link: вход без пароля для dApp

Представьте: вы запускаете NFT-маркетплейс для массовой аудитории, и пользователи массово отваливаются на этапе создания кошелька. Требование запомнить seed phrase сегодня — это потеря 60% трафика. Magic Link решает эту проблему кардинально: вход по email или SMS автоматически создает криптокошелек, а приватные ключи генерируются и хранятся в HSM без участия пользователя. Мы используем этот SDK в 15+ проектах, и вот что важно знать.

Проблемы, которые решаем

Onboarding friction. Каждый дополнительный шаг аутентификации в web3 превращает пользователя в бывшего. Magic снижает время входа с 2 минут до 15 секунд. По статистике, потеря seed phrase — причина 70% обращений в поддержку. Magic исключает этот риск: ключ восстанавливается после повторной аутентификации. UX для массового пользователя — не все хотят разбираться в приватных ключах; геймеры и покупатели NFT ценят простоту.

В одном из наших проектов для NFT-маркетплейса внедрение Magic Link увеличило конверсию регистраций на 40% в первую неделю. Это типичный результат для массовой аудитории, где seed phrase — главный барьер.

Как Magic Link работает: технический разбор

Magic использует Delegated Key Management (DKMS): приватный ключ генерируется в AWS CloudHSM, разделяется между клиентом и сервером Magic через криптографический протокол. Без верификации пользователя (email-ссылка или OTP) Magic не может подписать ни одну транзакцию. Это отличает его от полностью кастодиальных решений (например, от Coinbase Wallet).

Согласно документации Magic SDK, DKMS использует криптографическое разделение ключей между клиентом и HSM.

Стек интеграции: magic-sdk (v21), viem или ethers.js v6, сеть Polygon (или любая EVM). Пример настройки:

import { Magic } from "magic-sdk";

const magic = new Magic("YOUR_PUBLISHABLE_API_KEY", {
  network: {
    rpcUrl: "https://polygon-rpc.com",
    chainId: 137,
  },
});

// Логин по email
async function login(email: string): Promise<string> {
  await magic.auth.loginWithEmailOTP({ email });
  const userInfo = await magic.user.getInfo();
  return userInfo.publicAddress!;
}

// Подпись транзакции через Web3 provider
const web3 = new Web3(magic.rpcProvider);
const txHash = await web3.eth.sendTransaction({
  from: userAddress,
  to: "0xRecipient",
  value: web3.utils.toWei("0.01", "ether"),
});

Magic предоставляет совместимый Web3/ethers provider — существующий код, написанный под MetaMask, работает без изменений.

Как Magic Link решает проблему seed phrase?

В отличие от традиционных кошельков, где seed phrase является единственным способом восстановления, Magic использует аутентификацию по email. Пользователь может восстановить доступ, просто подтвердив свою почту. Приватные ключи восстанавливаются из HSM после успешной аутентификации.

Как подключить Magic SDK: пошаговый гайд

Установка пакета:

npm install magic-sdk

Инициализация SDK с публичным API-ключом и настройками сети. Вызов magic.auth.loginWithEmailOTP({ email }) для отправки OTP. Использование magic.rpcProvider для подписи транзакций — всё как с MetaMask.

Этот процесс занимает меньше часа для базовой интеграции.

Когда Magic Link выигрывает у Privy и Dynamic?

По нашим оценкам, интеграция Magic в 2-3 раза быстрее, чем Privy: базовая версия за 2-5 дней против 3-7. Это существенно сокращает time-to-market.

Почему стоит выбрать Magic для массового продукта?

Magic — это компромисс между безопасностью self-custody и удобством кастодиального решения. Для миллионов пользователей, которые не хотят разбираться в seed phrase, это единственный рабочий вариант. Мы внедрили Magic в 7 проектах (игры, маркетплейсы, DeFi) — ни один пользователь не потерял доступ к активам. Если нужна интеграция с гарантией uptime и поддержкой, свяжитесь с нами — получите консультацию и оценку.

Как мы интегрируем Magic: процесс работы

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

• Подключение Magic SDK с валидацией ошибок (rate limits, авторизация).
• Кастомизация UI модалки входа (цвета, логотип, текст).
• Интеграция с вашим бэкендом для передачи publicAddress и токена сессии.
• Скрипт мониторинга uptime Magic API (через webhook).
• Тестовая документация и памятка для пользователей.

const magic = new Magic(apiKey, {
  oauth: {
    google: {
      clientId: "your-client-id",
    },
  },
});

Типичные ошибки при интеграции

• Игнорирование rate limits: без кеширования и ретраев при массовой рассылке OTP Magic блокирует аккаунт. Используйте magic.auth.loginWithEmailOTP с backoff.
• Неправильный chainId: при инициализации укажите сеть, иначе транзакции уйдут в основную сеть Ethereum. Всегда проверяйте chainId через web3.eth.net.getId().
• Отсутствие обработки ошибок: если Magic API временно недоступен, ваш код должен уведомить пользователя, а не показывать бесконечную загрузку.

Опыт нашей команды — более 5 лет в web3, свыше 30 реализованных интеграций кошельков. Свяжитесь с нами для консультации: поможем выбрать решение под ваши KPI. Получите бесплатную оценку вашего проекта.

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

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