Користувач відкриває додаток, бачить запит на підпис у 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.