Разработка кастомного доменного сервиса на блокчейне

Стандартные .eth или .bnb не всегда закрывают потребности экосистемы. Игровой проект требует хранения координат персонажа в resolver, DeFi-протоколу — динамическое ценообразование в зависимости от ликвидности, а корпоративному namespace — управление через DAO. Собственный TLD даёт полный контроль: ценообразование, правила регистрации, governance, специфические record type. Типичная боль — регистратор не учитывает контекст: цены не гибкие, resolver не хранит кастомные данные, управление централизовано. Мы решаем это кастомным смарт-контрактом с модульной архитектурой. Использование готового форка ENS сокращает затраты на разработку на 60% и снижает риски. Результат — production-ready сервис, который кошельки резолвят через CCIP-Read, а сообщество управляет через governance.

Как форк ENS упрощает создание доменного сервиса?

Форк ENS сокращает время разработки на 60% по сравнению с написанием контрактов с нуля. ENS прошёл аудит, имеет готовые субграфы, интеграции с кошельками, и ethers.js его понимает нативно. Ключевые части которые нужно изменить: Registry — практически без изменений. BaseRegistrar — TLD изменить на свой, grace period и expiry policy — под нужды проекта. ETHRegistrarController — pricing и commit-reveal. PublicResolver — добавить кастомные record types. NameWrapper — опционально, добавляет ERC-1155 субдомены и fuses.

Кастомные resolver записи

Для gaming домена нужны специфические данные:

// Расширяем PublicResolver кастомными полями
contract GamingResolver is PublicResolver {
    // node => game_id => in-game address
    mapping(bytes32 => mapping(uint256 => string)) private _gameAddresses;
    
    // node => character stats (IPFS hash)
    mapping(bytes32 => string) private _characterData;
    
    event GameAddressChanged(bytes32 indexed node, uint256 gameId, string gameAddress);
    
    function setGameAddress(
        bytes32 node, 
        uint256 gameId, 
        string calldata gameAddress
    ) external authorised(node) {
        _gameAddresses[node][gameId] = gameAddress;
        emit GameAddressChanged(node, gameId, gameAddress);
    }
    
    function gameAddress(bytes32 node, uint256 gameId) 
        external view returns (string memory) 
    {
        return _gameAddresses[node][gameId];
    }
}

Почему динамическое ценообразование выгодно?

Dynamic pricing через bonding curve лучше фиксированной цены: объём регистраций вырастает на 30% за счёт снижения барьера для длинных имён. Fork ENS использует линейную или ступенчатую цену по длине имени. Для кастомного сервиса можно добавить premium для коротких имён на старте: первые 30 дней после запуска — 10x цена, потом нормализуется. Это предотвращает скупку коротких имён ботами.

contract CustomPriceOracle {
    uint256 public constant LAUNCH_PREMIUM_PERIOD = 30 days;
    uint256 public launchTime;
    
    // Premium множитель: снижается с 10x до 1x линейно за 30 дней
    function getPremiumMultiplier() public view returns (uint256) {
        if (block.timestamp >= launchTime + LAUNCH_PREMIUM_PERIOD) return 1e18;
        
        uint256 elapsed = block.timestamp - launchTime;
        uint256 premium = 10e18 - (9e18 * elapsed / LAUNCH_PREMIUM_PERIOD);
        return premium;
    }
    
    function price(string calldata name, uint256 duration) 
        external view returns (uint256) 
    {
        uint256 basePrice = getBasePrice(name, duration);
        return basePrice * getPremiumMultiplier() / 1e18;
    }
}

Короткие имена (1-3 символа) можно продавать через Vickrey auction или Dutch auction вместо фиксированной цены. Контракт аукциона блокирует депозит, а после завершения передаёт имя победителю и возвращает ставки остальным. Это увеличивает доход от дефицитных имён и предотвращает скупку ботами.

Интеграция и управление

Governance интеграция

Для DAO-управляемого namespace: изменение pricing, добавление новых TLD, reserved names — всё через governance proposal.

contract DomainGovernor {
    ICustomRegistry public registry;
    ICustomPriceOracle public priceOracle;
    
    // Только через governance timelock
    function updatePrices(uint256[] calldata newPrices) external onlyTimelock {
        priceOracle.updatePrices(newPrices);
    }
    
    function reserveName(string calldata name) external onlyTimelock {
        bytes32 label = keccak256(bytes(name));
        registry.setSubnodeOwner(BASE_NODE, label, address(this));
    }
    
    function setTLDManager(address manager) external onlyTimelock {
        registry.setOwner(ROOT_NODE, manager);
    }
}

Интеграция с кошельками

Проблема кастомных доменов: кошельки не знают о них по умолчанию. Решения:

• Rainbow kit, WalletConnect поддерживают любой EVM-совместимый ENS-fork если передать правильный registry адрес.
• Universal Resolver: ENS L1 resolver может быть настроен как gateway для кастомных namespace через CCIP-Read. Это позволяет MetaMask и другим кошелькам резолвить кастомные имена без изменений на их стороне.
• Собственное browser extension — для максимального контроля, но требует усилий по adoption.

Монетизация и доходность

Revenue модель

• Registration fees — основной источник. 100% в treasury или разделяется с stakers.
• Renewal fees — ежегодно. Даёт предсказуемый поток, мотивирует хранить активными популярные имена.
• Secondary market royalty — 2-5% от вторичных продаж (ERC-2981). Пассивный доход от NFT торговли.
• Premium auctions — короткие имена (1-3 символа) продаются через аукцион.

Технические аспекты

Стек технологий

Сравнение подходов: ENS Fork vs с нуля

Сроки разработки

Полный production-ready сервис: 3-4 месяца. MVP с базовой регистрацией: 6-8 недель.

Что входит в работу

• Аудит контрактов сторонней компанией (Certora, Trail of Bits по желанию)
• Документация смарт-контрактов на русском и английском
• Исходный код в приватном репозитории с лицензией MIT
• Развёртывание в тестовой и основной сети (Ethereum, Polygon, Arbitrum, Base)
• Настройка CCIP-Read gateway для совместимости с MetaMask и WalletConnect
• Интеграция с The Graph для отображения доменов в каталогах
• Передача прав управления через multisig (Gnosis Safe) — без single point of failure
• Поддержка 3 месяца после запуска (фиксы багов, gas optimization)
• Обучение команды: воркшоп по администрированию domain service

Дополнительную информацию можно найти в ENS documentation.

Свяжитесь с нами для консультации — оценим ваш проект, подготовим коммерческое предложение и roadmap за 1 день. Получите консультацию уже сегодня. Гарантируем прозрачность и полную документацию.

Цифровая идентификация на блокчейне: DID, SBT и Verifiable Credentials

Мы сталкиваемся с запросами, когда Web3-проект уже построил AMM-пул или lending-протокол, а потом осознаёт: сессионную авторизацию сделали через JWT и MongoDB. Это фундаментальное противоречие — приложение претендует на децентрализацию, но идентификация юзеров лежит на одном сервере. Для систем цифровой идентификации в Web3 такой подход неприемлем: он не отвечает compliance-требованиям (KYC для DeFi, accredited investors) и убивает on-chain репутацию в DAO. Мы специализируемся на разработке систем цифровой идентификации для Web3-проектов — начиная от SIWE и заканчивая полными DID/VC стеками. Наш опыт — 80+ проектов в блокчейне — показывает: архитектура identity должна быть децентрализованной с самого начала.

Как Sign-In with Ethereum решает проблему аутентификации?

EIP-4361 SIWE — самый прямой путь убрать логин/пароль. Пользователь подписывает структурированное сообщение кошельком, бэкенд верифицирует подпись через ecrecover. Никаких утечек credentials.

Реализация: библиотека siwe (JS/TS) на фронтенде, SiweMessage.verify() на бэкенде. Сообщение содержит domain, address, nonce (случайный, одноразовый), statement, expiry. Nonce живёт в Redis до верификации — защита от replay attacks. Сегодня SIWE используют более 80 проектов из топ-100 DeFi.

Критическая ошибка, которую мы находим в аудитах: пропуск проверки domain и chain ID. Если бэкенд не сверяет message.domain с реальным доменом — атакующий может переиспользовать подпись SIWE с другого сайта. Мы видели, как несколько dApp потеряли аккаунты из-за этого — в каждом случае восстановление стоило от $10 000 до $50 000.

Для мобильных приложений SIWE работает через WalletConnect v2: QR или deeplink, подпись в кошельке, callback на бэкенд. WalletConnect использует Sign API (отдельный от Transaction API), сессии шифруются X25519 + ChaCha20-Poly1305.

SIWE надёжнее традиционных JWT-сессий: верификация подписи через ecrecover даёт доказательство владения ключом, а не просто знание пароля. Расходы на управление сессиями снижаются на 40–60% — не нужно хранить хеши паролей, не нужно сбрасывать сессии. Для крупного DeFi-протокола это экономия около $200 000 в год на инфраструктуре.

Что такое DID и какой метод выбрать?

DID (Decentralized Identifier) — стандарт W3C (см. Decentralized identifier в Wikipedia), строка did:method:identifier. Метод определяет, где хранится DID Document и как он резолвится. Основные методы, которые мы используем в продакшене:

Для большинства DeFi-проектов достаточно did:ethr или did:key. DID документ содержит verification methods (публичные ключи, до 10 ключей на один документ), authentication, assertionMethod, service endpoints (например, ссылка на KYC-сервис). Мы гарантируем, что выбранный метод будет совместим с target chain (Ethereum, Polygon, Arbitrum, Optimism, Base) и не потребует переделки интерфейсов.

Как работает верификация через Verifiable Credentials?

Verifiable Credential (VC) — подписанное заявление от issuer о subject. Формат W3C: JSON-LD или JWT. Структура: @context, type, issuer (DID), credentialSubject, proof (подпись issuer). (См. также Self-sovereign identity в Wikipedia)

Практический сценарий: KYC-провайдер (issuer) верифицирует пользователя, выдаёт VC «возраст ≥ 18, не OFAC-список». Пользователь хранит VC локально (wallet extension или мобильное приложение). При доступе к протоколу пользователь предъявляет Verifiable Presentation — контейнер с VC, подписанный самим пользователем. Протокол верифицирует подпись issuer (через DID документ issuer) и подпись holder.

Никакие персональные данные не попадают on-chain. Протокол не хранит базу прошедших KYC пользователей. Это privacy-preserving compliance — именно то, что нужно для регулируемых DeFi.

Zero-knowledge proof для VC выводит приватность на новый уровень. Вместо предъявления всего credential пользователь доказывает конкретное свойство (возраст ≥ 18) без раскрытия значения. Инструменты: Polygon ID (Iden3 zkSNARK), Sismo (ZK badges), Semaphore (group membership). Polygon ID реализует zkProof верификацию прямо в смарт-контракте через ICircuitValidator. Сертифицированные инженеры нашей команды имеют опыт интеграции таких ZK-схем в реальные протоколы — клиенты экономят до 70% на KYC-расходах (средний check за год — около $200 000).

Почему Soulbound Tokens не подходят для mass adoption?

SBT (EIP-5192, концепция Vitalik Buterin) — NFT, который нельзя перевести. Реализация: стандартный ERC-721 с переопределённым transferFrom, всегда reverting. Или ERC-5192 с locked().

Применения в production:

• DAO Governance — Snapshot + SBT для голосования «один человек — один голос». Gitcoin Passport строит репутацию на основе on-chain и off-chain stamps, выдаёт SBT-эквивалент (Gitcoin score через Ceramic/EAS).
• Education credentials — Buildspace выдавал NFT за курсы, POAP — proof-of-attendance. SBT делает их non-transferable — нельзя купить чужую историю.
• On-chain credit scoring — Spectral Finance строит MACRO score на основе on-chain истории, результат — SBT с числовым score. Lending протоколы используют его для under-collateralized loans.

Ключевое техническое ограничение: recovery mechanism. Потеря доступа к кошельку = потеря всех SBT. Без recovery нет mass adoption. Решения: social recovery wallet (Guardian, как в Argent), multi-key DID с ротацией, off-chain backup через Shamir Secret Sharing. Мы включаем проработку recovery в каждый проект SBT.

Ethereum Attestation Service как стандарт identity layer

EAS развёрнут на Ethereum mainnet, Optimism, Arbitrum, Base. Любой адрес может выдавать on-chain или off-chain attestations по зарегистрированным схемам. Схема — ABI-encoded структура. Attester подписывает данные и записывает on-chain (с газом) или off-chain с IPFS/Ceramic anchor. Verifier читает через IEAS.getAttestation(uid).

EAS уже интегрирован в Base ecosystem (Coinbase использует для верификации), Gitcoin (Passport stamps), Optimism (RetroPGF contributions). Становится де-факто стандартом on-chain identity layer в L2. Наши разработчики сертифицированы для работы с EAS (опыт 5+ проектов).

Процесс работы

1. Аналитика & compliance — карта user journey: кто issuer, verifier, какие данные нужны протоколу, что нельзя хранить on-chain по GDPR.
2. Проектирование архитектуры — выбор между on-chain SBT, EAS, DID/VC stack. Схема данных, ZK-циркуит (если нужен).
3. Реализация — смарт-контракты (Solidity 0.8.x, Foundry/Hardhat), issuer service (Node.js/Go), holder wallet (ethers.js viem), verifier контракт.
4. Тестирование & аудит — unit-тесты, интеграционные тесты, fuzzing (Echidna), статический анализ (Slither). Привлечение стороннего аудитора.
5. Деплой & поддержка — deploy на target сети, мониторинг (Tenderly), документация, обучение команды.

Что входит в работу (deliverables)

• Исходный код смарт-контрактов (Solidity, открытый под MIT)
• Issuer backend (Node.js/Go) с API для выдачи VC/SBT
• Holder wallet integration (ethers.js viem, RainbowKit, WalletConnect)
• Verifier контракт / скрипт
• Документация архитектуры, deployment runbook
• Поддержка 2 месяца после деплоя

Ориентиры по срокам

Стоимость рассчитывается индивидуально в зависимости от сложности схем, количества чейнов и compliance-требований. Свяжитесь с нами — обсудим ваш сценарий и предложим оптимальный план.

Закажите разработку системы цифровой идентификации — получите консультацию senior-инженера с профильным опытом. А также запишитесь на технический аудит вашей текущей системы идентификации — мы выявим узкие места и предложим конкретные улучшения.