Project Expanse: автономні децентралізовані мережі — формування дослідницької групи
Black Roses | Project Expanse | Дослідницька програма 2027
Вступ. Інфраструктура, яка повинна пережити власну ізоляцію
Сучасний Інтернет створює враження глобальної та майже безперервної комунікаційної системи. Однак за цією доступністю стоїть складна інфраструктура операторів, магістральних каналів, центрів обробки даних, систем маршрутизації, DNS, хмарних платформ і централізованих сервісів.
Відмова окремих компонентів, пошкодження фізичної інфраструктури, блокування каналів зв'язку, перебої електропостачання або адміністративні обмеження можуть зробити значну частину цифрових сервісів недоступною.
Проблема полягає не лише у втраті доступу до глобальної мережі. Разом із ним користувач може втратити можливість обмінюватися повідомленнями, отримувати документи, користуватися локальними сервісами, синхронізувати дані та взаємодіяти з іншими учасниками.
Традиційна модель підключення передбачає наявність доступного зовнішнього середовища. Але що відбувається, коли цього середовища більше немає?
Саме це питання стає відправною точкою дослідницької програми Black Roses / Project Expanse.
Ми розглядаємо mesh-мережі не як чергову альтернативу Wi-Fi або спосіб організувати локальний бездротовий зв'язок. Нас цікавить значно ширше завдання: створення автономної, гетерогенної та децентралізованої комунікаційної інфраструктури, яка зберігає практичну корисність навіть за умов тривалої ізоляції, втрати частини вузлів і деградації фізичних каналів.
1. Від mesh-мережі до AHDN
У межах дослідження ми використовуємо робочу назву AHDN — Autonomous Heterogeneous Decentralized Network.
Це концепція автономної гетерогенної децентралізованої мережі, побудованої на взаємодії декількох технологічних рівнів.
Її основні властивості:
відсутність залежності від одного оператора або центрального сервера;
підтримка декількох незалежних фізичних каналів зв'язку;
можливість автоматичного відновлення маршрутів;
передавання повідомлень за відсутності постійного наскрізного з'єднання;
збереження локальних цифрових сервісів;
розподілене зберігання та реплікація інформації;
криптографічний захист комунікацій;
можливість автономного функціонування окремих сегментів.
Важливо розуміти: AHDN поки що є дослідницькою архітектурою, а не готовим програмним продуктом або стандартизованим мережевим протоколом.
Ми не ставимо за мету винаходити ще один універсальний протокол. Натомість досліджуватимемо можливості інтеграції вже наявних відкритих технологій, визначатимемо межі їхньої сумісності та перевірятимемо практичну працездатність запропонованих рішень.
2. П'ять основних напрямків дослідження
2.1. Self-Healing Networks — мережі з автоматичним відновленням
Звичайна мережа часто залежить від заздалегідь визначених маршрутів та доступності певних вузлів.
У динамічній mesh-мережі така залежність стає проблемою. Вузли можуть переміщуватися, втрачати живлення, виходити з ладу або тимчасово втрачати зв'язок із сусідами.
Мережа повинна самостійно виявляти зміни топології та перебудовувати маршрути.
Основні завдання дослідження:
виявлення недоступних вузлів;
оцінювання якості каналів;
автоматичний вибір альтернативних маршрутів;
запобігання маршрутним петлям;
відновлення зв'язності після повернення вузлів;
мінімізація втрат даних під час перебудови мережі.
Окрема увага приділятиметься Babel — протоколу динамічної IP-маршрутизації, який розроблений для дротових і бездротових мереж, зокрема з мінливою топологією.
Водночас автоматичне відновлення маршруту не означає автоматичного відновлення сервісу. Якщо дані або застосунок були доступні лише на втраченому вузлі, потрібні окремі механізми реплікації та резервування.
2.2. Delay-Tolerant Networking — передавання даних без постійного з'єднання
Це один із центральних напрямків програми.
Delay-Tolerant Networking (DTN) призначений для мереж, у яких зв'язок може бути переривчастим, затримки — значними, а наскрізна передача даних — тимчасово неможливою.
Основний принцип — Store-Carry-Forward.
Вузол отримує повідомлення, зберігає його, переносить або очікує на появу доступного каналу, після чого передає далі.
Таким чином, для доставки інформації не обов'язково мати безперервне з'єднання між відправником та одержувачем.
Технологічною основою для дослідження є Bundle Protocol Version 7, визначений у RFC 9171.
Цей стандарт дозволяє організувати доставку даних у складних мережевих середовищах, де традиційні припущення про постійний IP-зв'язок не виконуються.
Окремий інтерес становить RFC 9675 — архітектура керування DTN, яка враховує асинхронність, автономне локальне управління та обмежені ресурси пристроїв.
Практичні завдання:
організація черг повідомлень;
збереження даних під час відсутності зв'язку;
передавання інформації між ізольованими сегментами;
контроль термінів зберігання;
перевірка цілісності;
обробка повторної доставки;
синхронізація після відновлення з'єднання.
DTN не слід плутати зі звичайним кешуванням або передаванням файлів. Це окрема архітектура доставки інформації.
2.3. Heterogeneous Mesh — об'єднання різних фізичних каналів
Один із найбільш перспективних напрямків — створення мережі, яка не залежить від одного типу фізичного з'єднання.
Для цього досліджуватиметься взаємодія:
Wi-Fi та Wi-Fi Mesh;
Ethernet;
LoRa;
пакетного радіозв'язку;
мобільних каналів;
супутникового зв'язку;
оптоволоконних і магістральних мереж.
Кожен транспорт має власні характеристики.
Wi-Fi та Ethernet забезпечують відносно високу пропускну здатність. LoRa дозволяє передавати невеликі обсяги даних на значні відстані з низьким енергоспоживанням. Супутниковий зв'язок може забезпечувати зовнішній канал для віддалених сегментів. Радіоканали дають можливість створювати незалежні фізичні маршрути.
Головне завдання — зробити так, щоб різні фізичні середовища могли обслуговувати спільний логічний комунікаційний простір.
Особливу увагу буде приділено Reticulum Network Stack. Цей відкритий мережевий стек підтримує роботу з різнорідними інтерфейсами, включно з Ethernet, Wi-Fi, послідовними каналами та LoRa через сумісне обладнання.
Також досліджуватиметься Yggdrasil — децентралізована IPv6 overlay-мережа.
Принципова різниця між ними полягає в архітектурі та способі взаємодії з транспортами. Їх не можна вважати взаємозамінними компонентами або просто об'єднати встановленням на один пристрій.
Потрібно перевірити, які сценарії допускають паралельну роботу, а де необхідні спеціальні шлюзи та механізми передачі даних між мережами.
Окремо досліджуватиметься Meshtastic як готова система для експериментів із малопотужними LoRa-мережами.
Важливе уточнення: LoRa — це технологія радіомодуляції, LoRaWAN — мережевий протокол, а Meshtastic реалізує власну mesh-логіку. Типова LoRaWAN-архітектура не є mesh-топологією.
2.4. Autonomous Routing — адаптивна маршрутизація
Наступний напрямок стосується інтелектуального управління мережею.
У традиційних алгоритмах маршрутизації використовуються визначені метрики: кількість переходів, вартість каналу, затримка, доступність та інші параметри.
Але в автономній гетерогенній мережі ситуація складніша.
Маршрут може бути швидким, але енергетично дорогим. Інший канал може мати низьку пропускну здатність, але залишатися доступним значно довше. Третій може бути перевантаженим або нестабільним.
У перспективі ми плануємо дослідити:
адаптивне оцінювання якості каналів;
врахування енергетичного стану вузлів;
динамічне балансування навантаження;
прогнозування деградації зв'язку;
алгоритми вибору маршрутів;
можливості Multi-Agent Reinforcement Learning.
Однак використання машинного навчання не є першочерговим завданням.
Спочатку необхідно отримати вимірювані результати роботи традиційних алгоритмів. Лише після цього можна оцінювати, чи дають адаптивні моделі реальну перевагу.
2.5. Privacy-Preserving Infrastructure — приватність на рівні архітектури
Децентралізація не гарантує приватності автоматично.
Зашифрований канал не обов'язково приховує мережеву топологію, метадані, факт участі конкретного вузла або характер передавання інформації.
Тому дослідження включатиме:
криптографічну ідентифікацію вузлів;
автентифікацію учасників;
керування ключами;
ротацію та відкликання ключів;
захист від підміни вузлів;
протидію Sybil-атакам;
обмеження можливостей спостереження за трафіком;
сегментацію та ізоляцію скомпрометованих компонентів.
Окремо розглядатиметься I2P як інструмент створення приватних overlay-сервісів.
Водночас ми не будемо ототожнювати шифрування, приватність та анонімність. Жодна з цих властивостей не є абсолютною, а захист від аналізу трафіку залежить від моделі загроз та умов використання.
3. Технологічна база досліджень
На першому етапі ми визначаємо такі основні компоненти.
Yggdrasil
Децентралізована IPv6 overlay-мережа. Досліджуватиметься як основа логічної IP-зв'язності між вузлами та доступу до локальних IP-сервісів.
Reticulum
Мережевий стек для роботи з різнорідними каналами. Один із головних кандидатів для експериментів із гетерогенним транспортом та автономними комунікаціями.
Babel
Стандартизований протокол IP-маршрутизації. Розглядатиметься для побудови та відновлення IP-маршрутів у відповідних сегментах.
DTN / Bundle Protocol v7
Основа для асинхронної доставки повідомлень у мережах із переривчастим з'єднанням.
Meshtastic
Практичний інструмент для експериментів із LoRa, малопотужними радіовузлами та багатовузловою передачею повідомлень.
IPFS
Розподілена система адресування та обміну контентом. Досліджуватиметься як механізм локального зберігання, реплікації та перевірки цілісності документів.
Для забезпечення тривалої доступності контенту необхідно передбачити постійне зберігання даних на декількох вузлах. Сам факт публікації файлу в IPFS не гарантує його безстрокової доступності.
I2P
Приватна overlay-мережа для дослідження захищеного доступу до сервісів та обмеження можливостей спостереження за комунікаціями.
Цей перелік не є остаточним технологічним стеком. Кожен компонент проходитиме оцінювання за функціональністю, сумісністю, безпекою, ресурсними вимогами та реальними результатами випробувань.
4. Архітектура майбутньої системи
Для систематизації досліджень пропонуємо п'ятирівневу модель.
Рівень 1. Обчислювальна інфраструктура
Фізичні вузли, мінікомп'ютери, маршрутизатори, сервери, накопичувачі, автономне живлення та системи моніторингу.
Рівень 2. Фізичні канали
Wi-Fi, Ethernet, LoRa, радіозв'язок, супутникові канали та інші сумісні засоби передавання даних.
Рівень 3. Транспорт і доставка
Механізми передавання пакетів, DTN, буферизація, повторна доставка та синхронізація.
Рівень 4. Мережевий рівень
IPv6, Yggdrasil, Babel, Reticulum та механізми взаємодії між різними мережевими середовищами.
Рівень 5. Локальні цифрові сервіси
Обмін повідомленнями, розподілені сховища, локальні каталоги, DNS, документація, інформаційні ресурси та інші застосунки.
Це концептуальна модель. Конкретний спосіб розміщення протоколів та сервісів буде визначатися експериментами.
5. Головна дослідницька гіпотеза
Ми пропонуємо перевірити таке твердження:
Локальна цифрова інфраструктура може залишатися функціонально корисною навіть після втрати зовнішнього Інтернету, частини фізичних каналів та окремих мережевих вузлів, якщо вона використовує поєднання автономної маршрутизації, DTN, розподіленого зберігання та локальних сервісів.
Для перевірки буде створено лабораторний експериментальний стенд.
Початковий сценарій:
декілька фізично або логічно розділених мережевих сегментів;
локальні вузли з власними сервісами;
наявність зовнішнього Інтернету на початку експерименту;
повне відключення зовнішнього каналу;
контрольована втрата частини вузлів;
деградація окремих транспортів;
переміщення одного з мобільних вузлів;
відновлення зовнішнього зв'язку та синхронізація.
У межах експерименту перевірятиметься не просто наявність мережевого з'єднання, а можливість виконувати конкретні користувацькі завдання.
Чи може користувач знайти локальний сервіс? Чи може відправити повідомлення? Чи отримає документ, який зберігається на іншому вузлі? Чи зможе передати інформацію між сегментами, які не мають постійного прямого з'єднання? Чи відновиться синхронізація після повернення каналу?
Саме ці результати будуть критерієм успішності.
6. Робоча група: структура та завдання
Ми започатковуємо формування дослідницької робочої групи Black Roses / Project Expanse.
Її завдання — не просто стежити за новинами технологічного сектору, а формувати незалежну, систематизовану та практично корисну базу знань про автономні децентралізовані мережі.
Робоча група повинна стати точкою координації досліджень, технічної документації, експериментів та обміну знаннями між окремими учасниками й проєктами.
Основні функції групи
Моніторинг технологій, стандартів, наукових публікацій та відкритих програмних проєктів.
Перевірка актуальності документації, версій і технічних можливостей.
Аналіз сумісності різних мережевих компонентів.
Підготовка технічних оглядів та порівнянь.
Розробка експериментальних сценаріїв.
Документування результатів випробувань.
Формування відкритої бази знань.
Підготовка рекомендацій для інших децентралізованих ініціатив.
Куратори напрямків
Для уникнення хаотичного накопичення інформації пропонується розподілити роботу за тематичними напрямками.
Куратор мережевої архітектури
Відповідає за Yggdrasil, Reticulum, Babel, IPv6, топології та сумісність мережевих стеків.
Куратор радіотехнологій і транспортів
Досліджує Wi-Fi Mesh, LoRa, Meshtastic, Ethernet, радіоканали та супутникові засоби зв'язку.
Куратор DTN і доставки даних
Відповідає за Bundle Protocol, асинхронну передачу, буферизацію, синхронізацію та механізми відновлення доставки.
Куратор розподілених сервісів і сховищ
Досліджує IPFS, реплікацію, локальні сервіси, edge-інфраструктуру та збереження цифрових ресурсів.
Куратор безпеки та приватності
Вивчає криптографію, моделі довіри, керування ключами, I2P, загрози та методи захисту.
Куратор досліджень і тестування
Формує експериментальні сценарії, методики вимірювання, порівняльні таблиці та звіти про результати.
Куратори не повинні перетворюватися на власників окремих технологій або закритих інформаційних напрямків. Їхня роль — координувати дослідження, перевіряти твердження, підтримувати документацію та забезпечувати передачу знань іншим учасникам.
Одна людина може тимчасово виконувати декілька ролей. Важливіше забезпечити відповідальність за результат, ніж створити формальну організаційну структуру.
7. Як працюватиме база знань
Ми хочемо, щоб результати роботи групи не залишалися всередині вузького кола розробників.
Тому кожен дослідницький напрямок повинен мати власну документацію.
Для кожної технології передбачатимуться:
опис призначення та архітектури;
актуальна версія;
офіційна документація;
стан розробки;
підтримувані платформи;
вимоги до обладнання;
відомі обмеження;
проблеми сумісності;
результати тестування;
оцінка безпеки;
практичні сценарії використання.
Кожне твердження повинно мати зрозумілий статус:
Підтверджено — перевірено за документацією, стандартом або відтворюваним експериментом.
Експериментально — отримано результат у конкретному тестовому середовищі, але ще не підтверджено в інших умовах.
Гіпотеза — перспективне припущення, яке потребує перевірки.
Не підтверджено — інформації недостатньо для обґрунтованого висновку.
Спростовано — твердження суперечить перевіреним даним або результатам випробувань.
Цей підхід дозволить не перетворити базу знань на збірник рекламних описів технологій.
Ми зацікавлені не в тому, щоб доводити переваги певного програмного забезпечення. Ми хочемо встановлювати, де, за яких умов і з якими обмеженнями воно справді працює.
8. План досліджень на 2027 рік
Перший етап. Архітектура та лабораторний прототип
Визначення сумісності основних компонентів, створення тестового середовища, розгортання мережевих вузлів та локальних сервісів.
Першочергове завдання — перевірити базову взаємодію Yggdrasil, Reticulum та локальної IP-інфраструктури.
Другий етап. Автономна доставка даних
Дослідження DTN, механізмів збереження повідомлень, повторної доставки та передачі даних між сегментами з переривчастим зв'язком.
Третій етап. Гетерогенні транспорти
Підключення додаткових фізичних каналів, дослідження LoRa, Wi-Fi Mesh, радіозв'язку та механізмів взаємодії між транспортами.
Четвертий етап. Розподілені сервіси
Інтеграція IPFS, локальних сховищ, реплікації документів та автономних інформаційних сервісів.
П'ятий етап. Безпека та польові випробування
Перевірка відмовостійкості, енергоспоживання, захисту вузлів, доступності сервісів та відновлення після втрати каналів.
Послідовність може коригуватися залежно від результатів попередніх етапів. Ми не будемо оголошувати завершення етапу лише тому, що настав календарний дедлайн.
9. Як вимірюватимемо результати
Дослідницька програма повинна спиратися на вимірювані показники.
Основні метрики:
час відновлення мережевої зв'язності;
частка успішно доставлених повідомлень;
затримка доставки;
пропускна здатність окремих каналів;
доступність локальних сервісів;
втрати даних;
час відновлення синхронізації;
енергоспоживання вузлів;
стійкість до втрати окремих компонентів;
поведінка мережі під час ізоляції сегментів.
Для кожного експерименту фіксуватимуться конфігурація, програмні версії, обладнання, умови тестування та отримані результати.
Це необхідно, щоб інші дослідники могли повторити експеримент і незалежно перевірити висновки.
10. Кому буде корисна ця робота
Ми не обмежуємо дослідження лише власною інфраструктурою.
Результати можуть бути корисними:
розробникам децентралізованих платформ;
спільнотам відкритого програмного забезпечення;
дослідникам мережевих технологій;
операторам громадських mesh-мереж;
розробникам автономних інформаційних систем;
проєктам розподіленого зберігання;
організаціям, які створюють резервні комунікаційні системи;
ініціативам цифрової стійкості громад.
Ми хочемо публікувати не тільки успішні результати, а й невдалі експерименти, виявлені обмеження та технічні помилки.
Іноді інформація про те, чому певне рішення не працює, має не меншу цінність, ніж інструкція з його впровадження.
11. Принципи роботи
Дослідницька група дотримуватиметься кількох принципів.
Відкритість. Публікувати результати, які можуть бути корисними іншим учасникам екосистеми.
Перевірюваність. Відокремлювати підтверджені факти від припущень та рекламних тверджень.
Технологічна нейтральність. Не прив'язувати дослідження до одного виробника, протоколу чи платформи.
Практичність. Перевіряти архітектурні ідеї на реальних пристроях і в контрольованих експериментах.
Відтворюваність. Документувати умови тестування та надавати достатньо інформації для повторення досліджень.
Децентралізація знань. Забезпечувати доступ до документації та результатів незалежно від участі в конкретній організації.
12. Запрошуємо до дослідницької співпраці
Black Roses / Project Expanse розпочинає формування робочої групи з дослідження автономних гетерогенних децентралізованих мереж.
Нас цікавлять не формальні члени команди, а люди, які готові працювати з конкретними технологіями, перевіряти документацію, проводити експерименти, аналізувати результати та передавати знання іншим.
Ми відкриті до співпраці з розробниками, системними адміністраторами, мережевими інженерами, дослідниками, фахівцями з інформаційної безпеки та прихильниками відкритого програмного забезпечення.
Участь може починатися з одного невеликого завдання: перевірки певного протоколу, аналізу сумісності двох компонентів, тестування обладнання або підготовки технічного огляду.
Не обов'язково бути експертом у всіх напрямках. Набагато важливіше мати готовність досліджувати, документувати та ділитися результатами.
Наша мета — не створити ще одну закриту технологічну платформу. Наша мета — дослідити, як побудувати інфраструктуру, яка не припиняє бути корисною тоді, коли звичний Інтернет перестає працювати.
Використані технічні джерела та документація
Yggdrasil Network — офіційна документація та репозиторій проєкту. Реліз 0.5.15 від 24 жовтня 2026 року.
Reticulum Network Stack — офіційний технічний посібник, версія документації 1.6.0.
IETF RFC 9171 — Bundle Protocol Version 7, січень 2022 року; подальші оновлення RFC 9713 та RFC 9758.
IETF RFC 9675 — Delay-Tolerant Networking Management Architecture.
IETF RFC 8966 — The Babel Routing Protocol.
Meshtastic — офіційна документація алгоритму mesh-мовлення та керованого flooding.
IPFS Documentation — Persistence, Permanence and Pinning.
I2P Documentation — Threat Model.
IEEE 802.11s — Mesh Networking, специфікація бездротових mesh-мереж.
Black Roses | Project Expanse
Досліджуємо. Документуємо. Ділимося знаннями. Будуємо децентралізовану інфраструктуру.
#ProjectExpanse #BlackRoses #AHDN #MeshNetworks #DecentralizedNetworks #Yggdrasil #Reticulum #DTN #IPFS #OpenSource
Comments
Post a Comment