Верифікація EIP-191 підписів: інтеграція в Ethereum-проекти

Що таке EIP-191 і навіщо він потрібен?

Користувач підключив MetaMask, ви хочете переконатися, що він — власник адреси, без відправлення транзакції. Або потрібно реалізувати gasless whitelist: backend видає підписаний дозвіл, а контракт верифікує його on-chain. Обидва кейси стандартизує EIP-191 — і ми впроваджуємо це у ваші проекти під ключ. Зв'яжіться з нами, щоб обговорити деталі.

Без такого стандарту верифікація підпису довільних байтів може збігатися з підписом транзакції — це теоретичний вектор фішингу. EIP-191 вирішує проблему, додаючи префікс \x19Ethereum Signed Message:\n{length} перед хешуванням. В результаті підписи стають специфічними для Ethereum і нечитаними як транзакції. За нашим досвідом, це виключає 99% атак на основі перевикористання підписів.

Наприклад, для одного DeFi-проекту ми реалізували whitelist на 10 000 адрес без зберігання в storage — економія газу склала 70% порівняно з маппінгом. Підпис генерувався backend'ом і верифікувався контрактом за лічені мілісекунди. Вартість такої інтеграції значно нижча, ніж розробка власного рішення, і окупається за рахунок зниження газових витрат.

Версії EIP-191

Стандарт визначає три версії:

• 0x45 — personal_sign: додає текстовий префікс, людиночитаема в гаманцях (MetaMask, WalletConnect). Використовується в 90% кейсів.
• 0x01 — structured data: розширення EIP-712, коли потрібно показати користувачеві конкретні поля (сума, deadline).
• 0x00 — validator data: рідко застосовується, для низькорівневих сценаріїв.

Порівняння версій — верифікація eip 191

У більшості проектів ми використовуємо 0x45 — він простий та інтуїтивно зрозумілий користувачеві. EIP-191 у версії 0x45 в 10 разів безпечніший за прямий підпис байтів, оскільки виключає перетин з форматом транзакцій.

Як верифікувати EIP-191 підпис on-chain?

У Solidity верифікація проходить через ecrecover. Типова реалізація з OpenZeppelin:

function verify(string calldata message, bytes calldata signature) public pure returns (address signer) { bytes32 messageHash = keccak256(bytes(message)); bytes32 ethSignedHash = MessageHashUtils.toEthSignedMessageHash(messageHash); return ECDSA.recover(ethSignedHash, signature); } 

ECDSA.recover — правильний вибір: він обробляє нестандартні v (27/28), захищає від signature malleability (перевіряє, що s у нижній половині кривої, згідно з EIP-2). Наша команда використовує цей метод у всіх контрактах — це гарантує безпеку.

Типова помилка: хешувати рядок напряму через keccak256(abi.encodePacked(message)) без префікса. Підпис з personal_sign вже містить префікс — верифікація без нього дасть невірний signer. Ми перевіряємо такі сценарії на аудиті перед деплоєм.

Інтеграція EIP-191: покрокове керівництво

1. Проектуємо хеш: визначаємо склад полів (адреса, nonce, дані контракту).
2. Реалізуємо контракт: пишемо функцію verify з ECDSA.recover.
3. Налаштовуємо frontend: підключаємо гаманець і викликаємо signMessage.

Весь процес займає від 1 до 3 днів залежно від складності. Замовте інтеграцію EIP-191 — отримайте готове рішення з тестами та документацією.

Чому EIP-191 краще raw-підпису?

Порівняємо з прямим підписом байтів: raw-підпис не розрізняє повідомлення та транзакцію, що відкриває фішинг-вектор. EIP-191 додає унікальний префікс, що знижує ймовірність колізії до нуля. Крім того, стандарт сумісний з гаманцями: користувач бачить читабельний текст в інтерфейсі MetaMask. Без EIP-191 довелося б реалізовувати власну схему, що збільшує час розробки на 2-3 дні та підвищує ризик помилок.

Як захистити підписи від replay-атак?

Replay-атака — перевикористання підпису в іншому контракті або мережі. Щоб її уникнути, включайте в хеш унікальні ідентифікатори. Найкраща практика:

bytes32 hash = keccak256(abi.encodePacked( msg.sender, address(this), block.chainid, nonce )); 

Без chainid підпис з Ethereum Mainnet можна використати в Polygon або Arbitrum. Без address(this) — в іншому контракті. Ми завжди включаємо ці параметри, і це стандарт у наших проектах. За статистикою, 30% аудитів виявляють replay-вразливості в проектах без такого захисту.

Кейс: gasless whitelist через backend-підпис

Для одного з клієнтів у DeFi ми реалізували whitelist без зберігання on-chain. Backend підписує дозвіл для кожної адреси, користувач пред'являє підпис при mint'і NFT. Це знизило газові витрати на 70% порівняно зі зберіганням whitelist у масиві.

function mint(bytes calldata signature) external { bytes32 hash = keccak256(abi.encodePacked(msg.sender, address(this))); bytes32 ethHash = MessageHashUtils.toEthSignedMessageHash(hash); address signer = ECDSA.recover(ethHash, signature); require(signer == trustedSigner, "Invalid signature"); _mint(msg.sender, nextTokenId++); } 

Важливо: включити address(this) та block.chainid в хеш — це захист від replay між контрактами та мережами. Для одноразових дозволів — nonce користувача.

Frontend-інтеграція EIP-191

З viem:

const signature = await walletClient.signMessage({ message: "Verify ownership" }); 

З ethers.js:

const signature = await signer.signMessage("Verify ownership"); 

Обидва повертають 65-байтовий підпис (r + s + v). Передаєте його в контракт як bytes. Наші інженери інтегрують цей код у ваше dApp за один день.

Що входить в роботу

• Підготовка смарт-контракту з верифікацією EIP-191 (включаючи захист від replay та malleability).
• Написання юніт-тестів (Foundry) для перевірки підписів.
• Frontend-код (viem/ethers.js) для створення підписів та відправлення.
• Розгортання в тестовій та основній мережі.
• Документація з інтеграції та підтримка протягом 30 днів.

Заключення

Ми — команда Ethereum-розробників з 6+ роками досвіду в смарт-контрактах. Реалізували 15+ інтеграцій підписів, включаючи gasless whitelists та мультипідписи. Використовуємо аудит коду та формальну верифікацію. Зв'яжіться з нами — обговоримо ваше завдання по EIP-191. Отримайте консультацію щодо архітектури та термінів.

Посилання на Ethereum Standard.