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

Проектируем и разрабатываем блокчейн-решения полного цикла: от архитектуры смарт-контрактов до запуска DeFi-протоколов, NFT-маркетплейсов и криптобирж. Аудит безопасности, токеномика, интеграция с существующей инфраструктурой.
Показано 1 из 1Все 1306 услуг
Разработка системы верификации credentials на блокчейне
Сложный
~1-2 недели
Часто задаваемые вопросы

Направления блокчейн-разработки

Этапы блокчейн-разработки

Последние работы

  • image_website-b2b-advance_0.webp
    Разработка сайта компании B2B ADVANCE
    1288
  • image_web-applications_feedme_466_0.webp
    Разработка веб-приложения для компании FEEDME
    1198
  • image_websites_belfingroup_462_0.webp
    Разработка веб-сайта для компании БЕЛФИНГРУПП
    902
  • image_ecommerce_furnoro_435_0.webp
    Разработка интернет магазина для компании FURNORO
    1122
  • image_logo-advance_0.webp
    Разработка логотипа компании B2B Advance
    589
  • image_crm_enviok_479_0.webp
    Разработка веб-приложения для компании Enviok
    859

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

Верификация credentials на блокчейне — это инфраструктура для проверки утверждений: «Этот адрес прошёл KYC», «Эта компания реальна», «Этот разработчик имеет определённый уровень квалификации». Система отвечает на вопрос: как протокол может проверить факты о пользователе без централизованного identity провайдера и без раскрытия лишних данных?

Архитектура verification системы

Credential Issuers

Организации выпускающие verifiable credentials:

  • KYC провайдеры (Persona, Jumio, Onfido)
  • Профессиональные ассоциации
  • Учебные заведения
  • DAO и протоколы (contributor credentials)
  • Государственные органы (в будущем)

Каждый issuer имеет известный DID и публичный ключ. Подлинность issuer верифицируется через его DID Document.

On-chain Verification Registry

contract CredentialVerificationRegistry {
    // Зарегистрированные trusted issuers
    mapping(address => IssuerRecord) public trustedIssuers;
    
    struct IssuerRecord {
        string name;
        string[] supportedCredentialTypes;
        bool active;
        uint256 addedAt;
    }
    
    // Кеш верифицированных фактов (чтобы не верифицировать каждый раз)
    mapping(address => mapping(bytes32 => VerificationRecord)) public verifications;
    
    struct VerificationRecord {
        bool verified;
        address verifiedBy;  // какой issuer
        uint256 verifiedAt;
        uint256 expiresAt;
        bytes32 credentialType;
    }
    
    // Верификатор записывает результат после off-chain проверки VC
    function recordVerification(
        address subject,
        bytes32 credentialType,
        uint256 expiresAt
    ) external onlyTrustedIssuer {
        verifications[subject][credentialType] = VerificationRecord({
            verified: true,
            verifiedBy: msg.sender,
            verifiedAt: block.timestamp,
            expiresAt: expiresAt,
            credentialType: credentialType
        });
    }
    
    function isVerified(address subject, bytes32 credentialType) 
        external view returns (bool) {
        VerificationRecord memory record = verifications[subject][credentialType];
        return record.verified && 
               block.timestamp < record.expiresAt;
    }
}

Presentation Protocol

Пользователь представляет credentials для верификации через Verifiable Presentation (VP):

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

Challenge-response: сервер генерирует nonce, пользователь включает в presentation и подписывает. Предотвращает replay attack (презентация valid только для этого конкретного запроса).

Privacy-preserving verification

Проблема: стандартная верификация раскрывает весь VC. Протокол узнаёт не только что пользователь прошёл KYC, но и когда, у какого провайдера, и другие данные.

ZK-proof verification: пользователь доказывает факт («у меня есть действующий KYC VC») без раскрытия содержания VC.

// Polygon ID style ZK verification
const proofRequest = {
    id: "kyc-verification-request",
    typ: "application/iden3comm-plain-json",
    type: "https://iden3-communication.io/proofs/1.0/contract-invoke-request",
    body: {
        transaction_data: {
            contract_address: verifierContractAddress,
            method_id: "submitZKPResponse"
        },
        scope: [{
            id: 1,
            circuitId: "credentialAtomicQueryMTP",
            query: {
                allowedIssuers: ["*"],
                type: "KYCVerification",
                credentialSubject: {
                    isVerified: { "$eq": true }
                }
            }
        }]
    }
};

На смарт-контракте — Groth16 или PLONK верификатор для ZK proof.

Интеграция в протоколы

Lending protocol: перед выдачей кредита — проверить KYC credential. DAO governance: только держатели Contributor SBT могут голосовать. Compliant DEX: торговля только для verified пользователей из whitelist юрисдикций.

modifier onlyVerifiedUser(address user) {
    require(
        credentialRegistry.isVerified(user, KYC_CREDENTIAL_TYPE),
        "KYC verification required"
    );
    _;
}

Разработка полной credential verification системы — 8-16 недель в зависимости от требований к приватности и числа интегрированных issuer'ов.