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







