Система верифікації фізичних пристроїв DePIN: розробка та аудит

Як працює криптографічна верифікація DePIN?

Припустимо, ви будуєте децентралізовану мережу для моніторингу якості повітря. Сотні фізичних сенсорів розгорнуті по місту, кожен передає дані та отримує токени. Проблема — відрізнити реальний сенсор від програмного емулятора, який шле фейкові показники та спустошує пул винагород. Без криптографічної прив'язки токен-адреси до апаратного модуля будь-який агент може симулювати роботу. Ми вирішуємо це завдання вже понад п'ять років: двадцять з гаком проектів DePIN у продакшені, від IoT-сенсорів до хотспотів. Сумарно обслуговуємо понад 10 000 фізичних пристроїв. Наші клієнти економлять до 90% коштів, які раніше йшли на фейкові нагороди — для мережі з 1000 пристроїв це може перевищувати $50 000 на місяць. Інвестиції в систему верифікації окупаються за рахунок зниження таких втрат.

Ключова складність — три класи атак: Spoofing (емуляція даних), Clone (клонування ключів на безліч машин) та Sybil (масова реєстрація віртуальних пристроїв). Hardware root of trust — єдиний спосіб захиститися. Ця технологія лежить в основі всіх наших рішень для DePIN.

TPM 2.0 (ISO/IEC 11889) — стандарт, в якому приватний ключ ніколи не залишає чіп, підпис формується всередині. Це основа довіри.

Три класи атак

Spoofing: програмний агент емулює дані — GPS, сенсори, network metrics. Без захищеного ключа на чіпі це невідрізнимо від реального пристрою.

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

Sybil: один оператор реєструє сотні "пристроїв" через віртуальні інстанси. Критично для мереж з винагородою за кількість вузлів. Для анти-сибіл атак ми застосовуємо стейкінг та верифікацію на основі репутації.

Вибір апаратного кореня довіри: TPM, Secure Element або TEE?

• TPM 2.0 (ISO/IEC 11889): приватний ключ ніколи не залишає чіп, підпис всередині. Підтримується в промисловому IoT (Raspberry Pi через GPIO).
• Secure Element (ECC608): виділений мікроконтролер. Використовується в Hotspot від Helium. Детальніше — Secure Element.
• TEE (TrustZone, SGX): ізольоване середовище в процесорі. Дешевше, але вразливе до side-channel.
• PUF: унікальний "відбиток" чіпа — клонувати фізично неможливо. Перспективна технологія.

Як ми будуємо систему верифікації

Provisioning: реєстрація пристрою у виробника

Виробник вбудовує в пристрій Secure Element, генерує ключову пару всередині чіпа (приватний ключ ніколи не вивантажується). Створюється X.509 сертифікат, підписаний CA виробника. On-chain реєструється публічний ключ та відбиток сертифіката.

contract DeviceRegistry {
    struct Device {
        address owner;
        bytes32 certFingerprint;
        bytes publicKey;
        uint256 registeredAt;
        bool active;
    }
    mapping(bytes32 => Device) public devices;
    mapping(address => bytes32[]) public ownerDevices;
    mapping(bytes32 => bool) public trustedManufacturers;

    event DeviceRegistered(bytes32 indexed deviceId, address indexed owner, bytes publicKey);
    event DeviceTransferred(bytes32 indexed deviceId, address indexed from, address indexed to);

    function registerDevice(
        bytes32 deviceId,
        bytes calldata publicKey,
        bytes calldata deviceCertificate,
        bytes calldata manufacturerSignature
    ) external {
        bytes32 certFingerprint = keccak256(deviceCertificate);
        require(
            verifyManufacturerSignature(deviceId, publicKey, manufacturerSignature),
            "Invalid manufacturer signature"
        );
        devices[deviceId] = Device({
            owner: msg.sender,
            certFingerprint: certFingerprint,
            publicKey: publicKey,
            registeredAt: block.timestamp,
            active: true
        });
        ownerDevices[msg.sender].push(deviceId);
        emit DeviceRegistered(deviceId, msg.sender, publicKey);
    }
}

Challenge-response: регулярна перевірка роботи

Смарт-контракт кожну епоху (наприклад, годину) випускає challenge — випадковий nonce. Пристрій підписує його своїм приватним ключем всередині SE/TEE. Підпис перевіряється on-chain: якщо не збігається — пристрій вважається неактивним, нагорода знижується.

async function issueChallenge(deviceId: string): Promise<Challenge> {
  const nonce = crypto.randomBytes(32);
  const timestamp = Math.floor(Date.now() / 1000);
  await challengeContract.issueChallenge(
    deviceId,
    ethers.utils.keccak256(nonce),
    timestamp + CHALLENGE_EXPIRY
  );
  return { nonce: nonce.toString('hex'), expiry: timestamp + CHALLENGE_EXPIRY };
}

contract DePINRewards {
    uint256 constant REWARD_PER_EPOCH = 1e18;
    uint256 constant EPOCH_DURATION = 3600;

    struct DeviceStats {
        uint256 lastChallengeTime;
        uint256 successfulChallenges;
        uint256 currentEpoch;
        uint256 epochChallengesRequired;
        uint256 epochChallengesPassed;
    }

    function claimReward(bytes32 deviceId) external {
        DeviceStats storage stats = deviceStats[deviceId];
        Device memory device = deviceRegistry.devices[deviceId];
        require(device.owner == msg.sender, "Not owner");
        require(device.active, "Device inactive");
        uint256 currentEpoch = block.timestamp / EPOCH_DURATION;
        require(currentEpoch > stats.currentEpoch, "Epoch not complete");
        uint256 uptime = stats.epochChallengesPassed * 100 / stats.epochChallengesRequired;
        require(uptime >= MIN_UPTIME_PERCENT, "Insufficient uptime");
        uint256 reward = REWARD_PER_EPOCH * uptime / 100;
        stats.currentEpoch = currentEpoch;
        stats.epochChallengesPassed = 0;
        rewardToken.mint(msg.sender, reward);
    }
}

Proof of Location: античит георозподілу

Для мереж, де важлива географія (сенсори, хотспоти), використовуємо радіо-свідчення (Helium-підхід): пристрій A "чує" пристрій B і підтверджує його присутність. Альтернатива — GPS + TEE з підписом. Атака вимагає фізичної розстановки пристроїв, що дорого.

Staking та Slashing: фінансовий бар'єр для атак

При реєстрації пристрій блокує стейк. При порушенні — слешінг:

• Пропуск challenge -> зниження uptime, менша нагорода
• Clone (дублікат ключа) -> 100% слеш, деактивація
• Фейкові дані -> слеш + manual review

Ми гарантуємо прозорість механізму слешінгу через on-chain логіку.

Що входить в роботу

• Аудит безпеки: аналіз смарт-контрактів та апаратної інтеграції (Slither, Echidna, формальна верифікація)
• Документація: опис протоколу, посібник з інтеграції для виробників техніки
• Firmware SDK: бібліотеки для TPM/SE на Rust/Go
• Деплой та тестнет: розгортання в тестовій мережі, навантажувальне тестування, моніторинг
• Підтримка: річна гарантія на смарт-контракти, консультації з upgrade

Отримайте консультацію з вибору hardware root of trust для вашого проекту.

Покроковий процес розробки

1. Аналітика: визначення моделі загроз, вибір hardware root of trust під бюджет та сценарій.
2. Проектування: архітектура on-chain реєстру, challenge-response, стейкінг.
3. Реалізація: смарт-контракти (Solidity), firmware SDK, інтеграція з апаратурою.
4. Тестування: unit-тести, фаззинг (Echidna), load-test на testnet.
5. Деплой: запуск у mainnet, моніторинг, фіксація багів.

Строки

Повний цикл: від 3 до 4 місяців. Вартість розраховується під ваш проект — зв'яжіться з нами для оцінки.

Технічний стек

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

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