Розробка децентралізованої мережі бездротового зв'язку

Розробка децентралізованої мережи беспроводной зв'язку

Helium Network довів, що модель працює: більше 900k hotspots по світу, покриття LoRaWAN та 5G, забезпечене незалежними операторами, що заробляють токени за реальне радіо покриття. Але Helium — це конкретна реалізація одної ідеї. Існують й інші архітектурні підходи: XNET (WiFi offload), Althea (mesh networking з автоматичними мікроплатежами), Pollen Mobile (5G Citizens Broadband).

Що об'єднує всі проекти: потрібно вирішити завдання Proof of Coverage — доказати on-chain, що фізичне залізо дійсно забезпечує беспроводне покриття у заявленому місці. Без надійного PoC токени можна отримати, поставивши антену у шкаф.

Proof of Coverage: ключова технічна проблема

Helium-підхід: RF challenge-response

Helium використовує challenge-response: один Hotspot (Challenger) ініціює challenge, інший (Transmitter) передає RF сигнал, треті (Witnesses) незалежно приймають та підтверджують. Всі три ролі змінюються випадково. Сенс: не можна підробити без реальної фізичної близькості.

Helium PoC flow:
1. Challenger → Transmitter: encrypted challenge payload (LoRa packet)
2. Transmitter → RF повітря: broadcasts challenge (915 MHz або 868 MHz)
3. Witnesses: незалежно приймають сигнал, вимірюють RSSI/SNR
4. Witness → Oracle: звіт {transmitter_id, rssi, snr, frequency, timestamp}
5. Oracle: верифікує timing, консистентність RSSI з відстанню
6. Reward: transmitter + witnesses отримують HNT по proof score

Проблеми Helium PoC v1 та їх рішення. Перші версії були уязвимі до gaming: оператори створювали віртуальні hotspot кластери через GPS spoofing, докладаючи про взаємні witness'и. Helium исправляв це ітеративно:

• Відстань між hotspots < 300m → reward нульовой (неефективне покриття)
• Hexagonal density-based rewards (H3 library, Uber) — HIP-83 снижує rewards у насиченому гексагоні
• Entropy з Solana blocktime для випадкового вибору challenger (не можна передбачити)

Альтернативний підхід: GPS + криптографічна аттестація

Для WiFi/5G мереж RF challenge неприменим напрямку (інші частоти, протоколи). Замість цього: hardware з TEE або спеціалізованим secure element.

Архітектура secure hardware attestation:
1. Device: ARM TrustZone або Intel SGX всередину точки доступу
2. TEE підписує: {gps_coordinates, timestamp, cell_id, connected_devices_count}
3. Підпис неможливо підробити без фізичного доступу до hardware
4. Oracle верифікує підпис через attestation certificate ланцюжок
5. On-chain: лише hash + підпис (приватність GPS координат)

Приклад: XNET використовує кастомні WiFi точки доступу зі вбудованим secure element. Реальна статистика трафіку (bytes transmitted, unique devices connected) стає Proof of Coverage.

Оракульна інфраструктура для PoC

PoC дані не можна писати напрямку у смарт-контракт — занадто дорого (кожен hotspot репортує кожні кілька хвилин). Стандартна архітектура:

Data flow:
Hotspot → PoC API (off-chain) → Oracle aggregator → L1 контракт (rewards)

Oracle aggregator:
- Збирає PoC звіти за epoch (зазвичай 1-24 години)
- Формує Merkle tree всіх rewards
- Публікує Merkle root on-chain
- Hotspot operator claimit reward, доказуючи inclusion у Merkle tree

Це паттерн «optimistic oracle»: дані приймаються як достовірні якщо нема challenge у dispute window. Економія gas: замість N транзакцій — одна (Merkle root update) + N claim транзакції (оператор платить за свій reward).

Токеноміка: стимули та anti-gaming

Dual-token модель

Helium перейшов на dual-token: HNT (utility/governance) + IOT/MOBILE (subnet-specific reward tokens). Логіка: різні subnet'и (LoRa vs 5G) мають різні ринки та утиліту. Конвертація: burn IOT/MOBILE → mint HNT (burn-and-mint модель).

// Спрощена burn-and-mint механіка
contract SubnetToken {
    IHNTToken public hnt;
    uint256 public burnRatio; // IOT за HNT
    
    function burnForHNT(uint256 subnetAmount) external {
        _burn(msg.sender, subnetAmount);
        uint256 hntAmount = subnetAmount / burnRatio;
        hnt.mint(msg.sender, hntAmount);
    }
}

Data Credits: стабільна оплата

Проблема: якщо оператор платить за передачу даних у нативному токені, а токен волатильний — передбачити вартість неможливо. Рішення Helium: Data Credits (DC). DC = $0.00001 фіксовано, створюються спаленням HNT (по поточному курсу). Користувач платить за дані у DC — стабільна вартість. HNT спалюється → дефляційне тиск.

Anti-gaming механізми у reward schedule

Reward scaling по плотності. Hexagonal grid (H3 resolution 8, ~0.7 km²): якщо у гексагоні N hotspots, кожен отримує 1/N від базового reward. Стимулює deployment у незакритих зонах.

Witness validity decay. Hotspot, що witnesses занадто багато раз одні й ті ж transmitters з ідеальним RSSI — підозрілий. HIP-83 вводит decay factor для повторяючих witness пар.

Transmit scale. Hotspot з високою плотністю сусідів отримує transmit_scale < 1.0, що снижує reward witnesses за його сигнал. Децентралізований market pressure проти clustering.

Архітектура смарт-контрактів

Helium мігрував на Solana (2023) для throughput та вартості. PoC-based мережи генерують величезний обсяг мікротранзакцій — Ethereum L1 непридатний. Варіанти для нового проекту:

Контракти вознаграджень

contract CoverageRewards {
    bytes32 public merkleRoot;
    mapping(bytes32 => bool) public claimed;
    
    // Oracle оновлює root кожен epoch
    function updateMerkleRoot(bytes32 newRoot) external onlyOracle {
        merkleRoot = newRoot;
        emit EpochSettled(block.number, newRoot);
    }
    
    // Оператор claimit reward, доказуючи inclusion
    function claimReward(
        address operator,
        uint256 amount,
        bytes32[] calldata proof
    ) external {
        bytes32 leaf = keccak256(abi.encodePacked(operator, amount));
        require(!claimed[leaf], "Already claimed");
        require(MerkleProof.verify(proof, merkleRoot, leaf), "Invalid proof");
        claimed[leaf] = true;
        _mint(operator, amount);
    }
}

Hardware та firmware

Це не тільки blockchain проект — потрібне фізичне залізо. Мінімальний стек:

LoRaWAN hotspot: Raspberry Pi CM4 + RAK2287 LoRa HAT + GPS модуль (u-blox M8N). Прошивка: packet forwarder + PoC agent (Go або Rust). TPM 2.0 чип для hardware attestation.

5G small cell: Baicells Nova 430 або CBRS-certified гарнітура + кастомний PoC агент. CBRS (Citizens Broadband Radio Service, 3.5 GHz у США) — лицензійний спектр через Spectrum Access System.

Secure provisioning: factory attestation при виробництві. Кожен device отримує unique keypair у TEE на фабриці. Public key реєструється on-chain як device identity. Поддельний device без TEE-ключа не може заробити reward.

Процес розробки

Дослідження (2-4 тижні). Вибір radio technology (LoRa, WiFi, 5G/CBRS), цільова географія та регуляції (частотні діапазони різняться: 868 MHz EU, 915 MHz US), модель монетизації.

PoC дизайн (2-4 тижні). Ключовой етап. Проектуємо challenge-response протокол, oracle архітектуру, anti-gaming механізми. Формалізуємо reward formula.

Smart contracts (4-6 тижнів). Token (ERC-20 або Solana SPL), reward distribution (Merkle), governance (якщо потрібен), Data Credits механізм.

Oracle інфраструктура (4-8 тижнів). PoC collector, aggregator, Merkle tree builder, on-chain updater. Це production-grade backend, не прототип.

Hardware SDK (4-8 тижнів). PoC agent для цільового hardware, secure provisioning flow, firmware update механізм.

Testnet + mainnet (2-4 місяці). Закритий testnet з реальним hardware → відкритий testnet з early adopters → mainnet. На кожному етапі — мониторинг gaming attempts та ітерація PoC.

Ориентири по срокам

MVP з симульованим PoC (без реального RF) для демонстрації токеноміки — 2-3 місяці. Повноцінна система з реальним hardware attestation, oracle інфраструктурою, anti-gaming — 6-12 місяців. Це один з найтехнічно складних Web3 проектів: вимагає експертизи у blockchain, RF engineering, hardware security та distributed systems одночасно.