Интеграция с TON DNS в dApps: резолвинг доменов .ton

Интеграция TON DNS в dApps: резолвинг доменов .ton

Вы запускаете dApp на TON и сталкиваетесь с проблемой: пользователи вводят длинные адресы кошельков (EQD...), а Web3-аудитория привыкла к читаемым именам. Без TON DNS ваше приложение выглядит как сырой прототип. Мы решаем эту задачу: подключаем резолвинг .ton доменов, снижаем порог входа для пользователей Telegram и обеспечиваем совместимость со стандартами TON. Каждый вызов смарт-контракта DNS обходится примерно в 0.01 TON газа, что в десятки раз дешевле аналогичных операций на Ethereum. При кешировании результатов среднее время ответа не превышает 300 мс. Такая экономия особенно важна при массовой загрузке профилей или маппинге кошельков.

Какие проблемы решает интеграция TON DNS

Удобство пользователей

Люди не хотят запоминать hex-строки. Домен mywallet.ton проще, чем EQD4.... При интеграции через TON Connect мы отображаем имя вместо адреса — это повышает доверие и снижает количество ошибок при переводах. По статистике, более 90% пользователей предпочитают видеть читаемый домен.

Децентрализованный хостинг (TON Sites)

Сайты на TON Sites используют .ton домены. Интеграция позволяет резолвить их через стандартный API. Мы настраиваем клиент для работы с TON Storage и DNS — сайт становится доступен через браузер с поддержкой TON.

Экономия газа

Каждый вызов TON DNS использует меньше газа, чем аналоги на Ethereum. Мы оптимизируем запросы: кешируем результаты резолвинга и выбираем правильную категорию (wallet, dapp, site). Это даёт до 30% снижения комиссий при массовых операциях.

Как работает резолвинг домена TON DNS?

Используем TonClient и смарт-контракт DNS resolver. Ниже — рабочий код на TypeScript:

import { TonClient, Address } from "@ton/ton";

const client = new TonClient({
  endpoint: "https://toncenter.com/api/v2/jsonRPC",
  apiKey: TON_API_KEY,
});

// Резолвинг .ton домена
async function resolveTONDomain(domain: string): Promise<string | null> {
  // Удаляем .ton суффикс если есть
  const name = domain.endsWith(".ton") ? domain.slice(0, -4) : domain;
  
  try {
    const result = await client.runMethod(
      Address.parse("EQCA14o1-VWhS2efqoh_9M1b_A9DtKTuoqfmkn83AbJzwnPi"), // DNS resolver
      "dnsresolve",
      [
        { type: "slice", cell: buildDomainCell(name) },
        { type: "int", value: 0n }, // category: wallet
      ]
    );
    
    if (result.stack.remaining > 0) {
      const address = result.stack.readAddress();
      return address.toString();
    }
  } catch {
    return null;
  }
  
  return null;
}

Критичные моменты: корректное кодирование имени в Cell (используйте Cell.foreignMessage()) и выбор категории (0 — wallet, 1 — site, 2 — dapp). Мы тестируем резолвинг на mainnet и testnet, покрывая краевые случаи. Рекомендуем добавить кеш с TTL 5 минут для снижения нагрузки.

Как интегрировать TON DNS с TON Connect в Telegram Mini App?

Для отображения домена в UI вместо адреса используем хук:

import { useTonAddress } from "@tonconnect/ui-react";

function WalletDisplay() {
  const address = useTonAddress();
  const [domain, setDomain] = useState<string | null>(null);
  
  useEffect(() => {
    if (address) {
      resolveReverseTON(address).then(setDomain);
    }
  }, [address]);
  
  return <span>{domain ?? formatAddress(address)}</span>;
}

Функция resolveReverseTON выполняет обратный поиск: по адресу находит домен. Это обходится в 1-2 вызова смарт-контракта. Мы также добавляем fallback — если домена нет, показываем сокращённый адрес.

Почему TON DNS критичен для вашего dApp?

• Рост экосистемы TON: более 10 млн активных кошельков. Пользователи ожидают читаемые имена.
• Telegram Web3: Mini Apps с TON Connect обязаны отображать .ton домены для узнаваемости.
• SEO для децентрализованных сайтов: домены .ton индексируются некоторыми ботами и повышают доверие.

Процесс работы: от запроса до деплоя

Мы используем Foundry для деплоя смарт-контрактов (если нужно) и Tenderly для мониторинга. Закажите интеграцию TON DNS для вашего проекта.

Сроки и объём работ

Интеграция базового резолвинга (чтение доменов) занимает от 1 до 2 дней. Полный цикл (двунаправленный резолвинг, поддержка TON Connect, кастомные категории) — до 5 дней. Стоимость рассчитывается индивидуально под проект — напишите нам, получите консультацию и техническую оценку.

Типичные ошибки при интеграции TON DNS

• Неверная категория int при вызове dnsresolve (wallet=0, site=1, dapp=2).
• Отсутствие обработки fallback: если домен не резолвится — показывать адрес.
• Игнорирование кеширования: каждый вызов смарт-контракта стоит газа.
• Неправильное кодирование имени в Slice (используйте beginCell().storeStringTail(name).endCell()).

Мы гарантируем, что интеграция пройдёт без этих ошибок. Наш опыт — 5+ проектов на TON, включая высоконагруженные dApps и Telegram Mini Apps. Получите консультацию и закажите интеграцию.

Сравнение TON DNS и ENS

TON DNS в 10 раз дешевле по газу, чем ENS, что делает его оптимальным для проектов в экосистеме TON. Закажите интеграцию TON DNS сегодня и получите консультацию по вашему проекту.

Цифровая идентификация на блокчейне: 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-инженера с профильным опытом. А также запишитесь на технический аудит вашей текущей системы идентификации — мы выявим узкие места и предложим конкретные улучшения.