Розробка системи децентралізованої ідентифікації (DID)

OAuth, Social Login, ручний KYC — кожен новий застосунок вимагає повторної верифікації. Дані течуть, акаунти зламують. Decentralized Identifiers (DID) за стандартом W3C вирішують цю проблему раз і назавжди. Ми розробляємо DID-системи під ключ: від смарт-контрактів до інтеграції з гаманцями. Наша команда має 5+ років досвіду в блокчейні та реалізувала понад 50 проєктів, включаючи DID-рішення на Ethereum і Polygon. Традиційні методи аутентифікації змушують користувача довіряти свої дані централізованим серверам — кожен провайдер зберігає персональні дані, створюючи поверхню атаки. DID, навпаки, повністю виключає серверне зберігання: ключі генеруються локально, а документи підписуються на пристрої. Це знижує витрати на безпеку в середньому на 30%. Сьогодні менше 10% компаній використовують DID, але впровадження дозволяє скоротити витрати на KYC-верифікацію до 40%. Стандарт W3C DID Core 1.0 визначає децентралізовані ідентифікатори як URI, які не потребують центрального реєстру. На відміну від OAuth, де ідентичність прив'язана до провайдера, DID дозволяє користувачеві самому керувати своїми authentication methods, публікуючи лише відкриті ключі в блокчейні.

Наприклад, фінтех-стартап замінив ручний KYC на DID-верифікацію. Час перевірки клієнта скоротився з 24 годин до 5 хвилин, а вартість однієї верифікації впала з $15 до $0.02. Через 6 місяців економія склала $120 000 при потоці 1000 нових клієнтів на місяць. DID-система окупається в середньому за 3-6 місяців, знижуючи операційні витрати в 5 разів порівняно з традиційними KYC-провайдерами.

Як DID вирішує проблеми безпеки та KYC?

80% зломів пов'язані з витоком паролів — DID усуває цю вразливість, оскільки приватні ключі ніколи не покидають пристрій користувача. Відкликання акаунта або розкриття даних неможливі без вашої згоди: управління ідентичністю повністю децентралізоване. Пропускна здатність верифікації в 10 разів вища порівняно з централізованими KYC-провайдерами завдяки off-chain доказам.

DID — це URI виду did:method:identifier:

did:ethr:0x742d35Cc6634C0532925a3b844Bc454e4438f44e
did:key:z6MkpTHR8VNsBxYAAWHut2Geadd9jSwuias8sisDArDJF
did:web:example.com
did:ion:EiClkZMDxPKqC9c-umQfTkR8vvZ9JPhl_xLDI9Nfk38zA

DID Method визначає, як DID створюється, оновлюється, розв'язується. ethr — Ethereum-based, ion — Bitcoin-anchored через Sidetree, web — через веб-домен. Вибір методу залежить від бажаного ступеня децентралізації та бюджету.

ethr підходить для dApp, де важлива прозорість, key — для локальних гаманців, ion — для стійкості до цензури.

Як працюють Verifiable Credentials?

DID — це ідентифікатор. Verifiable Credentials — це твердження про власника DID, підписані іншим DID (issuer).

{
    "@context": ["https://www.w3.org/2018/credentials/v1"],
    "type": ["VerifiableCredential", "UniversityDegreeCredential"],
    "issuer": "did:web:university.example.edu",
    "issuanceDate": "2023-06-01T00:00:00Z",
    "credentialSubject": {
        "id": "did:ethr:0xGraduateAddress",
        "degree": {
            "type": "Bachelor",
            "name": "Computer Science"
        }
    },
    "proof": {
        "type": "Ed25519Signature2020",
        "created": "2023-06-01T12:00:00Z",
        "verificationMethod": "did:web:university.example.edu#key-1",
        "proofPurpose": "assertionMethod",
        "jws": "eyJhbGciOiJFZERTQS..."
    }
}

Повний VC розкриває всі поля. Selective disclosure — довести лише потрібні факти. BBS+ Signatures дозволяють математично довести, що розкрите поле є частиною вихідного документа, не показуючи решту. Polygon ID використовує zkSNARK для верифікації claims без розкриття самого VC — час перевірки скорочується до 100 мс.

contract DIDRegistry {
    mapping(address => mapping(bytes32 => mapping(address => uint256))) public delegates;
    mapping(address => mapping(bytes32 => mapping(bytes32 => uint256))) public attributes;
    mapping(address => uint256) public changed;
    mapping(address => address) public owners;
    
    event DIDDelegateChanged(
        address indexed identity,
        bytes32 delegateType,
        address delegate,
        uint256 validTo,
        uint256 previousChange
    );
    
    event DIDAttributeChanged(
        address indexed identity,
        bytes32 name,
        bytes value,
        uint256 validTo,
        uint256 previousChange
    );
    
    function identityOwner(address identity) public view returns (address) {
        address owner = owners[identity];
        return owner == address(0) ? identity : owner;
    }
    
    function setAttribute(
        address identity,
        bytes32 name,
        bytes calldata value,
        uint256 validity
    ) external onlyOwner(identity) {
        attributes[identity][name][keccak256(value)] = block.timestamp + validity;
        emit DIDAttributeChanged(identity, name, value, block.timestamp + validity, changed[identity]);
        changed[identity] = block.number;
    }
}

Архітектура повної SSI системи

DID Resolver перетворює DID на DID Document. Для did:ethr — читає події з DIDRegistry контракту:

import { Resolver } from 'did-resolver';
import { getResolver as getEthrResolver } from 'ethr-did-resolver';

const providerConfig = {
    networks: [{
        name: 'mainnet',
        rpcUrl: 'https://mainnet.infura.io/v3/...'
    }]
};

const ethrResolver = getEthrResolver(providerConfig);
const resolver = new Resolver({ ...ethrResolver });

const didDocument = await resolver.resolve('did:ethr:0x742d35Cc...');

Процес розробки та що входить

1. Аналітика: аудит вимог та сценаріїв використання (1–2 тижні).
2. Проектування: вибір DID-методу, стеку, архітектури смарт-контрактів.
3. Розробка: смарт-контракти (EVM, Solana), інтеграція гаманців, lifecycle VC.
4. Тестування: unit-тести, інтеграційні тести, gas-бенчмарки.
5. Деплой: на testnet, потім mainnet, налаштування DID Resolver та Revocation Registry.

В рамках проекту ми надаємо:

• Смарт-контракти: DID Registry, Revocation Registry з покриттям тестами.
• Серверна частина: Issuer Service та Verifier Service (Node.js, TypeScript).
• Клієнтський SDK для інтеграції в гаманці (ethers.js, viem).
• Документація: API-специфікація, інструкції з інтеграції.
• Навчання команди замовника роботі з системою.
• Гарантійна підтримка на 3 місяці після деплою.

Розробка з нуля — 8–16 тижнів. Інтеграція готових компонентів (Veramo, SpruceID, Polygon ID) — 3–6 тижнів. Зв'яжіться з нами, щоб обговорити ваш сценарій. Замовте розробку DID-системи під ключ — отримайте консультацію.

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