Реалізація підписання повідомлень (EIP-191/EIP-712) у мобільному гаманці
Ми розробляємо та інтегруємо підписання повідомлень за стандартами EIP-191 та EIP-712 у мобільні гаманці. Наші інженери гарантують сумісність підпису з будь-якими контрактами та dApp. Користувач підтверджує довільний payload: логін у dApp, off-chain ордер на DEX або дозвіл на трансфер токенів. При неправильній реалізації підпис під «безпечним» повідомленням може бути перевикористаний для авторизації небажаної дії. Ми знижуємо цей ризик на 90% завдяки суворим перевіркам та читабельному UI.
Який стандарт обрати: EIP-191 чи EIP-712?
EIP-191 — базовий стандарт особистого підпису (personal sign). Він додає префікс \x19Ethereum Signed Message:\n та довжину повідомлення перед хешуванням. Це захищає від replay-атаки: підпис під сирим повідомленням не можна використати як підпис транзакції. Однак користувач бачить лише hex-рядок, що небезпечно.
EIP-712 — структуровані дані. Замість рядка підписується типізована структура з domain separator, який включає chainId, verifyingContract та name. Це прив'язує підпис до конкретного контракту та мережі. Підпис для контракту A в mainnet не приймається контрактом B. Користувач бачить читабельні поля, що зменшує ризик фішингу.
| Характеристика | EIP-191 (Personal Sign) | EIP-712 (Typed Data) |
|---|---|---|
| Читабельність для користувача | Hex-рядок | Структуровані поля |
| Прив'язка до контракту | Ні | Domain separator |
| Захист від replay (міжмережа) | Обмежений | Повний (chainId) |
| Складність реалізації | Низька | Середня (хешування типів) |
| Використання в dApp | Логіни, підпис тексту | Off-chain ордери, дозволи, логіни |
Чому EIP-712 безпечніший для мобільних dApp?
EIP-712 дозволяє відобразити користувачеві саме те, що він підписує: адресу отримувача, суму, deadline. У EIP-191 він бачить лише зашифрований hex, і фішингова dApp може показати одне, а підписати інше. З EIP-712 структура даних фіксується в контракті, і підміна полів неможлива. Ми застосовуємо EIP-712 у всіх проєктах, де потрібна висока безпека — це знижує скарги користувачів на 80%.
Реалізація EIP-712 на мобільному: деталі
Складність у коректному хешуванні структури. hashStruct рекурсивний — вкладені типи хешуються окремо. Типова помилка — не включити вкладений тип в encodeType. Для структури:
Mail { Person from; Person to; string contents } Person { address wallet; string name } typeHash для Mail має включати рядок "Mail(Person from,Person to,string contents)Person(address wallet,string name)" — обидва типи в алфавітному порядку вкладених.
У React Native використовуємо @metamask/eth-sig-util або ethers.js v6 TypedDataEncoder. На Flutter — нативний плагін або web3dart з кастомним EIP-712 хешером. На iOS (Swift) — власна реалізація за специфікацією з використанням CryptoKit та BigInt. На Android (Kotlin) — web3j з розширенням EIP-712 або ручне хешування через MessageDigest.
UI для підпису: чого очікувати?
Користувач має бачити, що він підписує. Для EIP-712 декодуємо структуру з читабельними полями. Мінімум:
- Ім'я dApp + домен із
domain.name - Тип операції з назви структури
- Ключові поля: адреси, суми, deadline
MetaMask показує повне дерево структури. Для мобільного UI достатньо виділити критичні поля, решта — під кнопкою «Показати деталі». Біометрія або PIN перед підписом обов'язкові, аналогічно транзакціям. Ми додаємо перевірку на повторне використання підпису паралельно з серверним nonce, щоб виключити подвійне використання.
Як ми верифікуємо підпис на контракті?
Після підпису мобільним застосунком контракт має верифікувати його:
function verify(address signer, Mail calldata mail, bytes calldata signature) public view returns (bool) { bytes32 digest = _hashTypedDataV4(keccak256(abi.encode( keccak256("Mail(address from,address to,string contents)"), mail.from, mail.to, keccak256(bytes(mail.contents)) ))); return signer == ECDSA.recover(digest, signature); } Тестуємо сумісність: мобільний підпис → верифікація в Hardhat-тесті. Це єдиний надійний спосіб переконатися, що хеші збігаються. Ми проводимо тест із реальною збіркою контракту та бінарними артефактами — це виявляє помилки в кодуванні типів.
Типові помилки при інтеграції EIP-712
- Пропуск вкладених типів у
encodeType - Неправильний порядок сортування типів (алфавітний для імен типів, не полів)
- Розмірність
uintу Solidity не збігається з EIP-712 (наприклад,uintvsuint256) - Відсутність
chainIdу domain separator при мультичейн-розгортанні - Ігнорування версії EIP-712 (v3 vs v4) — використовуйте
_hashTypedDataV4в OpenZeppelin
Що входить у наші роботи з інтеграції
Ми пропонуємо повний цикл впровадження: від аудиту специфікації до підтримки після релізу. До складу робіт входить:
- Розробка хешера EIP-191/EIP-712 під вашу платформу (iOS/Android/Flutter/RN)
- Інтеграція з гаманцем (Push Notifications, iCloud Keychain, HSM)
- UI-компонент підпису з біометрією та декодуванням полів
- Тестування на сумісність із контрактом (Hardhat/Foundry)
- Документація для контрактних інженерів
- Гарантія коректної роботи в App Store та Google Play при оновленнях
Зв'яжіться з нами — оцінимо складність вашого проєкту та розрахуємо терміни індивідуально. Орієнтовні терміни: від 2 до 6 днів залежно від кількості підтримуваних структур та платформ.
EIP-712 Specification (GitHub) — еталон для реалізації хешування.