Зв’язок і платежі без інтернету

Автономна радіомережа для спілкування, взаємного кредиту та вільного обміну

Уявіть кишеньковий пристрій з екраном і клавіатурою: можна написати сусідові або підготувати оплату покупки там, де немає мобільного зв’язку, Wi-Fi та глобального інтернету. Пристрої зв’язуються через LoRa — радіотехнологію для невеликих повідомлень — і допомагають передавати дані одне одного.

Ми розглядаємо таку мережу як розширення CommonGround. Один пристрій потенційно поєднує особистий месенджер, платіжний термінал і радіоретранслятор. Для спілкування потрібен шлях доставки даних; для платежу — ще й допустимі кредитні відносини та узгоджений фінансовий стан. Ці два шляхи не обов’язково збігаються.

Кишеньковий термінал: три ролі в одному пристрої

Передбачаються невеликий екран, кнопки або цифрова клавіатура, акумулятор і радіомодуль. Термінал зможе зберігати повідомлення та необхідний локальний стан, приймати радіопакети й автоматично пересилати їх далі. Можливі самостійний варіант без смартфона та робота разом зі смартфоном.

Для повідомлення користувач обере адресата, введе текст і підтвердить відправлення. Для покупки — обере продавця, введе суму, перевірить баланс і доступний кредитний ліміт, а потім підпише операцію власним ключем. Інтерфейс має розрізняти «очікує доставки», «перевіряється» та «завершено», щоб відправлення не сприймалося як успішна оплата.

Попередні апаратні кандидати: nRF52840 як контролер переносного пристрою з невеликим енергоспоживанням, SX1262 як LoRa-трансивер; ESP32-S3 — альтернативний контролер для складнішого інтерфейсу або мережевого шлюзу. Це компоненти, які розглядаються, а не затверджена модель. Інформація виробників: Nordic Semiconductor, Semtech, Espressif.

Готові пристрої та самостійне складання

Уже існують готові LoRa-пристрої та модульні набори для Meshtastic. Нижче — приклади можливої апаратної основи: від переносних пристроїв у корпусі до плат для власного складання. Це не готові платіжні термінали CommonGround: сумісні прошивка, інтерфейс і фінансовий протокол ще потребують розроблення та перевірки.

Кожен охочий зможе зібрати власний пристрій з окремих компонентів, дібравши сумісні контролер і LoRa-модуль, антену, акумулятор із відповідною схемою живлення, екран, кнопки або клавіатуру й корпус. Можна почати з модульного набору або спроєктувати власну плату. Для цього потрібні навички складання та налаштування; готової інструкції й перевіреної прошивки CommonGround поки немає. Робочі діапазони антени та радіомодуля мають узгоджуватися між собою й відповідати місцевим правилам радіозв’язку.

Стаціонарні ретранслятори: фірмовий і DIY

Стаціонарний вузол розміщують там, де він добре чує сусідні пристрої: наприклад, на даху або відповідній височині. Йому не обов’язково мати екран і клавіатуру — важливіші антена, надійне живлення, захищений корпус і доступ для обслуговування. Сонячну панель та акумулятор добирають відповідно до споживання енергії, сезону й запасу роботи без сонця; цілодобова автономність не виникає автоматично.

Ці пристрої можуть бути прикладами радіоінфраструктури. Ретранслятор не стає кредитором чи фінансовим посередником лише тому, що пересилає пакет. Сумісність транспорту, налаштування ретрансляції та інтеграцію CommonGround потрібно перевірити окремо.

Mesh: повідомлення йдуть через сусідів

Mesh, або комірчаста мережа, пов’язує пристрої через доступних сусідів. Замість обов’язкового звернення до базової станції оператора повідомлення може пройти кілька радіопереходів. Анна не чує пристрій Гліба безпосередньо, але Борис чує Анну, Віра — Бориса, а Гліб — Віру. Виникає шлях Анна → Борис → Віра → Гліб.

Ретрансляція не потребує дій людини: увімкнені пристрої виконують її автоматично. Вузли можуть з’являтися, вимикатися й переміщуватися; маршрути змінюються. Мережа здатна працювати локально без інтернету, але самоорганізація не гарантує зв’язності. Якщо ланцюжка радіоконтактів немає, негайна доставка неможлива.

Приклад наявного відкритого проєкту автономного LoRa-зв’язку — Meshtastic. Для CommonGround ще належить обрати готовий Mesh-протокол або власний транспорт; сумісність із Meshtastic поки не реалізована.

Дальність та обмеження радіоканалу

Для кишенькових пристроїв варто розглядати широкий орієнтир: від сотень метрів до кількох кілометрів, залежно від місцевості, антени, завад і режиму передавання. У щільній міській забудові стіни та будівлі можуть різко скорочувати дальність. У передмісті й на відкритій місцевості умови зазвичай сприятливіші, а між височинами за прямої видимості можливі десятки кілометрів. Це орієнтири для проєктування, а не результати випробувань нашого пристрою чи обіцянка певної дальності.

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

LoRa підходить насамперед для тексту та компактних службових або фінансових повідомлень. Голосові виклики, фотографії й відео не є цільовим сценарієм. Частоти, потужність і допустима тривалість передавання залежать від країни; апаратну конфігурацію та режим роботи потрібно добирати відповідно до місцевих правил.

Конфігурації мережі та розрахунок дальності платежів

Розгляньмо село та відкриту сільську місцевість. Розрізняймо три типи зв’язку: переносний ↔ переносний — 2 км, переносний ↔ піднятий стаціонарний вузол — 5 км, стаціонарний ↔ стаціонарний — 10 км. Це обрані припущення для порівняння конфігурацій, а не виміряні характеристики чи гарантована дальність. Для стаціонарних вузлів припускаємо вдале розміщення, відповідні антени та сприятливу пряму видимість.

Чому зв’язок зі стаціонарним вузлом може бути дальшим? Піднята антена зменшує вплив перешкод і покращує умови радіолінії; відповідна зовнішня антена може покращити й приймання. Але сам статус «стаціонарний» не збільшує дальності, а більша потужність передавача не гарантує відповіді переносного вузла. Ці чинники пояснює RAKwireless. Числа 2/5/10 км не виведені автоматично з висоти й не є результатом випробувань CommonGround.

Рельєф, лісосмуги, низьке положення антени та завади можуть скоротити зв’язок навіть поза містом. Для конкретного села потрібно задати висоти, антени, режим і рельєф, наприклад у Meshtastic Site Planner, а потім перевірити кожну ланку в обидва боки на місцевості. Схеми показують радіодоставку; кредитні відносини розглянуто окремо далі.

Скільки вузлів може бути в ланцюжку: 5, 9 чи 10?

LoRa як радіотехнологія не має універсальної межі «5–10 пристроїв». Обмеження визначає Mesh-протокол. У Meshtastic стандартний hop_limit = 3, найбільше налаштування — 7. За офіційною схемою підрахунку це бюджет проміжних ретрансляцій: звичайний ланцюжок із трьома пересиланнями містить 5 радіопристроїв, із сімома — 9. Між M пристроями є M − 1 фізичних радіопереходів, але проміжних пересилань лише M − 2. Пряме приймання не потребує пересилання.

10 послідовно необхідних пристроїв потребують 8 пересилань, що перевищує звичайний бюджет Meshtastic. Тому відповідні рядки нижче — геометричний розрахунок для іншого або спеціально спроєктованого транспорту, а не обіцянка роботи стандартної прошивки. Уся розгалужена мережа може містити набагато більше пристроїв: обмежується шлях одного пакета, а не розмір спільноти. Збільшення hop_limit підвищує ефірне навантаження й не гарантує доставки.

Для порівняння, MeshCore описує межу до 64 переходів за однобайтового формату шляху, але його звичайні клієнтські пристрої не ретранслюють повідомлень. Це інший протокол і розподіл ролей, а не автоматична заміна для Mesh лише з пристроїв учасників. Для CommonGround транспорт ще не обрано.

Mesh без виділених ретрансляторів. Увімкнені пристрої учасників автоматично пересилають повідомлення, якщо це дозволяють прошивка й налаштування. Для M пристроїв з однаковим кроком d формула L = (M − 1) × d. Переміщення або вимкнення проміжного пристрою може розірвати шлях; інший маршрут знайдеться лише за достатньої щільності доступних вузлів. Покриття залежить від присутності та заряду учасників.

Ланцюжок із N стаціонарними ретрансляторами має N + 1 радіоперехід. За довжини кінцевих ділянок d і ділянок між ретрансляторами D: L = 2 × d + (N − 1) × D, N ≥ 1. Тут d = 5 км, D = 10 км: один ретранслятор дає 5 + 5 = 10 км, п’ять — 50 км. Це сума довжин ланок, а не радіус покриття: відстань по прямій між A і B не перевищує L і досягає його лише за лінійного розміщення. Усі відстані потребують вимірювань на місцевості.

Платіж не має окремої гарантованої «LoRa-дальності». Крім запиту потрібні зворотні повідомлення й доступ до компонентів, уповноважених узгодити фінансовий стан. Ланцюжок може стати транспортом для платежу між його кінцями, лише якщо працюють усі потрібні двосторонні зв’язки, є допустимий шлях довіри й успішно завершується фінансова перевірка. За розриву маршруту повідомлення може зберегтися для подальшого передавання, а розрахунок залишиться непідтвердженим.

Додавати ретранслятори безмежно не можна: протокол може обмежувати кількість переходів, кожен пакет займає ефір, а перевірки й підтвердження потребують додаткових передач. Перед розгортанням потрібно виміряти зв’язки в обидва боки, затримки та втрати, перевірити висоти антен, навантаження, живлення й допустимі режими. Запасний радіомаршрут може підвищити стійкість, але не створює додаткового кредитного ліміту.

Через шлюзи: Intranet, інтернет, Holochain і CommonGround

Шлюз — пристрій із LoRa-інтерфейсом і доступом до IP-мережі, наприклад невеликий комп’ютер із підключеним радіомодулем. Між шлюзами можна використовувати власну радіомережу Intranet або глобальний інтернет. В обох варіантах кишенькові термінали залишаються в локальних LoRa-мережах.

Варіант 1. Радіомости та приватна Intranet

Intranet — власна внутрішня IP-мережа, яка не обов’язково має вихід до інтернету. Наприклад, спрямовані радіомости пов’язують шлюз G1 із вузлом T на височині, а T — зі шлюзом G2. Це окрема радіомагістраль з обладнанням для передавання IP-даних, а не спроба перетворити звичайні LoRa-модулі на широкосмуговий канал.

Розрахунковий приклад: переносний термінал зв’язується безпосередньо з піднятою LoRa-антеною шлюзу G1 на умовних 5 км; з іншого боку така сама ділянка біля G2. Отримуємо 5 + 10 + 10 + 5 = 30 км уздовж обраної прямої. Відстані радіомостів теж умовні: потрібні відповідні антени, пряма видимість, перевірка рельєфу, завад і допустимих режимів. Тут 10 км припадають на LoRa, 20 км — на IP-радіоканали; їхню суму не можна вважати дальністю одного LoRa-вузла.

Щоб розрахунок міг завершитися без глобального інтернету, в Intranet мають бути доступні необхідні вузли CommonGround/Holochain та уповноважений фінансовий механізм. Потрібно налаштувати локальне виявлення вузлів і перевірити роботу без зовнішніх мережевих сервісів. Якщо в доступній частині мережі немає потрібних повноважень чи актуального стану, платіж чекає узгодження. Ізольований сегмент не отримує права незалежно витратити спільний ліміт удруге. Це проєктована архітектура, не готовий автономний режим.

Варіант 2. Шлюзи через глобальний інтернет

G1 приймає локальне підписане повідомлення та передає його застосунку через інтернет; G2 доставляє дані до іншої LoRa-мережі. Учасникам власний інтернет не обов’язковий, але між шлюзами він потрібен. Цей варіант поєднує радіомережі за межами власної Intranet, наприклад у різних регіонах.

Тут інтернет — транспорт, Holochain — платформа розподіленого застосунку, CommonGround — застосунок із правилами обміну, а Credit Engine — проєктований механізм фінансового виконання. Це різні рівні, а не чотири послідовні радіоретранслятори. Повноцінний вузол застосунку може працювати на шлюзі чи окремому комп’ютері з явно обмеженими повноваженнями. Архітектура Holochain відокремлює клієнтський інтерфейс від вузла застосунку; сама платформа не замінює протоколу узгодженого фінансового розрахунку.

Кожен локальний радіосегмент має власний бюджет пересилань. Зв’язок через інтернет дозволяє поєднати віддалені поселення без безперервного ланцюжка LoRa між ними; географічна відстань уже не визначається радіодальністю одного вузла. Число 500 км на схемі — лише приклад відстані між шлюзами, не довжина мережевого кабелю й не межа Holochain.

Для CommonGround ще потрібно реалізувати двосторонній міст, перевірку підписів, єдиний ідентифікатор операції, захист від повторного застосування, доставку підтверджень і відновлення після розривів. Шлюз не повинен отримувати право довільно змінювати чужі зобов’язання. Звичайне переспрямування пакета або повторне відправлення з новим hop_limit не забезпечує безпечного платежу. За вимкнення інтернету локальне листування може тривати, а міжмережевий розрахунок — чекати зв’язку й фінансового підтвердження. Готова сумісність шлюзів із Holochain/CommonGround не заявляється.

Платіж спирається на мережу довіри

У статті «P2P-фінанси» російською докладно розібрано взаємний кредит та IOU — особисті боргові зобов’язання. Учасники добровільно відкривають кредитні лінії, визначають напрямок довіри, межу боргу та правила використання. Під час розрахунку змінюються баланси конкретних зобов’язань; радіосигнал сам собою грошей не створює.

Анна купує товар у Гліба за 20 розрахункових одиниць. Борис погодився приймати зобов’язання Анни, Віра — Бориса, Гліб — Віри. Якщо поточний стан ліній, доступні ліміти та дозволи це допускають, розрахунок може пройти Анна → Борис → Віра → Гліб. Відправникові не потрібно особисто знати всіх учасників мережі, але довільний ланцюжок знайомств ще не є платіжним маршрутом.

Rippling — узгоджена зміна зобов’язань уздовж такого маршруту. У прикладі без комісій вимога кожного посередника до попереднього учасника та борг перед наступним збільшуються на однакову суму. Сумарний баланс зберігається, але кредитний ризик залишається. Заздалегідь дозволивши Rippling, посередник не мусить особисто підписувати кожну покупку. Дозвіл не замінює перевірки доступної суми та узгодження стану.

Два маршрути: радіозв’язок і фінансові відносини

Варіант А: маршрути збігаються

Радіопакет іде A → B → C → D, і ті самі учасники утворюють фінансовий ланцюжок. Схема проста, підтримує місцевий обмін і потенційно потребує менше транспортних переходів. Проте потрібно одночасно знайти відповідні радіоконтакти та кредитні лінії. Кожен ретранслятор у цьому ланцюжку має бути також фінансовим посередником; розрахунок обмежений фізичною топологією мережі.

Варіант Б: маршрути незалежні

Кредитні відносини пов’язують A → B → C → D, а пакет доставляють пристрої A → R1 → R2 → D. Ретрансляторам R1 і R2 не обов’язково надавати комусь кредит. B і C можуть бути тимчасово відключені від радіомережі й не пересилати пакети цієї покупки.

Це перспективна цільова архітектура: вона дозволяє використовувати ширшу мережу довіри, гнучко розвивати радіопокриття та відокремлювати передачу даних від економічної відповідальності. Але уповноважені фінансові компоненти все одно мають узгодити зміни на лініях B і C. Сама доставка між A і D не дає їм права довільно змінювати чужі баланси.

Що означає «посередник може бути відключений»

Важливо розрізняти п’ять дій:

1. Дозвіл: власник лінії заздалегідь погодив її використання для Rippling.
2. Перевірка місткості: механізм обліку визначив, скільки на ній справді доступно зараз.
3. Резервування: потрібна частина доступної суми захищена від паралельного використання.
4. Узгодження: пов’язані зобов’язання змінено за єдиними правилами, без конфліктних версій.
5. Підтвердження: учасники отримали результат завершеного платежу, який можна перевірити.

Відключеній людині не потрібно повторно давати вже виданий дозвіл. Однак її вимкнений термінал не здатен самостійно перевіряти нові операції. Можливі обмежені делеговані повноваження або попередні резерви — конкретну схему ще належить розробити й випробувати.

Credit Engine — проєктна ідея окремого фінансового компонента: він перевіряє допустимість операцій, веде облік і забезпечує відтворюваність фінансового стану. Транспорт доставляє йому дані, але не замінює його. Якщо зв’язку з уповноваженим механізмом узгодження немає, завершення розрахунку може очікувати відновлення зв’язку.

Чому підпис не розв’язує проблему подвійних витрат

Підпис підтверджує автора й цілісність повідомлення. Він не доводить, що той самий кредитний ліміт не використано в іншому підписаному платежі. Якщо дві ізольовані частини мережі одночасно вважають той самий залишок доступним, обидві можуть прийняти несумісні операції.

Тому потрібні правила виключного права запису, резервів і відновлення після поділу мережі. Класичний Rippling сам собою не забезпечує безпечних розрахунків у цілком ізольованих частинах мережі. Для автономного CommonGround захист від подвійних витрат залишається відкритим технічним завданням.

Store-and-Forward: зберегти й передати пізніше

Store-and-Forward означає «збережи й перешли». Якщо Борис поза зоною зв’язку, проміжний вузол може зберегти адресоване йому зашифроване повідомлення та передати пізніше, коли з’явиться відповідний контакт. Це корисно під час переміщення учасників, вимкнення пристроїв і розривів зв’язку між поселеннями.

Коротка буферизація пакета в оперативній пам’яті відрізняється від стійкого зберігання: для збереження після вимкнення потрібна енергонезалежна пам’ять, а також правила строку зберігання, видалення й захисту повідомлень. Ці механізми ще потрібно дослідити. Наявний модуль Store & Forward у Meshtastic — приклад конкретної реалізації зберігання повідомлень, а не готове рішення фінансового узгодження CommonGround.

Store-and-Forward доставляє інформацію, але сам собою не завершує розрахунок і не захищає від подвійних витрат. Навіть доставлене підписане платіжне повідомлення може очікувати фінансового підтвердження.

Захист повідомлень і приватність

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

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

Як це пов’язано з CommonGround і Holochain

Holochain — основа розподіленого застосунку CommonGround, а LoRa Mesh розглядається як додатковий транспорт для обмеженого обсягу даних. Робота повного Holochain безпосередньо на nRF52840 не припускається як підтверджена можливість.

Один із підходів: термінали зберігають власні ключі й обмежені дані, передають повідомлення та підписані операції; шлюзи пов’язують радіомережу з повноцінними вузлами CommonGround. За наявності інтернету чи іншого відповідного зв’язку дані синхронізуються з основною мережею. Credit Engine залишається окремим від радіотранспорту компонентом, а завершення операцій потребує перевіреної моделі узгодженості.

Таке розширення могло б підтримувати зовнішній обмін в Економіці Участі, зберігаючи відмінність між P2P-боргами та внутрішніми капітальними рахунками організацій.

Три історії застосування

За межами мобільного покриття. Кілька мешканців сільської місцевості обмінюються короткими повідомленнями. Пристрої сусідів автоматично передають пакети. Якщо безперервного шляху немає, повідомлення очікує наступного контакту.

На місцевому ринку. Покупець обирає продавця, вводить суму й підписує повідомлення. Термінал показує «доставлено», потім «очікує фінансового підтвердження». Продавець вважає платіж завершеним лише після передбаченого протоколом підтвердження, а не за фактом отримання пакета.

Між поселеннями. Стаціонарні ретранслятори на височинах поєднують кілька радіопереходів. Мобільний оператор на кожній ділянці не потрібен; реальне покриття, навантаження та живлення все одно слід перевіряти на місцевості.

Стан розроблення

Строк випуску не призначено. Наступні кроки — обрати транспорт і апаратну платформу, перевірити модель фінансового виконання, зібрати прототип та випробувати доставку, автономність і відновлення після розривів зв’язку. Працездатне радіолистування та безпечний платіж мають підтверджуватися окремо.

Продовжити читання: P2P-фінанси російською, стан розроблення російською, репозиторій CommonGround, вихідний код інформаційного сайту.

Технічний приклад Rippling: офіційна документація XRP Ledger. Це довідковий приклад іншого протоколу; він не означає вибір XRP Ledger або токена XRP для CommonGround.