Twitter

середа, 11 листопада 2026 р.

Меш мережі або гонка озброєнь 2.0

Попрацював 19s

### Найперспективніші дослідження у сфері mesh-мереж

Технологічний огляд · листопад 2026 · дослідницька стратегія

Якщо дивитися на mesh-мережі не просто як на альтернативу Wi-Fi, а як на основу майбутньої незалежної комунікаційної інфраструктури, то найцікавіші дослідження зараз лежать на перетині п'яти напрямків:

* Self-healing networks — мережі, які самостійно відновлюються після втрати вузлів і каналів.

* Delay-tolerant networking (DTN) — комунікації, які працюють навіть без постійного наскрізного з'єднання.

* Heterogeneous mesh — об'єднання Wi-Fi, LoRa, радіоканалів, супутникового зв'язку та дротових мереж.

* Autonomous routing — адаптивна маршрутизація з урахуванням якості каналу, енергоспоживання та доступності вузлів.

* Privacy-preserving infrastructure — мережі, в яких приватність та стійкість до централізованого контролю закладені в архітектуру.

Моя головна теза: перспективна mesh-мережа майбутнього — це не мережа з максимальною кількістю вузлів. Це мережа, яка залишається корисною навіть тоді, коли її фізична та логічна структура постійно змінюється.

### 1\. Де зараз найбільший дослідницький потенціал

![ER706W | Omada AX3000 Gigabit VPN Router | TP-Link Malaysia](https://images.openai.com/static-rsc-4/lONtMD-QAjqfKpnip9cQELa_FrZYZXGI5FnYrhG0HpyiDWNh6oEgzb6hftEA_Nnu3MZvXslo1Vks7V2VNuSH45pqDPhIK_m8l5sLwqae052cqAbItlnv_HKFwFC6G41Ydk_oYTJjmlXiQsYwJuvdN1xBvpnDI0qOy4tAItUHx0vg-9S4YWat7ldKBxRNNQ0s?purpose=fullsize)

1\. Самовідновлення та автономна маршрутизація

Пріоритет №1

* Автоматичне відновлення маршрутів після зникнення вузлів.

* Вибір альтернативних каналів без центрального координатора.

* Прогнозування деградації каналів.

* Розподілене управління навантаженням.

Особливо цікаво: поєднання традиційних алгоритмів маршрутизації з Multi-Agent Reinforcement Learning.

![Space–Air–Ground–Sea Integrated Network with Federated Learning](https://images.openai.com/static-rsc-4/dvhe5cly9LEG3iRTd6Q4gPOa-D-RrUeTjkhj2ZYES_wYgjJXJSxyFkibP9UoNmSbiMPd36RZ6qygkExs80fhr8x1A5JzASccpTAhr1GAzKLNDLfEw9F0MjdxHV8o9myzvKyVgKeaXid5Sdoesdt2__2UFJpySlgYJ2_cxLqtZ0cqBTsFQqg5VKQwbAmVbwy5?purpose=fullsize)

2\. Гетерогенні mesh-мережі

Пріоритет №1

* Wi-Fi mesh + LoRa/LoRaWAN.

* Yggdrasil поверх різних фізичних транспортів.

* Супутникові канали як зовнішній транспорт.

* Автоматичне перемикання між доступними середовищами.

Головне питання: як побудувати єдиний логічний простір комунікації поверх фізично різних мереж?

![Store-carry-forward mechanism in DTN  | Download Scientific Diagram](https://images.openai.com/static-rsc-4/tc2kB6HsGCIbTgmRvN_5nCuf5JkSgQsCUqA9BjT33gtykAW7zwYVhjE51h8HHqjlQhAgKghG6O_ca5DDR3RzWA_38fjIl5HkQpiMI5g647dq7OKq7MuyUdtzgDgykNWdlEK8r0KmjNSVNunCpp69EUXfSmmPrCdajKBACccnUaseS-SbhjO8fVS9aq9Y19v6?purpose=fullsize)

3\. DTN та Opportunistic Networking

Пріоритет №1

* Store-Carry-Forward.

* Передавання повідомлень через тимчасово доступні вузли.

* Робота без постійного Internet-з'єднання.

* Пріоритети повідомлень і контроль черг.

Це один із найцікавіших напрямків для інфраструктури, яка повинна переживати тривалі розриви зв'язку.

![Trust Over IP in Decentralized Information and the Role of Delegates | by Michael Ruminer | Medium](https://images.openai.com/static-rsc-4/REsnL8sbjvOIfj_X-35DB_jQs2onPi0WSv-pFxHv68CohTg6ZRNZyfx83kKZcA3qReIGTtzh4eulxxqR0o0JPn9hJBEHlKmgDJot2GZwojwm7Ph2Oo3aLWwpGF-MAjBxyZW4rA_zOAzNLjcg5ULzqhLxmDEt2lr_Q-rGkS3ko_8ClT9DzWR1i8621GeoGNGX?purpose=fullsize)

4\. Розподілена безпека та довіра

* Децентралізована ідентифікація вузлів.

* Керування ключами без центрального сервера.

* Захист від підміни маршрутів та зловмисних вузлів.

* Виявлення аномалій без передавання телеметрії до централізованого хмарного сервісу.

Особливо перспективні Federated IDS та легкі криптографічні механізми.

![HP workpath | PaperCut](https://images.openai.com/static-rsc-4/o7ygo8BarHA4-5qqjdofqXf75vAXLTnW-UQKOG9edKEeFfPIbjXaHwX1Ze4wDIRyzKsQ_gcCHQdcu6CKQcfzbP4krK7CFpeF6Trl5ZBCVUS46nnGh_f_TbntG25q9efIpvM2Q35Qz6f36JQDpGAAtjHNY928lUND3ID_2MdyqjpsVfm3iEyVNq_ZXxVaupar?purpose=fullsize)

5\. Edge Computing та розподілені сервіси

* Локальні DNS та кешування.

* Розподілені шлюзи.

* Локальна обробка даних.

* Автоматичне переміщення сервісів між вузлами.

Мережа повинна не лише передавати пакети, а й надавати послуги навіть за відсутності зовнішнього Internet.

![Meshtastic Solar Node, Outdoor Node for Meshwork and IoT - Meshnology](https://images.openai.com/static-rsc-4/EGAxDCo99PkHrC3N-dc8rkpvuuQBWh5pdINHZxmxg2sn_qntp3F94PLa3XVQ672Cwpm-eSPITo35xMLrU6z67NpnIoB-BDDjBlyf5b9HXBC6g9y3m1RrLGPKpgU6swnAY1k8aErZA3CJp1QWjpwGhyCanXy7fFPXY-Wj3t1Mx0AV8ZMyP53X5HdoMXj62ZR-?purpose=fullsize)

6\. Енергетична автономність

* Solar-powered mesh nodes.

* Динамічне регулювання потужності.

* Енергоефективне сусідство та маршрутизація.

* Вузли з режимами сну та пробудження.

Важливо для тривалої роботи інфраструктури без постійного обслуговування.

Ці пріоритети не випадкові. У дослідженні ACM 2026 року з оптимізації wireless mesh networks виявлено, що пропускна здатність домінує серед досліджуваних цілей, тоді як безпека, мобільність і контроль енергоспоживання залишаються недостатньо опрацьованими. Це відкриває можливість для робіт, які досліджують декілька параметрів одночасно. A Survey +1

### 2\. Напрямки, які варто досліджувати окремо

| Напрямок | Наукове питання |
| ---------------- | ------------------------------------------------------------------------------------ |
| Mesh + DTN | Як зберігати доставку повідомлень під час тривалої ізоляції? |
| Mesh + AI | Як навчити мережу адаптувати маршрути без центрального контролера? |
| Mesh + LoRa | Як поєднати далекобійний низькошвидкісний транспорт із високошвидкісними сегментами? |
| Mesh + Yggdrasil | Як оптимізувати побудову та підтримку overlay-топології? |
| Mesh + I2P/Tor | Як забезпечити приватність без критичного погіршення доступності? |
| Mesh + Edge | Як забезпечити локальні сервіси під час відключення Internet? |
| Mesh + Security | Як виявляти скомпрометовані вузли без централізованої системи довіри? |

Окремо звернув би увагу на дві нові лінії досліджень:

* Association-less communication — обмін даними без попереднього встановлення традиційного з'єднання. У вересневому огляді 2026 року дослідники розглядають Wi-Fi та BLE як практичну основу таких комунікацій. Springer

* Self-healing через розподілене машинне навчання — у роботі IEEE 2026 року продемонстровано експериментальну модель, де вузли самостійно розподіляють навантаження та адаптуються до втрати частини мережі. IEEE Xplore

### 3\. Найцікавіше: об'єднання різних mesh-парадигм

Тут я бачу найбільший потенціал для самостійної дослідницької роботи.

Потрібно розрізняти два поняття:

* Physical mesh — фізичні пристрої безпосередньо утворюють багатохопову мережу.

* Overlay mesh — логічна мережа створюється поверх наявних IP-каналів, незалежно від фізичної топології.

Їхнє поєднання дозволяє будувати значно цікавіші системи.

![Recommendation ITU-T Y.4218 (05/2023) - Internet of things and information and communication technology requirements for deployment of smart services in rural communities](https://images.openai.com/static-rsc-4/huqOxyNtMSUj5GBcvMvb5Fa4ICV1fFXlQgnX0rOepZB4C7ifL84unqXWw5xHj2EBeDKencaAU8u1-8bu9JNt7rA_9Jw9RDB7XMGyEA2zrS32PDeajMPHzgvxDiLpJY1HtyiadiLIzJbFOZhlwolhN6MhlMKPm8ftGyVDkPhHHoOqxckibGtGnWNaDSFWeBRh?purpose=fullsize)

Я б досліджував таку архітектуру:

### Multi-Transport Decentralized Mesh

Рівень застосунків

Локальні сервіси · обмін повідомленнями · DNS · сховища

Overlay Network

Yggdrasil · IPFS · Reticulum · DTN

Wi-Fi / Ethernet

Висока пропускна здатність

LoRa / Radio

Низька швидкість, автономність

Satellite

Зовнішній транспорт

Fiber / WAN

Стабільні магістральні канали

Розподілені фізичні вузли

Маршрутизатори · шлюзи · автономні вузли · edge-системи

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

### Що тут можна дослідити

* Як різні фізичні транспорти можуть обслуговувати одну логічну мережу?

* Як уникнути дублювання маршрутів і нестабільної маршрутизації?

* Як передавати великі файли через мережу з періодично доступними каналами?

* Як забезпечити пріоритетність повідомлень?

* Як зберегти працездатність локальних сервісів після втрати зовнішніх шлюзів?

* Як вимірювати реальну автономність мережі, а не тільки її пропускну здатність?

Це вже не просто дослідження mesh-протоколу. Це дослідження незалежної мережевої інфраструктури.

### 4\. Конкретні технології та проєкти для вивчення

Добірка відкритих технологій, які варто включити до порівняльного дослідження.

![Новый виток развития Yggdrasil / Хабр](https://images.openai.com/static-rsc-4/ZVxTq4URMUeNZ7YKjZMc2_SG2zaqIKUtyfcvsHByHhQTM4JwVU_jpB27W0cmJCa9AESSwer5NOjHHLz9ajevH3k1f_R_5Cll0fySnHarlcmPMIg0r808veTECK9LLFGAJ8vq7yLsfZPYwh5Pu3yJwK2hb2GMgDQ0tsrVL3N-mCONHZ_toHczLWnnQ2AraDoZ?purpose=fullsize)

Yggdrasil

Децентралізована IPv6 overlay-мережа. Досліджувати маршрутизацію, топологію, discovery, масштабування та роботу через різні транспорти.

[Офіційна документація](https://yggdrasil-network.github.io/?utm_source=chatgpt.com)

![Getting Started Fast - Reticulum Network Stack 1.1.3 documentation](https://images.openai.com/static-rsc-4/OYOMvjxcUXytQAtD9iCM-iUTTu7XrKQNXF2PhkqWdf5sZfEKJJGHyCD4_AQsDv3fKa7X2vZcox3o4jxTHrj4jaapvhpR2M-e8eaDn0gKIMIoEEsOfMyEETECUn73FFO5D2NJCn7KlA7NixxHGGzXhrm-SF6u1VkhGMuq0Ow0Pqg8Xudv55-7Gr0H2PcMjBJK?purpose=fullsize)

Reticulum

Мережевий стек для роботи поверх різнорідних транспортів, зокрема каналів з обмеженою пропускною здатністю.

[Офіційний сайт](https://reticulum.network/?utm_source=chatgpt.com)

![Radio Mesh Network](https://images.openai.com/static-rsc-4/yrVjsvv2RWvxZmKrsrRbCwO_lU20IUX1XCFYo1goWR7HnjUWPlSPMzLuaU65lxzlTCLnYMDqUmVmpvdPH3SBaxgu44VsFQ-GTrnLKvLiRQQX_ZKIK3rE4eUIrZhPAC4TGfjvvc8RCMTW00NPcyqtUYpaCwp5iA-mNPbs5R-dxO7h5Mb9zYQU2xDz94WIc01M?purpose=fullsize)

Babel

Цікавий об'єкт для дослідження динамічної маршрутизації у змішаних мережах.

[Документація Babel](https://www.irif.fr/~jch/software/babel/?utm_source=chatgpt.com)

![Meshtastic Icon & Logo (selfh.st) | Dashboard Icons & Logos](https://images.openai.com/static-rsc-4/yR2OmyZJ1_G-bBG7BKjUIveRzjHbJ-VK3T9_YgVT7OYFY1w3dhZD8dy_Ys9Y6lkryBo_MVHeV0PSnBQnjl2lNWsWWZo1EAi3DJyfwNqM96LWexIxgoKl31498jsRkGDj8A6mLxAWKYlaJlBapsQsouj3TAG1STsfvIQ1I6R1TmRraDAziTtIuBw_LmLMuSuL?purpose=fullsize)

Meshtastic

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

[Офіційний сайт](https://meshtastic.org/?utm_source=chatgpt.com)

![I2P Logo PNG Vector (SVG) Free Download](https://images.openai.com/static-rsc-4/HPUuo3_OsBCWLqT9BWpqhxVqFD1s52p4J4vN6NUN3VGkUxKOn6ZCgRNLDN2ybwHTTkKk65HzE6oJCQVe4OPXgfW6JP4Fe9Z6h2uaEqI-27m0ogOY6ED2_yH7_QubRyjNp8ziFpnQ1P1CU9nSxmHkP8hBYiwQF8I3i5Bkx21si7KQucU0jkawSIL4MM1tylG8?purpose=fullsize)

I2P

Дослідження анонімності, маршрутизації, розподілених служб та поведінки overlay-мережі за нестабільних з'єднань.

[Офіційний сайт](https://geti2p.net/?utm_source=chatgpt.com)

![NexFun](https://images.openai.com/static-rsc-4/mEHfm3T36e09Dy_4j1z84zfN-c25MqhcYI6k_B7Cl0FicI_W-E5NODgOEbhZ4F8hiiZF39pzIFA1qOtTX9TQT02Co0NZRoJGfxLKyhfg9JSHHas2yTGaMP4aMnGmjE6wBrFcgtRUtbGhvIjECMWtHBsDD1aNO0llVYupkzuHb3OGn63rTBvWiTX10x5bkPCp?purpose=fullsize)

IPFS

Розподілене зберігання, content addressing, кешування та доступність контенту без залежності від одного сервера.

[Документація IPFS](https://docs.ipfs.tech/?utm_source=chatgpt.com)

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

### 5\. П'ять перспективних тем для власних досліджень

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

| № | Тема | Дослідницький результат |
| --- | -------------------------------- | --------------------------------------------- |
| 1 | Autonomous Self-Healing Mesh | Модель самовідновлення мережі |
| 2 | Hybrid Mesh Transport | Архітектура об'єднання різних транспортів |
| 3 | DTN-enabled Community Network | Комунікація без постійного Internet |
| 4 | Decentralized Trust Architecture | Розподілена система довіри |
| 5 | Persistent Edge Services | Локальні сервіси з автономним функціонуванням |

Особливо перспективними вважаю теми №2 і №3. Їхнє поєднання може дати практичний результат, який виходить далеко за межі звичайної mesh-мережі.

### 6\. Як організувати дослідження

Пропоную чотири послідовні етапи.

* Етап I. Літературне та архітектурне дослідження

    * Порівняти MANET, WMN, DTN та overlay mesh.

    * Вивчити сучасні протоколи маршрутизації.

    * Зібрати результати реальних експериментів.

    * Визначити невирішені проблеми.

* Етап II. Експериментальна лабораторія

    * Віртуальні вузли Linux.

    * Yggdrasil, Babel, Reticulum.

    * Імітація втрати вузлів, затримок та обмеження пропускної здатності.

    * Тестування різних топологій.

* Етап III. Фізичний прототип

    * Декілька недорогих маршрутизаторів.

    * Wi-Fi та Ethernet.

    * Окремий низькошвидкісний транспорт.

    * Локальні DNS, кешування та обмін повідомленнями.

* Етап IV. Вимірювання та публікація

    * Порівняння алгоритмів.

    * Аналіз відмовостійкості.

    * Енергетична ефективність.

    * Відтворювані результати та відкриті інструменти тестування.

### Що вимірювати

| Метрика | Що показує |
| ------------------------ | ------------------------------ |
| Packet Delivery Ratio | Частка доставлених пакетів |
| End-to-End Latency | Наскрізна затримка |
| Route Convergence Time | Час відновлення маршрутизації |
| Network Recovery Time | Час відновлення працездатності |
| Control Overhead | Витрати на службовий трафік |
| Energy per Delivered Bit | Енергетична ціна передачі |
| Service Availability | Доступність локальних сервісів |

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

### 7\. Наукові джерела, з яких варто почати

Ось кілька актуальних робіт 2026 року:

* [MultiObjective Optimization in Wireless Mesh Networks – A Survey](https://doi.org/10.1145/3800685?utm_source=chatgpt.com) — ACM Computing Surveys, 2026. Особливо важлива для визначення недосліджених компромісів.

* [Evolving MANETs toward secure, scalable, and intelligent networks](https://link.springer.com/article/10.1007/s43926-026-00376-w?utm_source=chatgpt.com) — сучасні проблеми масштабування, безпеки й адаптивності.

* [Three-Level Taxonomy of RL Self-Healing for Energy, Latency, and Security Constrained Edge IoT Networks](https://www.sciencedirect.com/org/science/article/pii/S1546221826005151?utm_source=chatgpt.com) — самовідновлення через Reinforcement Learning.

* [A systematic survey of post-Matter smart-home mesh security](https://www.sciencedirect.com/science/article/pii/S1570870526002052?utm_source=chatgpt.com) — безпека багатопротокольних mesh-мереж.

* [WiFi and BLE advertisement based communication for ephemeral interactions](https://link.springer.com/article/10.1007/s12083-026-02295-7?utm_source=chatgpt.com) — комунікації без попереднього встановлення з'єднання.

* [Decentralized Multi-Agent Reinforcement Learning for Self-Healing Resource Optimization in IoT Edge Meshes](https://ieeexplore.ieee.org/abstract/document/11688347/?utm_source=chatgpt.com) — експериментальна реалізація розподіленого самовідновлення.

### 8\. Мій стратегічний висновок

Найперспективніша дослідницька концепція

Autonomous Heterogeneous Decentralized Network (AHDN)

Це умовна назва дослідницького напряму, а не назва готового стандарту чи протоколу.

Його предмет — створення мережевої інфраструктури, яка:

* не залежить від одного оператора;

* підтримує різні фізичні транспорти;

* здатна переживати тривалу втрату зовнішнього зв'язку;

* самостійно відновлює доступні маршрути;

* зберігає локальні сервіси;

* не потребує постійного централізованого управління;

* забезпечує криптографічну автентифікацію та контроль довіри.

Це перспективніше, ніж просто розробляти ще один mesh-протокол.

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

* Network Architecture — фізичні та логічні мережі, маршрутизація, транспортна сумісність.

* Network Autonomy — самовідновлення, DTN, розподілене управління, енергоефективність.

* Network Sovereignty — приватність, незалежна ідентифікація, локальні сервіси, відсутність єдиної точки контролю.

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

Моя рекомендація: почати з дослідження зв'язки Yggdrasil + Reticulum + DTN + локальні Edge Services. Не з інтеграції заради інтеграції, а з перевірки гіпотези: чи можна забезпечити безперервність локальних комунікацій і сервісів, коли Internet, окремі маршрутизатори та частини фізичної мережі стають недоступними?

Це конкретна, вимірювана і потенційно публікаційна задача.

Наступним кроком я можу підготувати дослідницьку дорожню карту на 12 місяців із пріоритетами, технічними гіпотезами, експериментальними стендами, відкритими репозиторіями та критеріями успіху.

📡

Щомісячний огляд досліджень mesh-мереж

Торкніться, щоб налаштувати

неділя, 4 жовтня 2026 р.

Хто насправді створив Monero?

 

Хто насправді створив Monero?



Monero часто сприймають як майже унікальний продукт криптографічної культури: приватність не як додаткова функція, а як базова властивість протоколу; чесний запуск без premine; відсутність компанії-засновника; анонімні або псевдонімні люди на початку історії.

У цій картині є багато правди. Але сама історія виникнення Monero значно дивніша.

Вона починається не з Monero, не з відомого розробника і навіть не з Bitcoin-форка.

Вона починається з анонімного CryptoNote, загадкового Bytecoin, суперечливого запуску і людини під ніком thankful_for_today, яка створила BitMonero — а потім фактично втратила контроль над власним проєктом.

І найцікавіше тут не те, що під історією є «щось страшне».

Найцікавіше — наскільки мало нам насправді потрібно вигадувати, щоб ця історія виглядала майже неймовірною.

1. До Monero був CryptoNote

У 2012–2013 роках з'являється концепція CryptoNote — протоколу, який дивився на Bitcoin зовсім під іншим кутом.

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

CryptoNote запропонував інший підхід: одноразові адреси призначення, кільцеві підписи та механізм key images для запобігання double-spending без розкриття того, який саме вихід був витрачений.

Підпис авторства був простим:

Nicolas van Saberhagen.

Проблема в тому, що ми не знаємо, хто це.

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

Це важлива межа доказу.

Ми можемо говорити про документи CryptoNote і їхній зміст.

Ми не можемо на підставі цього сказати, хто фізично їх написав.

2. Bytecoin: перша велика загадка

Першою відомою реалізацією CryptoNote став Bytecoin.

Сьогодні це одна з найбільш незручних частин історії.

Команда Bytecoin заявляла, що мережа була запущена 4 липня 2012 року і що до публічного оголошення монета вже майнилася майже два роки.

Коли Bytecoin став публічно відомим у 2014 році, у блокчейні вже знаходилася величезна частка майбутньої емісії. У дискусіях того часу фігурувала цифра близько 80%; один із учасників прямо зазначав, що на блокчейні бачив приблизно 83% уже видобутих монет.

Але тут треба бути акуратним із термінологією.

83% видобутих монет ≠ автоматично доказ premine.

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

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

Це версія джерела, а не незалежно встановлений факт.

І саме ця непрозорість стала однією з причин, чому частина криптоспільноти почала шукати альтернативу Bytecoin.

Тут важливо не перебільшувати: немає достатніх підстав перетворювати загадкову ранню історію Bytecoin на доказ якогось таємного державного або корпоративного проєкту.

Але є достатньо підстав сказати інше:

розподіл Bytecoin був непрозорим, а прозорість походження монет стала принциповою проблемою.

3. 18 квітня 2014 року

Саме тут починається безпосередня історія Monero.

Користувач Bitcointalk під псевдонімом thankful_for_today оголосив BitMonero — форк Bytecoin на базі CryptoNote. Запуск був анонсований заздалегідь, а фактичний старт відбувся 18 квітня 2014 року о 10:50 GMT.

Це принципова відмінність від Bytecoin.

Не потрібно було приймати на віру історію про приховані два роки майнінгу.

Не було premine.

Не було частки блок-нагороди для розробників.

Будь-хто міг почати майнити з запуску мережі.

Саме це сьогодні офіційно описується Monero як «fair launch».

Але назва тоді була іншою:

BitMonero.

І тут починається найцікавіша частина.

4. Засновник, який не став засновником

thankful_for_today справді був людиною, яка запустила BitMonero.

Це не міф.

У першому announcement він публікував код, бінарні файли, координував запуск і продовжував розробку.

19 квітня він уже обговорював зміни коду та питання GUI. 25 квітня він пропонував merged mining. Наприкінці квітня він усе ще активно коментував виправлення помилок.

Тобто історія «засновник запустив Monero і одразу зник» — неправильна.

Він був реальною активною фігурою перших тижнів.

Але паралельно виникла інша група.

Люди почали обговорювати майбутнє мережі, код, параметри протоколу, перейменування, GUI, блок-експлорер та інфраструктуру.

23 квітня в публічній гілці вже видно, що навколо BitMonero формується окреме ядро активних учасників. David Latapie, який пізніше фігурував як член Monero Core Team, писав про перейменування BitMonero на Monero, новий OP і передачу доступу до нього довіреним учасникам.

Це ще не була завершена «революція».

Це був процес.

І він відбувався публічно.

5. Момент, коли проєкт почав відриватися від автора

23–24 квітня — особливо цікава точка.

У той час David Latapie та інші учасники вже організовували нову структуру навколо проєкту.

План включав:

  • перейменування BitMonero на Monero;

  • новий основний форумний announcement;

  • новий домен;

  • доступ до нового OP для довірених користувачів.

При цьому thankful_for_today не погоджувався з частиною запропонованих змін. Зокрема, 24 квітня він прямо писав, що підтримує перейменування, але не підтримує запропонований hard fork без підтримки щонайменше 50% майнерів.

Це дуже важливий момент.

Пізніша спрощена версія історії звучить приблизно так:

«Засновник запропонував погані зміни, спільнота його усунула».

А первинні матеріали показують дещо складніше:

спільнота почала перебудовувати проєкт ще до того, як старий автор остаточно зник із процесу.

Це не одномоментний переворот.

Це поступова зміна центру тяжіння.

6. Найцікавіше: Monero виник не через новий genesis block

Ось тут легко заплутатися.

Monero не виник як пізніший проєкт, який просто «скопіював» BitMonero.

Genesis block залишився тим самим — 18 квітня 2014 року.

Тобто Monero — це продовження тієї самої мережі, яка стартувала як BitMonero.

Змінився не genesis.

Змінилася структура управління, назва і поступово — технічна реалізація.

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

Фактично проєкт відокремився від авторства без відокремлення блокчейна.

Це одна з найцікавіших властивостей його походження.

7. Чому Bytecoin важливий для розуміння Monero

Тепер видно логіку.

Bytecoin дав технологію CryptoNote, але його розподіл і рання історія викликали серйозні питання.

BitMonero взяв цю технологію і зробив протилежний акцент:

відкрите оголошення + fair launch + можливість майнити з першого дня.

У квітневих обговореннях 2014 року прихильники BitMonero прямо протиставляли його Bytecoin: на той момент у Monero було видобуто менше 0,1% емісії, тоді як щодо Bytecoin говорили про приблизно 80% уже видобутих монет до публічного виходу.

Тобто Monero спочатку будував свою легітимність не тільки на технології приватності.

Він будував її на способі розподілу.

І це дуже важливо.

Приватність була властивістю протоколу.

Fair launch був властивістю соціального контракту.

8. А що з Nicolas van Saberhagen?

Ось тут починається територія, де дуже легко перейти від OSINT до конспірології.

Ми маємо документ CryptoNote v2.0, датований 17 жовтня 2013 року та підписаний Nicolas van Saberhagen.

Ми можемо прочитати документ.

Можемо проаналізувати його криптографічні конструкції.

Можемо простежити, як ці ідеї потім були реалізовані в Bytecoin і зрештою в Monero.

Але ми не маємо надійно встановленої особи Nicolas van Saberhagen.

Тому твердження:

«Nicolas van Saberhagen був X»

без додаткових доказів є припущенням.

Так само немає підстав автоматично робити наступний стрибок:

«Якщо особу не встановлено, за проєктом стояла спецслужба / корпорація / уряд».

Це логічно не випливає з наявних доказів.

Невідомість — це саме невідомість.

9. А що з thankful_for_today?

Тут ситуація протилежна.

Ми не знаємо його реального імені.

Але його діяльність як учасника запуску BitMonero прекрасно документується під псевдонімом.

Ми бачимо його повідомлення, пропозиції щодо коду, технічні суперечки, ставлення до hard fork і спроби продовжувати управління проєктом.

Тому анонімність особи не означає відсутність доказового сліду.

Це важлива відмінність для всієї історії.

10. Чи «захопила» спільнота Monero?

Слово «захопила» я б використовував дуже обережно.

З одного боку, офіційна історія Monero прямо говорить про конфлікт: thankful_for_today запропонував суперечливі зміни, спільнота їх не підтримала, після чого Core Team зробила fork проєкту і спільнота пішла за нею.

З іншого боку, первинні матеріали показують, що цей процес не виглядав як одномоментне відсторонення людини від вже сформованої організації.

Організації в сучасному розумінні взагалі ще не існувало.

Була мережа, код, форум, IRC, кілька розробників, майнери та користувачі.

Тому точніше сказати:

контроль над напрямком розвитку поступово перейшов від первинного автора до ширшої групи розробників і користувачів, які сформували Core Team.

Це не робить історію менш радикальною.

Навпаки.

11. І тут з'являється справжня загадка

Якщо відкинути конспірологію, залишиться питання, яке набагато цікавіше.

Чому це спрацювало?

У квітні 2014 року BitMonero був крихітним проєктом.

На 25 квітня в одному з обговорень учасники оцінювали, що Monero мав лише близько 0,1% розподіленої емісії.

У нього не було величезної інфраструктури.

Не було корпорації.

Не було ICO.

Не було venture capital.

Не було засновницької частки.

І все ж мережа пережила конфлікт із власним первинним автором.

Це означає, що критично важливим активом виявився не приватний ключ засновника.

Активом стала мережа людей, які готові продовжувати код.

Саме тут історія Monero починає бути цікавою не лише для криптоентузіастів.

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

12. Що з цього випливає — і чого не випливає

Підтверджено

  • CryptoNote існував до Monero і запропонував ключові механізми приватних транзакцій.

  • Авторство документів пов'язане з псевдонімом Nicolas van Saberhagen, але його реальна особа не встановлена.

  • Bytecoin був публічно представлений у 2014 році як проєкт, що заявляв про запуск у липні 2012 року.

  • До публічного розгортання Bytecoin уже мав дуже велику кількість видобутих монет.

  • BitMonero був анонсований як форк Bytecoin і стартував 18 квітня 2014 року.

  • thankful_for_today був реальним активним автором раннього BitMonero.

  • У другій половині квітня 2014 року навколо проєкту сформувалася група, яка перейменувала його на Monero і почала формувати нову структуру управління.

  • Monero продовжив той самий блокчейн, а не запустив окрему мережу з нуля.

Не встановлено

  • Хто насправді був Nicolas van Saberhagen.

  • Хто саме контролював ранній Bytecoin.

  • Скільки людей реально видобували ранні BCN.

  • Чи була вся рання емісія Bytecoin результатом майнінгу протягом заявлених двох років.

  • Чи стояла за CryptoNote якась прихована організація.

Що не можна чесно вивести з цих фактів

Не можна сказати:

«Monero створили спецслужби».

Але так само не можна сказати:

«Ми знаємо всіх справжніх творців Monero і його передісторії».

Ми цього не знаємо.

І це, мабуть, найчесніша відповідь.

13. То хто ж насправді створив Monero?

Відповідь виявляється багатошаровою.

CryptoNote створив концептуальний фундамент.

Nicolas van Saberhagen залишив нам анонімний дизайн-документ.

Bytecoin першим реалізував цю технологію в живій мережі.

thankful_for_today запустив BitMonero як альтернативний fair-launch форк.

А потім спільнота та Core Team перетворили BitMonero на Monero.

Тому відповідь «Monero створив X» майже неминуче буде неправильною.

Monero — це не продукт одного засновника.

Це результат кількох послідовних шарів авторства.

І, можливо, саме це пояснює його подальшу історію краще, ніж будь-яка теорія про таємного творця.

14. І що це означає для самого Monero?

Для мене тут немає підстав робити ні апологетику, ні викриття.

Monero не стає менш цікавим через те, що його рання історія містить темні плями.

Навпаки.

Вона демонструє дуже рідкісну для технологічних проєктів річ:

код пережив автора.

Автор CryptoNote залишився невідомим.

Автор BitMonero втратив визначальний вплив на напрямок розвитку.

А мережа продовжила існувати.

Це не доказ абсолютної децентралізації.

Не доказ відсутності центрів впливу.

І не доказ того, що всі люди, які працювали над проєктом, були незалежними від будь-яких інших інтересів.

Але це достатній доказ іншого:

історія Monero набагато менш схожа на історію звичайного криптостартапу, ніж може здатися.

І саме тому її варто знати.

Не для того, щоб перестати користуватися інструментом.

Не для того, щоб оголосити його святим.

А щоб розуміти, що саме ти тримаєш у руках.

https://t.me/donoperinfo/61515


Джерела

  1. Monero — About Monero / A Brief History.

  2. Nicolas van Saberhagen — CryptoNote v2.0, 17 October 2013.

  3. Bitcointalk — [ANN][BMR] Bitmonero - a new coin based on CryptoNote technology - LAUNCHED, 9 April 2014; запуск 18 квітня.

  4. Bitcointalk — первинна дискусія BitMonero, 19–30 квітня 2014 року.

  5. Bitcointalk — обговорення переходу від BitMonero до Monero, 23–25 квітня 2014 року.

  6. Bitcointalk — Bytecoin announcement та дискусія про ранній розподіл.

  7. Bitcointalk — відповідь, приписана представнику CryptoNote, щодо запуску Bytecoin та ранніх користувачів.