Типова ситуація: у вас є ідея децентралізованої мережі — LoRaWAN, WiFi або 5G. Ви хочете, щоб незалежні оператори розгортали точки доступу та заробляли за покриття. Перевірити, що антена дійсно стоїть у вказаному місці та не підключена до симулятора — нетривіальне завдання. Ми проєктуємо такі мережі з нуля: від концепції токеноміки до прошивки заліза. Замовте розробку вашої децентралізованої мережі — ми реалізуємо проєкт під ключ.
Helium Network довів, що модель працює: більше 900k хотспотів по всьому світу, покриття 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
Перші версії були вразливі до gaming: оператори створювали віртуальні hotspot кластери через GPS spoofing, доповідаючи про взаємні witness'и. Helium виправляв це ітераційно:
- Відстань між hotspots < 300m → reward нульовий (занадто близько, неефективне покриття)
- Hexagonal density-based rewards (H3 library, Uber) — у насиченому гексагоні HIP-83 знижує rewards
- Entropy з блокчейну для випадкового вибору 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 дані не можна напряму писати в смарт-контракт — занадто дорого (кожен 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).
Порівняння coverage технологій
| Технологія | Дальність (км) | Пропускна здатність | Типовий юзкейс | Підтримка блокчейн |
|---|---|---|---|---|
| LoRaWAN | до 15 | 0.3-50 kbps | IoT, датчики | Helium, Mysterium |
| WiFi | 0.1-0.3 | до 1 Gbps | Широкосмуговий доступ | XNET, Althea |
| 5G/CBRS | 0.5-3 | до 10 Gbps | Мобільний зв'язок | Pollen Mobile |
Токеноміка: стимули та 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 заради throughput та вартості. PoC-based networks генерують величезний обсяг мікротранзакцій — Ethereum L1 непридатний. Solana забезпечує пропускну здатність у 650 разів вищу за Ethereum L1 (65k vs ~100 TPS), що критично для масштабування. Варіанти для нового проєкту:
| Блокчейн | Переваги | Недоліки |
|---|---|---|
| Solana | 65k TPS, ~$0.0001/tx | Централізація валідаторів |
| Polygon PoS | EVM-сумісність, зрілість | ~$0.01/tx при навантаженні |
| Arbitrum | EVM + low cost | Sequencer centralization |
| Celestia DA + rollup | Мінімальний DA cost | Складність |
| Власний chain | Повний контроль | Bootstrapping security |
Контракти винагород
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.
Приклад налаштування PoC агента: для LoRaWAN hotspot на Raspberry Pi встановіть пакет helium-gateway, сконфігуруйте GPS та налаштуйте регіон у файлі /opt/helium/config/region.toml. Після цього device автоматично почне брати участь у challenge-response.
Процес розробки
| Етап | Тривалість | Результат |
|---|---|---|
| Дослідження | 2-4 тижні | Вибір radio технології, аналіз регуляцій, модель монетизації |
| PoC дизайн | 2-4 тижні | Протокол challenge-response, oracle архітектура, anti-gaming |
| Smart contracts | 4-6 тижнів | Token, reward distribution (Merkle), governance, Data Credits |
| Oracle інфраструктура | 4-8 тижнів | PoC collector, aggregator, on-chain updater |
| Hardware SDK | 4-8 тижнів | PoC agent, secure provisioning, firmware update |
| Testnet → Mainnet | 2-4 місяці | Закритий тест з реальним hardware → відкритий → mainnet |
Що входить у розробку?
- Токеноміка та смарт-контракти: проектування dual-token моделі, написання контрактів на Solidity/Rust з формальною верифікацією.
- Oracle інфраструктура: розгортання PoC aggregator, Merkle tree builder, моніторинг подій.
- Hardware SDK: прошивка для цільового заліза, TEE-атестація, secure provisioning flow.
- Документація: архітектурні decision records, API-специфікації, гайди для операторів.
- Техпідтримка: допомога в запуску testnet, інтеграція з хардвером, навчання команди.
Орієнтири за термінами
MVP з симульованим PoC (без реального RF) для демонстрації токеноміки — 2-3 місяці. Повноцінна система з реальним hardware attestation, oracle інфраструктурою, anti-gaming — 6-12 місяців. Вартість MVP починається від кількох десятків тисяч, повноцінна система — від кількох сотень тисяч. Це один з найбільш технічно складних Web3 проєктів: вимагає expertise в blockchain, RF engineering, hardware security та distributed systems одночасно. Порівняно з централізованими рішеннями, децентралізована мережа дозволяє скоротити CAPEX на 40-60% та підвищити відмовостійкість. Економія на операційних витратах досягає 30% за рахунок автоматизації виплат та відсутності єдиного оператора. Децентралізована мережа знижує капітальні витрати в 1.5-2.5 рази порівняно з централізованою.
Зв'яжіться з нами для детального обговорення вашого проєкту. Ми оцінимо ваше завдання та запропонуємо оптимальну архітектуру. Отримайте консультацію з архітектури Proof of Coverage.