Разработка децентрализованной сети беспроводной связи

Разработка децентрализованной сети беспроводной связи

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

Что объединяет все эти проекты: нужно решить задачу Proof of Coverage — доказать on-chain, что физический hardware действительно обеспечивает беспроводное покрытие в заявленном месте. Без надёжного 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 air: broadcasts challenge (915 MHz или 868 MHz)
3. Witnesses: независимо принимают сигнал, измеряют RSSI/SNR
4. Witness → Oracle: report {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 + cryptographic attestation

Для WiFi/5G сетей RF challenge неприменим напрямую (другие частоты, протоколы). Вместо этого: hardware с Trusted Execution Environment (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 contract (rewards)

Oracle aggregator:
- Собирает PoC reports за epoch (обычно 1-24 часа)
- Вычисляет Merkle tree всех rewards
- Публикует Merkle root on-chain
- Hotspot operator клеймит 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). Логика: разные субсети (LoRa vs 5G) имеют разные рынки и разную utility. Конвертация: burn IOT/MOBILE → mint HNT (модель burn-and-mint).

// Simplified burn-and-mint mechanic
contract SubnetToken {
    IHNTToken public hnt;
    uint256 public burnRatio; // IOT per 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. Стимулирует деплой в незакрытых зонах.

Witness validity decay. Hotspot, который witnesses слишком много раз одни и те же передатчики с идеальным RSSI — подозрителен. Helium HIP (Helium Improvement Proposal) 83 вводит decay factor для повторяющихся witness пар.

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

Смарт-контрактная архитектура

Helium мигрировал на Solana (2023) ради throughput и стоимости. PoC-based networks генерируют огромный объём микротранзакций — 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);
    }
    
    // Оператор клеймит 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 проект — нужен физический hardware. Минимальный стек:

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), целевая geography и регуляции (частотные диапазоны различаются: 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 mechanism.

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 месяцев. Это one of самых технически сложных Web3 проектов: требует expertise в blockchain, RF engineering, hardware security и distributed systems одновременно.