Докази з нульовим розголошенням для анонімного трафіку

Проблема традиційної маршрутизації та чому нам потрібні ZKP

Ви коли-небудь замислювалися, чи ваш VPN з політикою «без логів» (no-logs) насправді такий конфіденційний, як стверджує реклама? Це гірка правда, але традиційна маршрутизація — навіть зашифрована — є фундаментально вразливою, оскільки вона покладається на сліпу довіру до централізованих органів та статичні шляхи, якими напрочуд легко маніпулювати.

Більшість людей вважають VPN магічним тунелем, але «під капотом» це лише серія рукостискань (handshakes) із сервером провайдера. Проблема в тому, що ці сервери стають центральними точками відмови. Навіть якщо провайдер заявляє, що не веде журналів, ви все одно ставите свою приватність на його слово та фізичну безпеку його дата-центру.

• Парадокс «відсутності логів»: Ви мусите вірити, що провайдер не перебуває під тиском уряду або не став жертвою прихованого зламу. Якщо центральний сервер скомпрометовано, ваші метадані — хто ви і куди прямуєте — стають повністю відкритими.
• Недоброчесність вузлів у P2P-мережах: У децентралізованих мережах ми спостерігаємо явище «брехні маршрутизації». Вузол може стверджувати, що має найшвидший шлях до пункту призначення, лише для того, щоб перехопити ваші пакети для аналізу — класична схема атаки «людина посередині» (man-in-the-middle).
• Відведення трафіку: Дослідження Джейкоба Д. Вайта з Лос-Аламоської національної лабораторії (2023) підкреслює, як маршрутизатори можуть «брехати» про свої шляхи, що призводить до атак типу blackholing (скидання пакетів) або перехоплення даних у межах автономних систем. (White, J. D., "ZKPNet: Verifiable Routing," LA-UR-23-29806).

Нам потрібен спосіб довести, що шлях маршрутизації є валідним, не розкриваючи при цьому сам шлях або дані всередині нього. Саме тут на допомогу приходять докази з нульовим розголошенням (Zero-Knowledge Proofs або ZKP). Уявіть це на прикладі гри «Де Воллі?»: я можу довести, що знайшов Воллі на карті, показавши його через крихітний отвір у величезному аркуші картону. Я довів, що знаю, де він, не показуючи вам решту карти.

• Мінімізація даних: ZKP дозволяє вузлу довести, що він дотримувався протоколу та політики, не розкриваючи жодних приватних схем мережі.
• Захист метаданих: На відміну від звичайного шифрування, яке приховує контент, але залишає «цифрові сліди» (IP-адреси, часові мітки), ZKP може приховати особу відправника навіть від тих самих вузлів, що передають дані.
• Верифікація без довіри (Trustless): Вам не потрібно довіряти власнику вузла — ви довіряєте математиці. Якщо доказ не підтверджується, пакет не рухається далі.

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

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

Як ZKPNet та NIAR змінюють правила гри

Отже, ми з’ясували, що сучасна маршрутизація в інтернеті — це, по суті, серія «чесних слів» між серверами. Якщо ми хочемо вийти за межі цієї моделі, нам потрібна реальна математика, яка не розкриватиме наші конфіденційні дані. Саме тут на сцену виходять ZKPNet та NIAR (Мережева інфраструктура для анонімної маршрутизації). NIAR — це, власне, фреймворк, який дозволяє будувати ці анонімні шляхи без централізованого керування.

Зазвичай, якщо маршрутизатор хоче довести, що він може досягти певної точки призначення, йому доводиться показувати свою таблицю маршрутизації або внутрішні схеми. Для інтернет-провайдера або мережі лікарні це справжній кошмар із точки зору безпеки. Джейкоб Д. Вайт із Лос-Аламоської національної лабораторії (2023) представив ZKPNet — бібліотеку на базі Rust, яка створює спеціальні «гаджети» для таких атестацій.

• Мінімальний обсяг даних: Ці докази крихітні — іноді всього 224 байти при використанні groth16. Такий доказ можна вставити в заголовок, не перевантажуючи MTU (максимальний розмір пакета).
• Досяжність в один крок: Вузол може довести, що має валідний шлях до «Маршрутизатора Y», не розкриваючи точну кількість переходів (хопів) або внутрішні IP-адреси.
• Компроміси продуктивності: Головною перешкодою тут є затримка в реальному часі. Тести на процесорі M1 Max показують, що генерація доказу займає близько 468 мс. Для одного пакета 468 мс — це ціла вічність, тому ми не використовуємо це для кожної одиниці даних. Замість цього ZKP (докази з нульовим розголошенням) застосовуються для операцій рівня управління (control-plane) — наприклад, для встановлення шляху, — тоді як самі дані передаються миттєво, щойно «довіру» встановлено.

Крім того, існує sPAR (Somewhat Practical Anonymous Router — дещо практичний анонімний маршрутизатор), який намагається вирішити проблему вимоги «чесного вузла», характерну для таких систем, як Tor. Як зазначають Дебаджйоті Дас та Чонун Пак (2025), sPAR використовує багатостороннє повністю гомоморфне шифрування (FHE), завдяки чому навіть сам маршрутизатор не знає, куди він відправляє дані.

Найцікавіше те, як система уникає «проблеми колізій». Якщо кілька користувачів одночасно намагаються використати один і той самий слот пропускної здатності, дані можуть бути втрачені. sPAR використовує стратегію вибору з трьох (математичний трюк «кульки та кошики»), де клієнт обирає три випадкові індекси, і повідомлення потрапляє в перший доступний.

• Гомоморфне розміщення: Сервер розміщує ваш пакет у «кошик», жодного разу не бачачи обраний вами індекс. Усе це відбувається, поки дані залишаються зашифрованими.
• Обмеження масштабування: На даний момент sPAR не замінить глобальну мережу. Він підтримує близько 128 користувачів із затримкою в кілька секунд, що робить його ідеальним для нішевих завдань, як-от мікшування криптотранзакцій або приватний обмін повідомленнями в локальній мережі (LAN).

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

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

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

Рух DePIN (децентралізовані мережі фізичної інфраструктури) кардинально змінює цю ситуацію, створюючи свого роду «Airbnb для пропускної здатності». Замість того, щоб просто щомісяця платити провайдеру, ви можете реально заробляти криптовалюту, ділячись своїм невикористаним з'єднанням із глобальною P2P-мережею.

Для того, щоб децентралізований VPN (dVPN) або проксі-мережа були справді ефективними, потрібні тисячі вузлів (нод). Щоб мотивувати людей запускати ці вузли, проєкти використовують токенізовані стимули. Ви надаєте канал зв'язку, а мережа виплачує вам винагороду в утилітарних токенах.

Однак тут виникає серйозна технічна перешкода: як мережі переконатися, що ви справді надаєте якісну пропускну здатність, не шпигуючи при цьому за трафіком, який ви маршрутизуєте? Якщо вузол почне логувати дані користувачів, щоб «довести» свою роботу, вся концепція приватності Web3 VPN втратить сенс.

• Майнінг пропускної здатності: Користувачі встановлюють легкий клієнт вузла, який додає вихідну потужність до загального пулу мережі. Винагороди зазвичай розраховуються на основі часу безперебійної роботи (uptime), пропускної здатності та попиту в конкретному географічному регіоні.
• Докази з дотриманням приватності: Тут на допомогу приходять докази з нульовим розголошенням (ZKP). Ви можете підтвердити доступність вузла та дотримання протоколу, не розкриваючи фактичного вмісту пакетів або внутрішніх карт мережі.
• Якість обслуговування (QoS): Вузли можуть надавати «Доказ пропускної здатності» (Proof of Bandwidth), використовуючи математичні атестації для підтвердження того, що вони не обмежують швидкість трафіку та не скидають пакети («blackholing»).

Якщо ви хочете бути в курсі того, як розвиваються ці специфічні VPN-протоколи, радимо заглянути на SquirrelVPN, де публікуються останні новини про технології VPN та оновлення безпеки. Вони уважно стежать за переходом від централізованих дата-центрів до моделей із розподіленими вузлами.

Економічна складова цього процесу відбувається безпосередньо в блокчейні (on-chain). Смарт-контракти виступають у ролі автоматизованих посередників, забезпечуючи обмін між користувачами, яким потрібна приватність, та операторами вузлів, які мають зайву пропускну здатність.

• Автоматизовані P2P-платежі: Замість щомісячної підписки на послуги гігантської корпорації, ви платите лише за те, що реально використали. Смарт-контракт у реальному часі перераховує мікроплатежі постачальникам потужностей.
• Стійкість до атак Sybil: Якби одна людина могла запустити 1000 фейкових вузлів з одного сервера, це зруйнувало б децентралізацію мережі. Протоколи Proof of Bandwidth — часто підкріплені вимогами до стейкінгу — роблять спроби «збрехати» про свої ресурси економічно невигідними.

Повертаючись до нашого прикладу зі сферою охорони здоров'я: клініка могла б оплачувати пропускну здатність у такій мережі за допомогою токенів. Завдяки логіці sPAR, яку ми розглядали раніше, клініка отримує анонімність, а власники вузлів — оплату. При цьому провайдер (ISP) не бачить жодних патернів трафіку між клінікою та лікарнею.

Глибоке занурення у технічний рівень протоколу

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

Справжній прорив полягає у відмові від єдиної точки відмови. У типовій архітектурі одна особа володіє «ключами від замку». Проте завдяки багатосторонньому повністю гомоморфному шифруванню (fhe) ми можемо створити спільний публічний ключ, де фактично ніхто не знає головного секрету.

• Спільна генерація ключів: Під час налаштування кожен учасник створює власний секретний ключ. Вони об'єднуються в єдиний публічний ключ ($pk$). Як зазначають Дебаджьоті Дас та Чжон Ин Пак (2025) у своїй роботі щодо sPAR, головний секретний ключ — це просто сума всіх індивідуальних ключів, але оскільки ніхто не передає свій ключ іншим, «цілісний» ключ не існує в жодному конкретному місці.
• RLWE (Ring Learning With Errors): Це математичний фундамент системи. Простими словами, RLWE схожий на складну головоломку, де до даних додається невелика кількість «шуму». Комп'ютеру надзвичайно важко розв'язати її у зворотному порядку, що забезпечує нам стійкість ind-cpa (це означає, що зловмисник не зможе розрізнити два різні зашифровані повідомлення, навіть якщо він здогадується про їхній зміст).

Структура пакета: де зберігається доказ

То куди саме вбудовується цей 224-байтний ZKP (доказ із нульовим розголошенням)? У сучасній архітектурі IPv6 ми використовуємо розширені заголовки (Extension Headers). Зокрема, ми застосовуємо кастомний заголовок «Destination Options».

Завдяки розміщенню доказу в розширеному заголовку, маршрутизатори, які не підтримують ZKPNet, можуть просто передавати пакет далі. Проте вузли, що підтримують ZKP, зупиняють пакет, верифікують доказ за 2,7 мс і лише після цього пересилають його. Якщо доказ виявиться підробленим, пакет негайно відкидається.

• Захист від двозначності (Equivocation Protection): Ми можемо завадити вузлам надавати неправдиві дані, вбудовуючи історію взаємодії безпосередньо в ключі. Використовуючи хеш історії комунікації для оновлення публічного ключа в кожному раунді, ми досягаємо того, що математика просто «зламається», якщо сервер спробує показати Алісі іншу «реальність», ніж Бобу.
• Верифіковане fhe: Замість того, щоб просто довіряти вузлу у правильному виконанні обчислень, ми використовуємо верифіковане fhe. Це працює як цифровий чек, який підтверджує, що сервер дотримувався протоколу саме так, як це було прописано.

У нашому сценарії для роздрібної торгівлі цей технічний рівень дозволяє 100 магазинам синхронізувати дані. Стратегія «вибору з трьох кошиків» гарантує, що навіть якщо зловмисник перехопить пакет і перегляне заголовок IPv6, він не зможе визначити, з якого саме магазину надійшли дані, оскільки ZKP підтверджує валідність шляху, не розкриваючи джерела.

Майбутнє DePIN та інтернету, стійкого до цензури

Будемо відвертими: сучасний інтернет — це фактично набір «обгороджених садів», які лише вдають із себе глобальне надбання. У попередніх розділах ми обговорювали, як докази з нульовим розголошенням (ZKP) та P2P-пропускна здатність можуть «полагодити систему», але головне питання полягає в тому, як усе це масштабуватиметься, коли мільйони людей одночасно захочуть дивитися потокове відео.

Масштабування таких протоколів — процес надзвичайно складний через так звану «трилему анонімності». Зазвичай доводиться обирати лише два пункти з трьох: високий рівень приватності, низька затримка (latency) або мінімальне навантаження на пропускну здатність. Аналіз складних систем, таких як Tor, показує, що навіть за умови «ідеальної» криптографії ви все одно стикаєтеся з атаками на рівні системи (наприклад, кореляцією трафіку), якщо мережа недостатньо щільна.

Найбільшим «вузьким місцем» для децентралізованих мереж фізичної інфраструктури (DePIN) є співвідношення «розміру доказу» та «часу його генерації». Якщо кожен пакет у Web3 VPN вимагатиме окремого доказу Groth16, ваш роутер просто вийде з ладу від перевантаження. Для вирішення цієї проблеми ми впроваджуємо рекурсивні докази.

• Рекурсивні SNARK: Замість того, щоб перевіряти 1000 окремих доказів для кожного пакета, вузол (нода) може «згорнути» (roll up) ці докази в один єдиний мета-доказ. Це схоже на матрьошку, де зовнішній шар підтверджує валідність усього, що знаходиться всередині.
• Скорочення стейту (State Shrinking): Це дозволяє тримати розмір блокчейну в розумних межах. Нодам більше не потрібно зберігати всю історію мережі — достатньо перевірити останній рекурсивний доказ, щоб переконатися, що таблиця маршрутизації є достовірною.

Бізнес поступово усвідомлює, що централізовані VPN є вразливою ланкою для безпеки даних. Розподілені вузли роблять таку ціль для атак майже недосяжною.

• Маршрутизація на базі ШІ: Ми спостерігаємо перехід до програмно-визначених мереж (SDN), де агенти штучного інтелекту в реальному часі обирають шлях, найбільш стійкий до цензури.
• Обхід провайдерів (ISP Bypass): Токенізуючи зв’язність (connectivity), ми фактично будуємо паралельний інтернет. Тепер ідеться не просто про приховування IP-адреси; ідеться про володіння самою інфраструктурою. Таким чином, інтернет-провайдер не зможе просто натиснути на вимикач і заблокувати вам доступ.

Посібник із впровадження для операторів вузлів

Отже, ви ознайомилися з математикою та теорією, і тепер вам, ймовірно, цікаво, як саме запустити вузол на практиці. Чесно кажучи, налаштування вузла з підтримкою ZKP (доказів із нульовим розголошенням) — це проєкт на вихідні, але це єдиний спосіб перейти від парадигми «довіри VPN-провайдеру» до «довіри законам фізики».

Специфікації та налаштування вузла

Вам не потрібна серверна ферма, але й на «калькуляторі» запустити систему не вдасться.

• Мінімальні характеристики: Я б радив орієнтуватися щонайменше на 8 ГБ оперативної пам'яті (RAM) та сучасний 4-ядерний процесор.
• Мережа: Симетричне оптоволоконне з'єднання — це ідеал, але необхідно мати принаймні 20 Мбіт/с на віддачу (upstream).

Ініціалізація гаджета доказів (Proof Gadget)

Більшість сучасних dVPN-проєктів використовують такі бібліотеки, як arkworks або bellman. Ось приклад псевдокоду того, як вузол може ініціалізувати гаджет валідації шляху, використовуючи логіку ZKPNet:

// Псевдокод для ініціалізації гаджета маршрутизації ZKP
use zkpnet_lib::{Prover, PathCircuit};

fn prove_path(secret_path: Vec<u8>, public_root: [u8; 32]) {
    // 1. Ініціалізація схеми (circuit) із секретним шляхом маршрутизації
    let circuit = PathCircuit {
        path: secret_path,
        root: public_root,
    };

    // 2. Генерація доказу Groth16 (займає приблизно 468 мс)
    let proof = Prover::prove(circuit, &params).expect("Proving failed");

    // 3. Прикріплення 224-байтного доказу до розширеного заголовка IPv6
    packet.attach_header(0xZK, proof.to_bytes());
}

Під час налаштування бекенду пам'ятайте, що головною перешкодою є час генерації доказу — майже пів секунди. Якщо ви розгортаєте таку систему, переконайтеся, що ваш вузол не намагається підтверджувати кожен окремий пакет. Замість цього варто використовувати імовірнісні докази або пакетну обробку (batching). Ви підтверджуєте, що правильно обробили певне «вікно» трафіку під час фази встановлення шляху.

1. Проблеми з Double NAT: Якщо ваш вузол знаходиться за двома роутерами, P2P-виявлення (discovery) не працюватиме. Використовуйте UPnP або ручне перенаправлення портів (port forwarding).
2. Розсинхронізація часу (Clock Skew): Протоколи ZKP та блокчейну чутливі до точного часу. Запустіть локальний демон NTP.
3. Витоки IPv6: Багато хто налаштовує свій VPN-вузол для IPv4, але забуває, що провайдер видає також IPv6-адреси.

Слід розуміти: перехід від централізованого інтернету до децентралізованого, що працює на базі ZKP, буде непростим. Ми все ще боремося з проблемами затримки та «трилемою анонімності». Але прогрес очевидний. Незалежно від того, чи запускаєте ви вузол заради токенів, чи тому, що втомилися від стеження провайдерів, ви стаєте частиною створення стійкішої інфраструктури. Просто пам'ятайте: вчасно оновлюйте прошивку, стежте за температурою процесора і, заради всього святого, не загубіть свої приватні ключі.