Разработка системы верификации credentials на блокчейне

При разработке системы верификации credentials для DeFi-протокола мы столкнулись с необходимостью проверять KYC-статус пользователей без раскрытия их персональных данных. Стандартная верификация на блокчейне раскрывает все атрибуты credential, что нарушает конфиденциальность. Решение — verifiable credentials с использованием ZK-proof (Groth16 или PLONK), которые позволяют доказать только нужный факт. Такая инфраструктура стандартизирована W3C (Стандарт W3C Verifiable Credentials) и поддерживается кошельками (Metamask, WalletConnect) и протоколами. Мы реализуем полный цикл: выпуск, хранение, верификацию и отзыв цифровых credentials на основе стандартов W3C Verifiable Credentials. Система может интегрироваться с существующими KYC-провайдерами (Persona, Jumio) и работать на Ethereum, Polygon или Arbitrum. Экономия на газе при использовании ZK-proof на L2 составляет до 70% — при 1000 верификаций в день это позволяет сэкономить более $500 в месяц.

Архитектура верификации на блокчейне

Система строится из трёх ключевых компонентов:

• Issuer — доверенная организация (KYC-провайдер, учебное заведение, DAO), которая выпускает подписанные credentials через свой DID.
• Holder — пользователь, хранящий credentials (например, в кошельке или с помощью Polygon ID).
• Verifier — протокол или dApp, который проверяет credentials перед предоставлением доступа.

Верификатор генерирует уникальный challenge (nonce), holder включает его в Verifiable Presentation и подписывает. Это предотвращает replay attacks: презентация действительна только для данного запроса.

// Пользователь создаёт presentation
const presentation = {
    "@context": ["https://www.w3.org/2018/credentials/v1"],
    "type": ["VerifiablePresentation"],
    "verifiableCredential": [kycCredential],
    "proof": {
        "type": "Ed25519Signature2020",
        "challenge": nonce,
        "domain": "app.example.com",
        "created": new Date().toISOString(),
        "verificationMethod": `did:ethr:${userAddress}#controller`,
        "proofPurpose": "authentication",
        "jws": await signPresentation(nonce)
    }
};

Необходимость ZK-верификации

Стандартная верификация раскрывает весь credential: протокол видит эмитента, дату выдачи и все атрибуты. ZK-proof (Groth16 или PLONK) меняет это: пользователь доказывает факт («у меня есть действующий KYC credential») без раскрытия содержимого. Такой подход требуется для:

• DeFi lending — проверить, что заёмщик прошёл KYC, но не раскрывая его личность.
• DAO governance — дать право голоса только обладателям Contributor SBT, не показывая, кто именно.
• Compliant DEX — разрешить торговлю только для верифицированных адресов из разрешённых юрисдикций.

ZK-proof ускоряет проверку в 3–5 раз по сравнению с полной верификацией (при использовании Plookup-фреймворков) и обеспечивает конфиденциальность, требуемую GDPR.

Как ZK-proof защищает приватность?

ZK-proof позволяет верификатору убедиться в достоверности утверждения, не видя исходных данных. Например, пользователь доказывает, что его возраст больше 18, не предъявляя паспорт. Это достигается через циркуиты circom и snarkjs. On-chain registry хранит только хеш или снимок состояния, а полные credentials остаются у пользователя.

Что такое on-chain registry?

On-chain registry — это смарт-контракт, который хранит ссылки на актуальные credentials или их отпечатки. При отзыве credential эмитент обновляет registry, и верификатор проверяет статус. Такой подход обеспечивает прозрачность и неизменяемость, но требует управления газом. Мы оптимизируем gas consumption за счёт хранения только данных, необходимых для верификации.

Наш подход: что входит в разработку

Мы проектируем систему под ключ с нуля или интегрируемся с существующей архитектурой. В рамках разработки мы:

1. Выбираем стандарт (W3C VC + DID или Polygon ID для ZK).
2. Разворачиваем on-chain Registry смарт-контракт на Ethereum/Polygon/Arbitrum (по вашему выбору).
3. Интегрируем trusted issuers (Persona, Jumio, Onfido или собственный).
4. Разрабатываем Verifier SDK (ethers.js, viem) для использования в протоколе.
5. Реализуем ZK-циркуиты (circom + snarkjs) и верификатор на смарт-контракте (при необходимости).
6. Проводим аудит безопасности (Slither, Mythril, Echidna fuzzing).
7. Передаём документацию, тесты и инструкцию по развёртыванию.

Сравнение методов верификации

Этапы разработки

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

1. Аналитика — уточняем типы credentials, число issuer'ов, требования к приватности.
2. Проектирование — выбираем стек (Foundry/Hardhat, circom/snarkjs), архитектуру смарт-контрактов.
3. Реализация — пишем контракты, ZK-циркуиты, SDK, тесты (unit + integration).
4. Аудит — внутренний и внешний аудит безопасности.
5. Деплой — развёртываем на выбранной сети, интегрируем с вашим протоколом.
6. Поддержка — документация, обучение команды, гарантийная поддержка 3 месяца.

pragma circom 2.0.0;
include "../../node_modules/circomlib/circuits/comparators.circom";

template KYCCredential(ageThreshold) {
    signal input age;
    signal input country;
    signal input isKYC;
    signal output valid;
    
    component ageCheck = GreaterThan(32);
    ageCheck.in[0] <== age;
    ageCheck.in[1] <== ageThreshold;
    valid <== ageCheck.out * isKYC;
}

Сроки и что вы получите

Разработка полной credential verification системы занимает 8–16 недель в зависимости от сложности. Стоимость рассчитывается индивидуально после аудита требований. Оцените ваш проект — свяжитесь с нами для консультации.

Отметим: что вы получите:

• Деплоимые смарт-контракты (Registry + Verifier) с открытым кодом.
• Verifier SDK (TypeScript) для интеграции в ваш протокол.
• ZK-циркуиты (если требуется) с аудитом.
• Документацию по архитектуре, деплою и эксплуатации.
• Поддержку 3 месяца и доработки по вашему ТЗ.

Опыт нашей команды — 5+ лет в блокчейн-разработке, 10+ проектов в DeFi, NFT и identity. Мы гарантируем работоспособность и прохождение аудита безопасности. Закажите разработку — получите надёжную инфраструктуру верификации.

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