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

Верификация дипломов на блокчейне: как избавиться от подделок за 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;   // имя — НЕ адрес, students часто без 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. Зачем платить gas за каждый диплом отдельно? Мы реализуем пакетную выдачу:

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