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

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

DePIN (Decentralized Physical Infrastructure Networks) — архітектура де реальне фізичне обладнання (сенсори, роутери, камери, майнери енергії) бере участь у децентралізованій мережі та отримує token-вознаграження за надані послуги. Центральна проблема: як убедитися, що конкретний token-адрес дійсно відповідає реальному фізичному пристрою, а не симулюється програмно?

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

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

Spoofing атака: програмний агент емулює дані фізичного пристрою. GPS координати, показання сенсорів, network metrics — всё це можна синтезувати. Без hardware root of trust програмне spoofing невідрізнюване.

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

Sybil атака: один оператор реєструє сотні "пристроїв", які на справі — віртуальні інстанси на одному сервері. Особливо критично для мереж де вознаграження залежить від кількості нод.

Hardware Root of Trust

Рішення — криптографічний матеріал, що неможливо вилучити з пристрою без його фізичного знищення. Виробничі підходи:

TPM (Trusted Platform Module): стандарт ISO/IEC 11889. Зберігає private key у захищеному енклаві, підписує attestation звіти. Key ніколи не покидає TPM — операції відбуваються всередині чіпа. Підтримується в industrial IoT пристроях (Raspberry Pi 4 має опціональний TPM2.0 через GPIO).

Secure Element (SE): виділений мікроконтролер для криптографічних операцій. Використовується у смарт-картах, eSIM. Helium використовує ECC608 SE для верифікації Hotspot пристроїв.

TEE (Trusted Execution Environment): ARM TrustZone, Intel SGX. Ізольована середовище виконання всередині основного процесора. Дешевше окремого SE, але model атаки складніше (side-channel атаки на SGX задокументовані).

PUF (Physically Unclonable Function): унікальний "fingerprint" мікросхеми, визначений випадковими варіаціями виробничого процесу. Не можна клонувати фізично — кожен чіп дає унікальну відповідь на challenge. Emerging технологія, використовується у спеціалізованих IoT чіпах.

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

Provisioning (первинна реєстрація пристрою)

Виробник → Secure Element provisioning
   ↓
Генерація device keypair всередині SE
(private key ніколи не покидає пристрій)
   ↓
Створення Device Certificate (X.509)
Підписано CA виробника
   ↓
Certificate chain: Root CA → Intermediate CA → Device Cert
   ↓
On-chain реєстрація device публічного ключа + cert fingerprint

Виробник підписує device ідентичність своєю CA. Протокол може верифікувати автентичність пристрою через cert chain без довіри до виробника on-chain — потрібна тільки його CA key у trusted registry.

On-chain Device Registry

contract DeviceRegistry {
    struct Device {
        address owner;           // wallet власника
        bytes32 certFingerprint; // SHA-256 device certificate
        bytes publicKey;         // публічний ключ з SE
        uint256 registeredAt;
        bool active;
    }
    
    mapping(bytes32 => Device) public devices; // deviceId => Device
    mapping(address => bytes32[]) public ownerDevices;
    
    // Trusted список CA виробників
    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 {
        // Верифікація cert chain (спрощено — повна реалізація off-chain)
        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 верифікація роботи

Реєстрація — разова подія. Але пристрій повинен регулярно доводити що він працює та саме цей пристрій відповідає.

// Smart contract видає challenge
async function issueChallenge(deviceId: string): Promise<Challenge> {
  const nonce = crypto.randomBytes(32);
  const timestamp = Math.floor(Date.now() / 1000);
  
  // Записуємо challenge on-chain (або off-chain з підписом оракула)
  await challengeContract.issueChallenge(
    deviceId,
    ethers.utils.keccak256(nonce),
    timestamp + CHALLENGE_EXPIRY
  );
  
  return { nonce: nonce.toString('hex'), expiry: timestamp + CHALLENGE_EXPIRY };
}

// Пристрій підписує challenge своїм SE приватним ключем
// (відбувається на пристрої, не у цьому коді)
function signChallengeOnDevice(challenge: string): string {
  // TPM2.0 PKCS#11 API:
  // const signature = tpm.sign(challenge, keyHandle);
  return signature;
}

// On-chain верифікація
async function submitChallengeResponse(
  deviceId: string,
  nonce: string,
  signature: string
): Promise<boolean> {
  const device = await deviceRegistry.devices(deviceId);
  
  // Відновлюємо ключ що підписав
  const recoveredKey = ethers.utils.recoverPublicKey(
    ethers.utils.hashMessage(nonce),
    signature
  );
  
  return recoveredKey === device.publicKey;
}

Proof of Location

Для DePIN мереж де важлива географічна розподіленість (IoT сенсори, wireless hotspots):

Radio-based proof (Helium підхід): пристрої верифікують місцезнаходження один одного через radio сигнали. Witness: якщо пристрій A чує пристрій B на правдоподібній відстані — верифікація присутності. Атака: вимагає фізично розставити пристрої у потрібні місця, не просто запустити VM.

GPS + TEE attestation: GPS координати підписуються TEE, не можуть бути змінені без фізичного доступу. Проблема: GPS spoofing атаки (особливо для outdoor пристроїв).

Cell tower triangulation + carrier verification: підтвердження місцезнаходження через мобільну мережу. Складніше spoofити, але вимагає SIM / eSIM.

Reward механізм з anti-cheat

contract DePINRewards {
    uint256 constant REWARD_PER_EPOCH = 1e18; // 1 token per epoch
    uint256 constant EPOCH_DURATION = 3600;   // 1 час
    
    struct DeviceStats {
        uint256 lastChallengeTime;
        uint256 successfulChallenges;
        uint256 currentEpoch;
        uint256 epochChallengesRequired; // скільки challenge потрібно в епоху
        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");
        
        // Перевіряємо uptime в епоху
        uint256 uptime = stats.epochChallengesPassed * 100 / stats.epochChallengesRequired;
        require(uptime >= MIN_UPTIME_PERCENT, "Insufficient uptime");
        
        // Reward пропорційно uptime
        uint256 reward = REWARD_PER_EPOCH * uptime / 100;
        
        stats.currentEpoch = currentEpoch;
        stats.epochChallengesPassed = 0;
        
        rewardToken.mint(msg.sender, reward);
    }
}

Staking та Slashing

Щоб збільшити cost of attack: пристрій при реєстрації повинен застейкати токени. При виявленні мошенництва (duplicate key usage, невідповідність claimed даних реальним) — stake slashиться.

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

Часова шкала розробки

Фаза 1 (4-6 тижнів): on-chain device registry, challenge-response протокол, базовий reward механізм.

Фаза 2 (3-4 тижні): staking/slashing, anti-cheat оракул, admin tools.

Фаза 3 (4-6 тижнів): hardware provisioning tooling, firmware SDK для пристроїв, інтеграція з конкретним SE/TPM.

Фаза 4 (2-3 тижні): аудит smart contracts, нагрузкове тестування, testnet deployment.

Повний цикл: 3-4 місяці для production-ready системи. Вартість залежить від типу hardware та target мережі.