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

Верифікація дипломів на блокчейні: як позбутися підробок за 2 секунди

Паперовий диплом можна підробити: достатньо хорошого принтера та пари годин. Навіть PDF з підписом — не гарантія, адже файл редагується. Роботодавці витрачають дні на перевірку: запит до вишу, очікування відповіді, бюрократія. Наша команда вирішує це завдання за допомогою смарт-контрактів: хеш документа зберігається в блокчейні, і будь-хто може перевірити автентичність за секунди. За 5 років ми реалізували 20+ проєктів верифікації для університетів і бізнесу, і ось як це працює.

Які проблеми вирішуємо?

Підробка дипломів — бич багатьох галузей. Паперовий диплом легко скопіювати або змінити. Навіть PDF з підписом можна сфабрикувати. Блокчейн робить підробку економічно невигідною: хеш документа зберігається в мережі, і будь-яка розбіжність з оригіналом одразу помітна. Ризик підробки знижується на 90%.

Довга перевірка — запит до університету, очікування відповіді днями або тижнями. Наша система видає результат за 2 секунди: достатньо відсканувати QR-код на дипломі.

Відкликання застарілих дипломів — якщо студента позбавлено ступеня, виш може анулювати запис у контракті. При верифікації буде показано статус revoked.

Як ми це робимо: реальний кейс

Один із клієнтів — регіональний університет із 50 000 студентів. Щороку вони випускають 8 000 дипломів. Раніше перевірка автентичності займала до 10 днів. Ми розгорнули систему на Polygon (газ ~$0.01 за видачу) з batch-функцією та Merkle tree. Тепер усі дипломи випускаються за одну транзакцію, а кожна верифікація коштує копійки. Впровадження зайняло 4 тижні, включно з інтеграцією з їхньою CRM.

Мінімальна архітектура:

contract DiplomaVerification {
    struct DiplomaRecord {
        bytes32 documentHash;   // SHA-256 hash PDF документа
        address institution;
        string recipientName;   // ім'я — НЕ адреса, студенти часто без wallets
        string degree;
        uint256 issuedAt;
        bool revoked;
    }
    
    mapping(bytes32 => DiplomaRecord) public diplomas;
    
    mapping(address => bool) public authorizedInstitutions;
    mapping(address => string) public institutionNames;
    
    event DiplomaIssued(bytes32 indexed documentHash, address indexed institution, string recipientName);
    event DiplomaRevoked(bytes32 indexed documentHash, string reason);
    
    function issueDiploma(
        bytes32 documentHash,
        string calldata recipientName,
        string calldata degree
    ) external onlyAuthorized {
        require(diplomas[documentHash].issuedAt == 0, "Already issued");
        
        diplomas[documentHash] = DiplomaRecord({
            documentHash: documentHash,
            institution: msg.sender,
            recipientName: recipientName,
            degree: degree,
            issuedAt: block.timestamp,
            revoked: false
        });
        
        emit DiplomaIssued(documentHash, msg.sender, recipientName);
    }
    
    function verifyDiploma(bytes32 documentHash) external view returns (
        bool isValid,
        string memory institution,
        string memory recipientName,
        string memory degree,
        uint256 issuedAt
    ) {
        DiplomaRecord memory record = diplomas[documentHash];
        return (
            record.issuedAt != 0 && !record.revoked,
            institutionNames[record.institution],
            record.recipientName,
            record.degree,
            record.issuedAt
        );
    }
}

QR-код верифікація

Зручний UX для роботодавців: диплом містить QR-код, при скануванні відкривається сторінка верифікації.

function generateDiplomaQR(documentHash: string, chainId: number): string {
  const verificationUrl = `https://verify.university.edu/diploma?hash=${documentHash}&chain=${chainId}`;
  return QRCode.toDataURL(verificationUrl);
}

async function verifyDiploma(documentHash: string): Promise<VerificationResult> {
  const provider = new ethers.JsonRpcProvider(RPC_URL);
  const contract = new ethers.Contract(DIPLOMA_CONTRACT, ABI, provider);
  
  const [isValid, institution, recipientName, degree, issuedAt] = 
    await contract.verifyDiploma(documentHash);
  
  return { isValid, institution, recipientName, degree, issuedAt: new Date(issuedAt * 1000) };
}

Як працює batch-видача дипломів?

Для університетів — видача сотень дипломів після graduation. Навіщо платити газ за кожен диплом окремо? Ми реалізуємо пакетну видачу:

function issueDiplomaBatch(
    bytes32[] calldata documentHashes,
    string[] calldata recipientNames,
    string[] calldata degrees
) external onlyAuthorized {
    require(documentHashes.length == recipientNames.length, "Length mismatch");
    
    for (uint i = 0; i < documentHashes.length; i++) {
        diplomas[documentHashes[i]] = DiplomaRecord({
            documentHash: documentHashes[i],
            institution: msg.sender,
            recipientName: recipientNames[i],
            degree: degrees[i],
            issuedAt: block.timestamp,
            revoked: false
        });
    }
    
    emit BatchDiplomasIssued(msg.sender, documentHashes.length, block.timestamp);
}

Або більш економний варіант — Merkle tree: зберігати лише root hash усього batch, верифікація через Merkle proof. Це знижує газ на видачу на 80% порівняно з індивідуальним зберіганням кожного диплома.

Яку мережу обрати?

Якщо бюджет обмежений, Polygon — оптимальний вибір для MVP: газ $0.01 за видачу, швидкість висока. Для production із максимальною надійністю — Arbitrum: використовує безпеку Ethereum, але газ дешевший ($0.10). Ethereum mainnet дає найвищий захист, але газ може бути суттєво дорожчим. Ми деплоїмо контракти в кілька мереж для резервування і рекомендуємо комбінацію Polygon + Arbitrum.

Процес роботи

1. Аналітика — обговорюємо вимоги: обсяг випуску, інтеграція з CRM вишу, терміни.
2. Проєктування — обираємо мережу, архітектуру (Merkle або прямий storage), дизайн QR-сторінки.
3. Розробка смарт-контракту — Solidity 0.8.x з тестами на Foundry (fuzz, unit). Аудит за допомогою Slither і Mythril.
4. Backend і frontend — admin-панель для вишу (випуск, відкликання, перегляд) + публічна сторінка верифікації з QR.
5. Деплой — deploy на обрані мережі, налаштування DNS, випуск тестового диплома.
6. Підтримка — передаємо доступи, документацію, навчаємо адміністраторів.

Що входить у розробку?

Типові помилки при впровадженні

• Зберігати в контракті весь PDF, а не хеш — дорого й небезпечно. Використовуйте лише хеш.
• Використовувати лише одну мережу — при форку або проблемах верифікація зупиниться. Дублюйте дані мінімум на 2 мережі.
• Не відкликати застарілі дипломи — функція revoke обов'язкова.
• Ігнорувати oracle для перевірки статусу вишу — при зміні ключів адміністрації можна втратити доступ.

Терміни реалізації

Типовий проєкт (контракт + admin portal + сторінка верифікації) — від 3 до 5 тижнів залежно від складності інтеграції. При використанні Merkle tree — +1 тиждень.

Замовте консультацію — ми проаналізуємо ваші вимоги та запропонуємо оптимальне рішення. Оцінимо ваш проєкт безкоштовно. Напишіть нам — розкажемо, як впровадити блокчейн-верифікацію у вашому університеті без зайвих витрат. Гарантуємо прозорість і повну документацію.

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