Доказателства с нулево знание за анонимно маршрутизиране

Проблемът с традиционното маршрутизиране и защо се нуждаем от ZKP

Запитвали ли сте се някога дали вашата VPN услуга, която обещава „без съхранение на логове“ (no-logs), е наистина толкова защитена, колкото твърди рекламата? Трудно е за вярване, но традиционното маршрутизиране – дори и криптираното – е фундаментално компрометирано, тъй като разчита на сляпо доверие в централни органи и статични пътища, които са изненадващо лесни за манипулиране.

Повечето хора си представят VPN услугата като магически тунел, но под повърхността тя представлява просто поредица от „ръкостискания“ (handshakes) със сървъра на доставчика. Проблемът е, че тези сървъри се превръщат в централни точки на отказ. Дори ако доставчикът твърди, че не събира данни, вие все още залагате поверителността си на неговата дума и на физическата сигурност на неговия център за данни.

• Парадоксът на „липсата на логове“: Трябва да вярвате, че доставчикът не е притиснат от държавни органи или че не е станал жертва на незабелязан пробив. Ако централният сървър бъде компрометиран, вашите метаданни – кой сте и накъде отива трафикът ви – стават напълно открити.
• Нечестни възли в P2P мрежите: В децентрализираните мрежи често се сблъскваме с „лъжливо маршрутизиране“. Даден възел (node) може да заяви, че разполага с най-бързия път до дестинацията, само за да прехване пакетите ви за анализ – класически сценарий за атака тип „човек по средата“ (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 е рамката, която ни позволява да изграждаме тези анонимни пътища без нуждата от централизиран администратор.

Обикновено, ако един рутер иска да докаже, че може да достигне до дадена дестинация, той трябва да разкрие своята таблица за маршрутизиране или вътрешни схеми. За един интернет доставчик (ISP) или болнична мрежа това е кошмар за сигурността. Джейкъб Д. Уайт от Националната лаборатория Лос Аламос (2023) представи ZKPNet – библиотека, базирана на Rust, която създава „джаджи“ (gadgets) за тези удостоверявания.

• Минимален отпечатък: Тези доказателства са миниатюрни – понякога само 224 байта при използване на groth16. Можете да ги вмъкнете в хедъра, без да превишавате максималния размер на пакета (MTU).
• Доказуема достижимост на един скок: Един възел може да докаже, че има валиден път до „Рутер Y“, без да показва колко точно скока (hops) са необходими или как изглеждат вътрешните IP адреси.
• Компромиси с производителността: Латентността в реално време е голямото предизвикателство тук. Бенчмарковете на M1 Max показват, че генерирането на доказателство отнема около 468 ms. В света на мрежите 468 ms са цяла вечност за един пакет, затова ZKP не се използва за всеки бит данни. Вместо това, доказателствата с нулево знание се прилагат за операции в контролния равнин (control-plane) – например при установяване на пътя – докато реалните данни преминават светкавично, след като „доверието“ вече е изградено.

От друга страна имаме sPAR (Донякъде практически анонимен рутер), който се опитва да реши проблема с изискването за „честен възел“ в системи като Tor. Както посочват Дебаджиоти Дас и Джонгън Парк (2025), sPAR използва многостранно напълно хомоморфно криптиране (FHE), така че дори рутерът да не знае накъде препраща информацията.

Интересната част е как се избягва „проблемът с колизиите“. Ако много потребители се опитат да използват един и същ слот от честотната лента, данните се повреждат. sPAR използва стратегия за избор от три – математически трик с „топки и кутии“ – при който клиентът избира три произволни индекса и съобщението попада в първия свободен.

• Хомоморфно позициониране: Сървърът поставя вашия пакет в „кофа“ (bucket), без изобщо да вижда избрания от вас индекс. Всичко това се случва, докато данните са все още криптирани.
• Лимити на мащабиране: Към момента sPAR няма да замени глобалната мрежа. Системата поддържа около 128 потребители с латентност от няколко секунди, което я прави идеална за нишови приложения като миксиране на крипто транзакции или частни съобщения в локална мрежа (LAN).

Представете си търговска верига, която трябва да синхронизира наличностите си. Чрез маршрутизиране в стил sPAR, централният сървър не може да картографира кой магазин коя актуализация изпраща. Това пречи на конкурентите да разберат кои локации са най-печеливши въз основа на обема на мрежовия трафик.

Добиване на лентова способност и икономика на токенизираните мрежи

Замисляли ли сте се някога как домашният ви интернет просто стои неизползван, докато сте на работа или спите? В същността си това е пропилян актив – точно като празна стая за гости, която никога не отдавате под наем.

Цялото движение DePIN (Децентрализирани физически инфраструктурни мрежи) променя това, създавайки нещо като „Airbnb за интернет трафик“. Вместо само да плащате на вашия доставчик всеки месец, вече можете действително да печелите криптовалута, като споделяте неизползваната си връзка с глобална P2P (мрежа от типа „равен към равен“) мрежа.

Изграждането на децентрализирана VPN мрежа (dVPN) или прокси мрежа изисква хиляди възли (нодове), за да бъде тя наистина полезна. За да мотивират хората да поддържат тези възли, проектите използват токенизирани стимули. Вие осигурявате „тръбата“, а мрежата ви плаща в полезни токени (utility tokens).

Тук обаче възниква сериозно техническо предизвикателство: как мрежата да разбере, че наистина предоставяте качествена лентова способност, без да шпионира трафика, който пренасочвате? Ако даден възел започне да логва потребителски данни, за да „докаже“, че работи, целият аспект на поверителността в една Web3 VPN услуга изчезва.

• Добиване на лентова способност (Bandwidth Mining): Потребителите инсталират лек клиент за възел, който допринася с изходящ капацитет към мрежовия пул. Наградите обикновено се изчисляват въз основа на времето на активна работа (uptime), пропускателната способност и географското търсене.
• Доказателства със запазване на поверителността: Тук технологията ZKP (доказателства с нулево знание) е истинско спасение. Можете да докажете достъпност и съответствие с протокола, без да разкривате съдържанието на пакетите или вътрешните карти на мрежата.
• Качество на услугата (QoS): Възлите могат да предоставят „Доказателство за лентова способност“ (Proof of Bandwidth), което използва математически атестации, за да потвърди, че не ограничават трафика или не „поглъщат“ пакети (blackholing).

Ако искате да следите как се развиват тези специфични VPN протоколи, посещаването на SquirrelVPN за последните новини в областта на VPN технологиите и сигурността е отличен ход. Те следят отблизо прехода от централизирани центрове за данни към тези модели с разпределени възли.

„Икономическата“ част на този процес се случва изцяло в блокчейна (on-chain). Смарт договорите действат като автоматизиран посредник, управляващ обмена между потребителите, които се нуждаят от поверителност, и операторите на възли, които разполагат с излишна лентова способност.

• Автоматизирани P2P плащания: Вместо месечен абонамент към гигантска корпорация, плащате точно за това, което използвате. Смарт договорът освобождава микроплащания към доставчиците на възли в реално време.
• Устойчивост срещу Сибила атаки (Sybil Attack): Ако един човек пусне 1000 фалшиви възела от един сървър, това би съсипало децентрализацията на мрежата. Протоколите за доказателство на лентова способност – често подкрепени от изисквания за стейкинг (staking) – правят „лъженето“ за наличните ресурси икономически неизгодно.

В нашия пример със здравеопазването, една клиника би могла да плаща за лентова способност в такава мрежа, използвайки токени. Тъй като мрежата използва логиката на sPAR, клиниката получава анонимност, а операторите на възли получават заплащане – и всичко това, без интернет доставчикът да може да види моделите на трафика между клиниката и болницата.

Детайлен преглед на техническия протоколен слой

Преминаваме от икономическия модел към същинския технически слой на протокола. Тук ще разгледаме в детайли как точно интегрираме тези доказателства в мрежовия пакет.

Истинският пробив тук е елиминирането на единната точка на отказ (single point of failure). При стандартните архитектури един субект държи „ключовете от замъка“. Но чрез използването на многостранно напълно хомоморфно криптиране (multi-party fully homomorphic encryption - fhe), можем да генерираме общ публичен ключ, при който буквално никой не притежава главната тайна (master secret).

• Съвместно генериране на ключове (Joint Key Generation): По време на първоначалната настройка всеки участник създава свой собствен таен ключ. Те се комбинират в един общ публичен ключ ($pk$). Както е посочено в разработките на Дебаджиоти Дас и Джонгън Парк (2025) относно sPAR, главният таен ключ е просто сбор от всички индивидуални ключове. Тъй като никой не споделя своя ключ, „целият“ ключ не съществува на нито едно физическо място.
• RLWE (Ring Learning With Errors): Това е математическата основа на системата. На достъпен език, RLWE е сложен пъзел, при който към данните се добавя минимално количество „шум“. За компютрите е изключително трудно да разрешат този пъзел в обратна посока, което ни осигурява ind-cpa сигурност (това означава, че атакуващият не може да различи две различни криптирани съобщения, дори ако предполага какво е съдържанието им).

Структура на пакета: Къде се съхранява доказателството?

Къде точно се вписват тези 224 байта ZKP (доказателство с нулево знание)? В съвременната IPv6 архитектура използваме разширителни заглавни части (Extension Headers). По-конкретно, прилагаме персонализирано заглавие за „Опции на дестинацията“ (Destination Options).

Чрез поставянето на доказателството в разширителното заглавие, рутерите, които не поддържат ZKPNet, могат просто да препратят пакета. „ZKP-ориентираните“ възли обаче ще спрат, ще верифицират доказателството за 2.7ms и едва тогава ще го препратят. Ако доказателството е невалидно, пакетът се отхвърля незабавно.

• Защита срещу двусмислие (Equivocation Protection): Предотвратяваме възможността възлите да подават невярна информация, като вграждаме историята на комуникацията в самите ключове. Използвайки хеш от историята на обмена за актуализиране на публичния ключ при всеки рунд, ако сървърът се опита да покаже на потребител А различна „реалност“ от тази на потребител Б, математическата логика се нарушава и операцията става невалидна.
• Верифицируемо fhe: Вместо просто да се доверяваме на даден възел, че извършва изчисленията правилно, използваме верифицируемо fhe. Това действа като дигитална касова бележка, която доказва, че сървърът е изпълнил протокола точно според зададените правила.

В нашия сценарий за търговски обекти, именно този технически слой позволява на 100 магазина да синхронизират данни помежду си. Стратегията за избор на маршрут тип „избор от три контейнера“ гарантира, че дори ако атакуващ прехване пакета и анализира IPv6 заглавието, той не може да разбере от кой точно магазин произхождат данните. Това е възможно, защото ZKP доказва валидността на пътя, без да разкрива самоличността на източника.

Бъдещето на DePIN и устойчивият на цензура интернет

Ако трябва да бъдем честни, съвременният интернет представлява поредица от „затворени градини“, които само се преструват на глобално споделено пространство. В предходните раздели обсъдихме как доказателствата с нулево знание (ZKP) и peer-to-peer (P2P) капацитетът на мрежата могат да поправят „тръбите“ на системата, но истинският въпрос е как всичко това ще се мащабира, когато милиони хора се опитват да стриймват видео едновременно.

Мащабирането на тези протоколи е изключително сложно предизвикателство заради т.нар. „трилема на анонимността“. Обикновено трябва да избирате между две от трите: силна поверителност, ниска латентност (закъснение) или нисък разход на мрежови ресурс. Анализът на комплексни системи като Tor показва, че дори при „перфектна“ криптография, все още сте уязвими към атаки на системно ниво, като корелация на трафика, ако мрежата не е достатъчно плътна.

Най-голямото тясно място за една децентрализирана мрежа от физическа инфраструктура (DePIN) е съотношението между „размера на доказателството“ и „времето за неговото генериране“. Ако всеки пакет в една Web3 VPN услуга изисква Groth16 доказателство, рутерът ви просто ще прегрее. За да решим този проблем, се насочваме към рекурсивни доказателства.

• Рекурсивни SNARK-ове: Вместо да верифицира 1000 индивидуални доказателства за пакети, даден възел може да ги „обедини“ (roll up) в едно единствено мета-доказателство. Това е като руска матрешка, при която външният слой доказва валидността на всичко, което се намира вътре.
• Свиване на състоянието (State Shrinking): Това поддържа размера на блокчейна управляем. Вместо всеки възел да съхранява цялата история на мрежата, е необходимо само да се верифицира последното рекурсивно доказателство, за да се потвърди, че таблицата за маршрутизиране е коректна.

Бизнесът започва да осъзнава, че централизираните VPN услуги са риск за сигурността на данните. Разпределените мрежови възли правят таргетирането на подобна инфраструктура много по-трудно.

• Маршрутизиране, базирано на изкуствен интелект: Наблюдаваме преход към софтуерно дефинирани мрежи (SDN), където AI агенти избират в реално време най-устойчивия на цензура път за данните.
• Заобикаляне на интернет доставчиците (ISP Bypass): Чрез токенизация на свързаността ние на практика изграждаме паралелен интернет. Вече не става въпрос само за скриване на вашия IP адрес; става въпрос за притежание на инфраструктурата, така че доставчикът на интернет да не може просто да „дръпне шалтера“ и да прекъсне достъпа ви.

Ръководство за внедряване за оператори на възли

Вече сте се запознали с математиката и теорията, но вероятно се питате как всъщност да стартирате собствен възел. Честно казано, конфигурирането на възел с поддръжка на доказателства с нулево знание (ZKP) е проект, който ще ви отнеме един уикенд, но това е единственият начин да преминете от „доверявам се на VPN доставчик“ към „доверявам се на законите на физиката“.

Спецификации и настройка на възела

Не се нуждаете от сървърна ферма, но и не можете да го подкарате на тостер.

• Минимални изисквания: Бих казал да се целите в поне 8GB RAM и съвременен 4-ядрен процесор.
• Мрежа: Симетричната оптична връзка е идеалният вариант, но са необходими поне 20Mbps скорост на качване (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 доказателство (отнема ~468ms)
    let proof = Prover::prove(circuit, &params).expect("Генерирането на доказателство неуспешно");

    // 3. Прикачване на 224-байтовото доказателство към разширения заглавен блок на IPv6 (Extension Header)
    packet.attach_header(0xZK, proof.to_bytes());
}

Когато настройвате бекенда, помнете, че времето за генериране на доказателство е критичният фактор — отнема почти половин секунда. Ако конфигурирате това, уверете се, че вашият възел не се опитва да доказва всеки отделен пакет. Вместо това трябва да използвате вероятностни доказателства или групиране (batching). Вие доказвате, че сте обработили коректно даден прозорец от трафик по време на фазата на установяване на пътя.

1. Проблеми с двоен NAT (Double NAT): Ако вашият възел е зад два рутера, P2P откриването ще се провали. Използвайте UPnP или ръчно пренасочване на портове (port forwarding).
2. Отклонение на часовника (Clock Skew): ZKP и блокчейн протоколите са чувствителни към времето. Стартирайте локален NTP демон.
3. Изтичане на IPv6 (IPv6 Leaks): Много хора конфигурират своя VPN възел за IPv4, но забравят, че техният доставчик (ISP) раздава и IPv6 адреси.

Преходът от централизиран интернет към децентрализиран такъв, задвижван от ZKP, ще бъде труден. Все още се борим с проблемите на латентността и „трилемата на анонимността“. Но прогресът е реален. Независимо дали поддържате възел заради токените или защото ви е писнало от наблюдението на интернет доставчиците, вие сте част от изграждането на една по-устойчива инфраструктура. Само помнете: обновявайте фърмуера си, следете температурата на процесора и за нищо на света не губете частните си ключове.