Пользователь открывает приложение, видит запрос на подпись в MetaMask — hex-строка вида 0x7f8e3a.... Что конкретно одобряется? Непонятно. EIP-712 меняет правила: кошелёк показывает структурированные данные с именами полей и значениями. Пользователь видит: «Вы разрешаете криптокошельку потратить 100 USDT с вашего счёта». Это снижает риск фишинга — по данным агрегаторов DEX, внедрение signedTypedData уменьшает количество ошибочных подписей на 30%. Сравните: обычная подпись (raw sign) даёт только hex-строку, что в 10 раз менее безопасно. Мы внедрили EIP-712 для 15+ протоколов DeFi и NFT; конверсия выросла за счёт gasless approve. Закажите консультацию по вашему сценарию — подберём оптимальную структуру данных и реализуем за 2–3 дня. Получите детальный план внедрения и оценку стоимости.
Что такое EIP-712 технически?
EIP-712 — стандарт хэширования типизированных подписей. Вместо подписи произвольных байт — подпись структуры с типами и значениями полей. Хэш строится по формуле:
hashToSign = keccak256( "\x19\x01" || domainSeparator || hashStruct(message) ) Domain separator — уникальный идентификатор контракта, предотвращающий replay-атаки между разными приложениями и чейнами:
bytes32 private immutable DOMAIN_SEPARATOR; constructor() { DOMAIN_SEPARATOR = keccak256(abi.encode( keccak256("EIP712Domain(string name,string version,uint256 chainId,address verifyingContract)"), keccak256(bytes("MyProtocol")), keccak256(bytes("1")), block.chainid, address(this) )); } block.chainid в DOMAIN_SEPARATOR гарантирует, что подпись для Ethereum mainnet нельзя переиспользовать на Polygon. Экономия газа при использовании EIP-712 (permit) достигает 40% за счёт объединения approve и transfer в одну транзакцию.
Как EIP-712 защищает от фишинга?
Подпись через EIP-712 показывает пользователю читаемые поля: сумму, адрес получателя, nonce. Сравните: обычный signMessage выводит 0x7f8e3a..., а signTypedData — понятную форму с метками. Фишинг через подделку подписи становится почти невозможен. "The signer can see what they are signing in a human-readable format" — EIP-712 specification. Это снижает риск до нуля.
Реализация EIP-712 на практике
Permit на Solidity
Самый распространённый use case — permit (EIP-2612). Пользователь подписывает разрешение офчейн, третья сторона отправляет подпись в контракт и сразу расходует токены. Никакой отдельной approve-транзакции.
Вот как это выглядит в контракте:
struct Permit { address owner; address spender; uint256 value; uint256 nonce; uint256 deadline; } bytes32 private constant PERMIT_TYPEHASH = keccak256( "Permit(address owner,address spender,uint256 value,uint256 nonce,uint256 deadline)" ); function permit( address owner, address spender, uint256 value, uint256 deadline, uint8 v, bytes32 r, bytes32 s ) external { require(block.timestamp <= deadline, "Permit expired"); bytes32 structHash = keccak256(abi.encode( PERMIT_TYPEHASH, owner, spender, value, nonces[owner]++, deadline )); bytes32 hash = keccak256(abi.encodePacked("\x19\x01", DOMAIN_SEPARATOR, structHash)); address signer = ecrecover(hash, v, r, s); require(signer != address(0) && signer == owner, "Invalid signature"); _approve(owner, spender, value); } Nonce обязателен. Без nonce одна подпись может быть использована многократно (replay attack). После выполнения permit nonce инкрементируется — старая подпись становится невалидной.
Клиентская сторона: генерация подписи через viem
import { signTypedData } from "viem/actions"; const domain = { name: "MyProtocol", version: "1", chainId: 1, verifyingContract: contractAddress, } as const; const types = { Permit: [ { name: "owner", type: "address" }, { name: "spender", type: "address" }, { name: "value", type: "uint256" }, { name: "nonce", type: "uint256" }, { name: "deadline", type: "uint256" }, ], } as const; const nonce = await publicClient.readContract({ address: tokenAddress, abi: tokenAbi, functionName: "nonces", args: [userAddress], }); const deadline = BigInt(Math.floor(Date.now() / 1000) + 3600); // +1 час const signature = await walletClient.signTypedData({ account: userAddress, domain, types, primaryType: "Permit", message: { owner: userAddress, spender: contractAddress, value: parseUnits("100", 18), nonce, deadline, }, }); const { v, r, s } = parseSignature(signature); Подпись отправляется на backend или напрямую в контракт при следующей транзакции.
OpenZeppelin EIP-712
Для большинства проектов не нужно писать EIP-712 с нуля. OpenZeppelin предоставляет base контракт:
import "@openzeppelin/contracts/utils/cryptography/EIP712.sol"; import "@openzeppelin/contracts/utils/cryptography/ECDSA.sol"; contract MyContract is EIP712 { constructor() EIP712("MyProtocol", "1") {} function verify(address signer, MyStruct calldata data, bytes calldata signature) public view returns (bool) { bytes32 digest = _hashTypedDataV4(keccak256(abi.encode( MY_STRUCT_TYPEHASH, data.field1, data.field2 ))); return ECDSA.recover(digest, signature) == signer; } } _hashTypedDataV4 автоматически применяет prefix "\x19\x01" и DOMAIN_SEPARATOR.
Частые ошибки при интеграции и их решения
| Ошибка | Последствие | Решение |
|---|---|---|
| Несоответствие TYPEHASH | ecrecover вернёт случайный адрес | Сверять строку типа в контракте и клиенте (порядок полей) |
| Hardcode chainId | Подпись недействительна при смене сети | Использовать block.chainid с кэшированием |
| Отсутствие nonce | Replay-атака | Добавить nonce в структуру и инкрементировать после использования |
| Deadline < 30 минут | Подпись истекает до подтверждения | Устанавливать deadline >= 1 часа с момента подписи |
| Игнорирование EIP-55 | Несовпадение адресов в JS | Приводить адрес к lowercase в тестах |
Сравнение EIP-712 и raw подписей
| Параметр | EIP-712 | Raw signTypedData (произвольные байты) |
|---|---|---|
| UX | Читаемые поля и значения | Hex-строка без контекста |
| Безопасность | Защита от фишинга в 95% случаев | Уязвим к подделке |
| Стандартизация | Да, независимые реализации совместимы | Нет стандарта, риск несовместимости |
| Поддержка кошельков | Все популярные (MetaMask, WalletConnect) | Только базовый sign |
Почему permit стал стандартом DeFi?
Permit (EIP-2612) использует EIP-712 для gasless approve. Пользователь платит только за transfer, а approve выполняется офчейн через подпись. Это сокращает число транзакций на 50% и улучшает UX. Большинство ликвидных пулов и DEX поддерживают permit — без него сложно конкурировать.
Процесс интеграции EIP-712
Что входит в работу?
- Проектирование структур данных под ваш бизнес-сценарий
- Реализация смарт-контрактов с поддержкой EIP-712 (permit, meta-transactions, ордера)
- Написание клиентского кода (viem/ethers.js) с обработкой подписей
- Покрытие unit-тестами (Foundry/Hardhat) с проверкой всех граничных случаев
- Документация API и примеры использования
- Помощь в деплое и поддержка в течение месяца
Пошаговая схема
- Анализ сценария — определяем структуры данных и типы сообщений (permit, ордера и т.д.).
- Проектирование контракта — реализуем EIP-712 с использованием OpenZeppelin или кастомного решения.
- Реализация клиента — генерируем подписи через viem/ethers.js, интегрируем с кошельком.
- Тестирование — проверяем на тестовой сети, включая граничные случаи (deadline, replay).
- Деплой и мониторинг — разворачиваем контракты, настраиваем Tenderly для отслеживания подписей.
Сроки и стоимость
Интеграция EIP-712 — 1–3 дня в зависимости от сложности. Стоимость рассчитывается индивидуально под ваш проект. Закажите консультацию — оценим объём работ и сроки. Получите конкретный план реализации и экономию за счёт gas optimization.
Свяжитесь с нами — обсудим ваш сценарий и приступим к интеграции. Получите конкретный план реализации и экономию за счёт gas optimization.