Розробка системи верифікації 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

Розробка системи верифікації облікових даних на блокчейні

Верифікація облікових даних на блокчейні — це інфраструктура для перевірки тверджень: "Ця адреса пройшла KYC", "Ця компанія реальна", "Цей розробник має певний рівень кваліфікації". Система відповідає на питання: як протокол може перевірити факти про користувача без централізованого провайдера ідентичності та без розкриття непотрібних даних?

Архітектура системи верифікації

Видавці облікових даних

Організації, які видають перевіряємі облікові дані:

  • KYC провайдери (Persona, Jumio, Onfido)
  • Професійні асоціації
  • Навчальні заклади
  • DAOs та протоколи (облікові дані розробників)
  • Державні органи (у майбутньому)

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

On-chain реєстр верифікації

contract CredentialVerificationRegistry {
    // Зареєстровані довірені видавці
    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;  // який видавець
        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

Користувач представляє облікові дані для верифікації через Verifiable Presentation (VP):

// Користувач створює presentation зі своїх облікових даних
const presentation = {
    "@context": ["https://www.w3.org/2018/credentials/v1"],
    "type": ["VerifiablePresentation"],
    "verifiableCredential": [kycCredential],
    "proof": {
        "type": "Ed25519Signature2020",
        "challenge": nonce,  // запобігає replay атакам
        "domain": "app.example.com",
        "created": new Date().toISOString(),
        "verificationMethod": `did:ethr:${userAddress}#controller`,
        "proofPurpose": "authentication",
        "jws": await signPresentation(nonce)
    }
};

Challenge-response: сервер генерує nonce, користувач включає в presentation та підписує. Запобігає replay атаці (presentation дійсна тільки для цього конкретного запиту).

Верифікація, що зберігає приватність

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

ZK-proof верифікація: користувач доводить факт ("у мене є дійсна KYC VC") без розкриття змісту VC.

// Polygon ID стиль ZK верифікація
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 протокол: перед видачею кредиту — перевірити KYC облікові дані. DAO governance: тільки власники Contributor SBT можуть голосувати. Compliant DEX: торговля тільки для верифікованих користувачів з дозволених юрисдикцій.

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

Розробка повної системи верифікації облікових даних — 8-16 тижнів залежно від вимог до приватності та кількості інтегрованих видавців.