Пользователь вводит vitalik.eth в поле адреса, а приложение не может преобразовать имя — знакомая ситуация? ENS-резолвер решает эту задачу, но его настройка требует внимания к деталям: нормализация имён, кэширование RPC-запросов, обработка отсутствующих reverse record. Мы настраиваем ENS-резолвер под ключ с использованием современного стека viem/wagmi. Опыт 5+ лет в web3, более десятка dApp с ENS — гарантируем стабильную работу. Закажите интеграцию ENS-резолвера в ваше dApp.
Какие проблемы решаем
Невалидные ENS-имена. Пользователь может ввести vItalik.eth или sub.vitalik.eth с Unicode-символами. Без нормализации (UTS-46) такие имена либо не резолвятся, либо возвращают неверный адрес. Мы применяем normalize() из viem/ens на каждом вводе.
Reverse lookup без обратной записи. Если владелец адреса не установил reverse record, хуки useEnsName возвращают null. В результате интерфейс показывает пустое имя вместо адреса. Мы реализуем fallback: отображаем сокращённый адрес (0x12...34) и предлагаем пользователю зарегистрировать ENS.
Затраты газа и время ожидания. Каждый запрос к mainnet RPC стоит около 5000 gas и занимает 2–5 секунд. Без кэширования dApp может тормозить. Wagmi автоматически кэширует результаты через React Query, но мы дополнительно настраиваем TTL и retry для стабильности.
Как работает ENS-резолвер?
ENS — это децентрализованная система имён на Ethereum mainnet. Преобразование происходит через контракт ENS Registry. В dApp мы используем готовые хуки useEnsAddress (forward) и useEnsName (reverse) из wagmi v2:
import { useEnsAddress, useEnsName, useEnsAvatar } from 'wagmi'; // Forward: имя → адрес const { data: address } = useEnsAddress({ name: 'vitalik.eth', chainId: 1, // только mainnet }); // Reverse: адрес → имя const { data: ensName } = useEnsName({ address: '0xd8dA6BF26964aF9D7eEd9e03E53415D37aA96045', chainId: 1, }); // Аватар const { data: avatar } = useEnsAvatar({ name: 'vitalik.eth', chainId: 1, }); ENS работает только на Ethereum mainnet (и Sepolia для тестирования). Для кроссчейн-резолвинга существуют решения на основе EIP-3668 (CCIP-Read), которые мы внедряем для мультичейн dApp.
Пошаговая интеграция ENS-резолвера
- Подключите библиотеки. Установите
wagmiиviemчерез npm или yarn. - Настройте клиент. Используйте конфиг Wagmi с провайдером mainnet.
- Внедрите хуки. Замените поля ввода адреса на компоненты с
useEnsAddressиuseEnsName. - Нормализуйте ввод. Применяйте
normalize()изviem/ensперед любым запросом. - Настройте кэширование. Укажите
staleTimeиgcTimeв опциях хуков wagmi для оптимального использования RPC. - Добавьте fallback. Если reverse lookup вернул null, отображайте сокращённый адрес и кнопку «Задать ENS-имя».
Почему важно нормализовать ENS-имена?
normalize() из viem/ens приводит строку к стандарту UTS-46, корректируя регистр и Unicode-символы. Без неё имена типа vItAlik.eth могут вернуть другой адрес или бросить исключение. Также проверяйте длину: максимальная длина ENS-имени — 128 байт в закодированном виде.
Сравнение viem и ethers.js для ENS
| Параметр | viem (wagmi) | ethers.js |
|---|---|---|
| Размер бандла | ~20 kB (tree-shakeable) | ~150 kB |
| Поддержка ENS | Встроенные хуки useEnsAddress, useEnsName |
Через Resolver + ручное кэширование |
| Производительность | В 2–3 раза быстрее за счёт компактного ABI | Тяжелее из-за полного JSON ABI |
| Кэширование | Автоматическое (React Query) | Требует ручной реализации |
| Типизация | TypeScript-first, полная типизация | Partial типизация |
viem выигрывает по производительности и удобству — для новых проектов рекомендуем именно этот стек.
Что входит в работу по настройке ENS-резолвера
| Этап | Детали | Срок (дней) |
|---|---|---|
| Анализ | Требования к резолвингу, выбор библиотеки | 1–2 |
| Проектирование | Архитектура, обработка ошибок, кэширование | 2–3 |
| Реализация | Интеграция хуков, валидация, нормализация | 3–5 |
| Тестирование | Unit-тесты, симуляция RPC failure, E2E | 2–3 |
| Деплой | Настройка mainnet, документация | 1–2 |
Входит: кодовая база (TypeScript), документация API, инструкция по тестированию, первичная настройка мониторинга (Tenderly). Поддержка 1 месяц после сдачи. Стоимость рассчитывается индивидуально. Получите консультацию по вашему проекту.
Типичные ошибки и как их избежать
- Забыли
normalize()— имена с Unicode-символами падают. Решение: всегда применяйтеviem/ensnormalize. - Не настроили таймаут — запрос к mainnet может зависнуть на 30+ секунд. Решение:
publicClient.getEnsAddress({ ... })сtimeout: 10000. - Игнорируете subdomains —
vitalik.ethработает, аsub.vitalik.eth— нет. Решение: проверяйте имя черезnormalize()и используйтеgetEnsAddressс полной структурой. - Reverse без fallback — пустой интерфейс вместо адреса. Решение: всегда показывайте сокращённый адрес при отсутствии ENS.
Почему стоит выбрать наш подход?
Мы внедрили ENS в 12 dApp для DeFi и NFT-проектов. Используем формальную верификацию контрактов (Slither + Mythril) и оптимизацию газа. Гарантируем, что резолвер не будет блокировать UX — время ответа менее 3 секунд при стабильном RPC. Закажите интеграцию ENS-резолвера в ваше dApp — свяжитесь для консультации.