Разработка системы аттестации (EAS — Ethereum Attestation Service)

Допустим, вам нужно построить систему верификации KYC для DeFi-платформы. On-chain хранение каждой анкеты — дорого, а IPFS без подтверждения не вызывает доверия. Решение — Ethereum Attestation Service (EAS): off-chain данные с on-chain подписью. Мы разрабатываем системы аттестации на EAS под ключ: от проектирования схемы до deployment resolver-контракта и интеграции фронтенда через EAS SDK. Согласно спецификации, EAS обеспечивает верифицируемость и экономию газа до 90% по сравнению с прямым хранением данных в блокчейне. EAS контракты — открытая кодовая база, которую мы адаптируем под ваш сценарий.

Проблемы, которые решаем

Gas-затраты

Хранение полных данных on-chain при массовом выпуске аттестаций (например, тысячи пользователей) ведёт к неоправданным расходам. EAS позволяет хранить только UID в цепочке, а сами данные — off-chain (IPFS, Arweave). Экономия газа — до 90%.

Доверие к off-chain

Без on-chain привязки данные легко подделать. EAS решает это через неизменяемый UID, верифицируемый в смарт-контракте. Любой может проверить, что аттестация создана конкретным адресом и не отозвана.

Управление отзывом

Часто нужно аннулировать аттестацию (пользователь вышел из DAO, истёк KYC). Resolver-контракт EAS позволяет гибко управлять revocable-флагом и выполнять дополнительную логику при отзыве.

Как мы это делаем

В процессе разработки системы EAS мы регистрируем схему, создаём resolver и интегрируем SDK. Рассмотрим типовую реализацию.

Регистрация схемы

Схема определяет структуру данных аттестации. Регистрируется один раз в SchemaRegistry и может переиспользоваться.

import { ISchemaRegistry, SchemaRecord } from "@ethereum-attestation-service/eas-contracts/contracts/ISchemaRegistry.sol";

ISchemaRegistry schemaRegistry = ISchemaRegistry(EAS_SCHEMA_REGISTRY);

// Регистрация схемы
bytes32 schemaUID = schemaRegistry.register(
    "bool isKYCVerified, uint8 verificationLevel, string jurisdiction",
    ISchemaResolver(resolverAddress),  // опциональный resolver контракт
    true  // revocable
);

Создание Attestation

import { IEAS, AttestationRequest, AttestationRequestData } from "@ethereum-attestation-service/eas-contracts/contracts/IEAS.sol";

IEAS eas = IEAS(EAS_ADDRESS);

bytes32 attestationUID = eas.attest(
    AttestationRequest({
        schema: schemaUID,
        data: AttestationRequestData({
            recipient: recipientAddress,
            expirationTime: block.timestamp + 365 days,
            revocable: true,
            refUID: bytes32(0),
            data: abi.encode(true, 2, "EU"),  // isKYCVerified, level, jurisdiction
            value: 0
        })
    })
);

Schema Resolver — безопасность и гибкость

Resolver-контракт вызывается при создании/отзыве аттестации. В нём можно проверять права аттестора, корректность данных, обновлять внешние хранилища. Без resolver контракт принимает любые данные — риск для системы.

import { SchemaResolver } from "@ethereum-attestation-service/eas-contracts/contracts/resolver/SchemaResolver.sol";

contract KYCAttestationResolver is SchemaResolver {
    mapping(address => bool) public verifiedAddresses;

    function onAttest(Attestation calldata attestation, uint256) 
        internal override returns (bool) {
        require(authorizedAttesters[attestation.attester], "Not authorized");

        (, uint8 level,) = abi.decode(attestation.data, (bool, uint8, string));
        require(level >= 1 && level <= 3, "Invalid level");

        verifiedAddresses[attestation.recipient] = true;
        return true;
    }

    function onRevoke(Attestation calldata attestation, uint256)
        internal override returns (bool) {
        verifiedAddresses[attestation.recipient] = false;
        return true;
    }
}

Интеграция через EAS SDK (TypeScript)

import { EAS, SchemaEncoder } from "@ethereum-attestation-service/eas-sdk";

const eas = new EAS(EAS_ADDRESS);
eas.connect(signer);

const schemaEncoder = new SchemaEncoder("bool isKYCVerified,uint8 verificationLevel,string jurisdiction");

const encodedData = schemaEncoder.encodeData([
    { name: "isKYCVerified", value: true, type: "bool" },
    { name: "verificationLevel", value: 2, type: "uint8" },
    { name: "jurisdiction", value: "EU", type: "string" }
]);

const tx = await eas.attest({
    schema: schemaUID,
    data: {
        recipient: recipientAddress,
        expirationTime: BigInt(Math.floor(Date.now() / 1000) + 365 * 24 * 3600),
        revocable: true,
        data: encodedData
    }
});

const uid = await tx.wait();

Как выбрать между on-chain и off-chain аттестациями?

On-chain аттестации хранят все данные в блокчейне — высокая стоимость, но постоянная доступность. Off-chain аттестации хранят данные в IPFS/Arweave, а в блокчейне только UID. Off-chain вариант в 10 раз дешевле при массовом выпуске, что критично для KYC или репутационных порталов. Сравнение:

Для массовых сценариев (KYC, репутация) off-chain оптимальна. Для редких, но ценных аттестаций (дипломы, лицензии) можно выбрать on-chain.

Почему Resolver-контракт критичен для безопасности?

Без resolver любой адрес может зааттестовать произвольные данные по вашей схеме — система теряет смысл. Resolver-контракт выступает шлюзом: проверяет, что аттестор авторизован, данные валидны, не превышен лимит. Также можно реализовать автоматическое создание встречных аттестаций (например, «подтверждение KYC» от проверяющего в ответ на запрос). Мы всегда включаем resolver в архитектуру для ответственных схем.

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

1. Аналитика — изучаем сценарий, определяем поля схемы, revocability, срок действия.
2. Проектирование — создаём схему (JSON/ABI), проектируем resolver с логикой.
3. Разработка — пишем смарт-контракты (Solidity), покрываем тестами (Foundry).
4. Интеграция — настраиваем EAS SDK фронтенда: создание, просмотр, отзыв аттестаций.
5. Тестирование — деплоим на тестовой сети, проводим интеграционное тестирование.
6. Деплой — регистрируем схему в мейннете, деплоим resolver, запускаем в production.

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

Наш опыт и гарантии

Мы — команда блокчейн-инженеров с более чем 5-летним опытом в Ethereum-разработке. Реализовали более 15 проектов на EAS: от KYC-систем для DeFi до репутационных порталов для DAO. Каждый resolver-контракт проходит статический анализ Slither и fuzz-тестирование Echidna. Гарантируем отсутствие reentrancy и переполнения — эти уязвимости встречаются даже в EAS-решениях новичков.

Сроки и стоимость

Разработка системы на EAS занимает от 2 до 4 недель в зависимости от сложности. Стоимость рассчитывается индивидуально под ваш сценарий. Для предварительной оценки — свяжитесь с нами: мы проанализируем проект за 1 рабочий день и подготовим коммерческое предложение. Закажите разработку системы EAS — мы составим смету и сроки под вашу задачу. Получите консультацию уже сегодня.

Примеры использования

EAS применяется в: Gitcoin Passport (аттестации об on-chain активности), Optimism Retro Funding (подтверждение вклада), Safe (доверенные адреса). Мы можем адаптировать любой из этих сценариев под вашу задачу.

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