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

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

Проблеми, які вирішуємо

Gas-затрати

Зберігання повних даних on-chain при масовому випуску атестацій (наприклад, тисячі користувачів) веде до невиправданих витрат. EAS дозволяє зберігати лише UID у ланцюжку, а самі дані — off-chain (IPFS, Arweave). Економія газу — до 90%. Наприклад, реєстрація однієї схеми EAS в мережі Polygon коштує менше $0.10, а на Ethereum — до $50. Економія при використанні off-chain атестацій може сягати $500 на 1000 користувачів.

Довіра до 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);

// Реєстрація схеми EAS
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 стеками. Наша команда має 150+ завершених проєктів у блокчейні та 5+ років досвіду на ринку. Ми бачили: архітектура 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 втратили акаунти через це — у кожному випадку відновлення коштувало значних витрат.

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

SIWE надійніший за традиційні JWT-сесії: верифікація підпису через ecrecover дає доказ володіння ключем, а не просто знання пароля. Витрати на управління сесіями знижуються на 40–60% — це в 1.5–2 рази менше ресурсів порівняно з JWT. Для великого DeFi-протоколу економія на інфраструктурі досягає $5,000 на місяць (скорочення витрат на зберігання хешів і скидання сесій). Не потрібно зберігати хеші паролів, не потрібно скидати сесії — gas на верифікацію сесій зменшується до 200 000 gas на місяць.

Чому цифрова ідентифікація має бути децентралізованою?

Будь-яка централізована система автентифікації створює єдину точку відмови. Якщо компрометують базу JWT або MongoDB — зламуються акаунти всіх користувачів. Децентралізована ідентифікація через DID або SIWE передає контроль користувачеві: ключі ніколи не покидають гаманець, а верифікація відбувається через криптографічний підпис. Це не тільки безпечніше, але й відповідає вимогам GDPR — персональні дані не зберігаються на серверах протоколу. Ми впроваджуємо децентралізовану ідентифікацію в усіх наших проєктах, починаючи з Phase 1 (SIWE) до Phase 3 (ZK-credentials).

Що таке DID і який метод обрати?

DID (Decentralized Identifier) — стандарт W3C, рядок 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) і не вимагатиме переробки інтерфейсів.

Типові помилки при виборі DID-методу:

• Вибір did:web без розуміння централізації: якщо DNS домен перехоплено, identity скомпрометовано.
• Ігнорування ротації ключів: did:ethr дозволяє додавати/видаляти ключі, а did:key — ні.
• Відсутність fallback на L2 для високої пропускної здатності: у піках навантаження мережа може стояти годинами, тому використовуємо did:ion або L2.

Як працює верифікація через Verifiable Credentials?

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

Практичний сценарій: 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. Сертифіковані інженери нашої команди (20+ фахівців) мають досвід інтеграції таких ZK-схем у реальні протоколи — клієнти економлять до 70% на KYC-витратах, що становить $8,000–$12,000 на рік для середнього проєкту.

Стандарт W3C Verifiable Credentials: vc-data-model

Чому Soulbound Tokens не підходять для mass adoption?

SBT (EIP-5192, концепція Vitalik Buterin) — NFT, який не можна перевести. Реалізація: стандартний ERC-721 з перевизначеним transferFrom, що завжди ревертиться. Або 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 протоколи використовують його for under-collateralized loans.

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

EAS розгорнуто на Ethereum mainnet, Optimism, Arbitrum, Base. Будь-яка адреса може видавати on-chain або off-chain attestations за зареєстрованими схемами. Схема — ABI-encoded структура. Attester підписує дані та записує on-chain (з газом ~30-50K gas на запис) або 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-інженера з профільним досвідом. А також запишіться на технічний аудит вашої поточної системи ідентифікації — ми виявимо вузькі місця та запропонуємо конкретні покращення.