Доказателства с нулево знание за поверителност в dVPN

Проблемът с доверието при традиционните VPN услуги

Замисляли ли сте се защо просто предоставяме целия си дигитален живот на даден VPN доставчик и се надяваме той да не наднича в него? Честно казано, изумително е, че през 2025 г. най-добрата ни защита на поверителността все още е „честна дума“ от страна на централизирана компания.

Повечето традиционни услуги гръмко рекламират своите политики за „липса на логове“ (no-logs), но като човек, занимаващ се с мрежи, аз виждам реалността на ниво пакети. Дори и да не записват историята на сърфирането ви, те все пак виждат реалния ви IP адрес и времевите данни в момента на свързване.

• Централизирани точки на отказ: Традиционните доставчици оперират върху клъстери, които те контролират. Ако правителство изиска данни чрез съдебна заповед или хакер получи администраторски достъп (root access), вашите данни са изложени директно в оперативната памет (RAM).
• Пропастта в доверието: Трябва да разчитате единствено на тяхната дума. Проучване на ExpressVPN от 2024 г. отбелязва, че потребителите на практика са принудени да се доверяват на честността на доставчика, тъй като не съществува технически начин да се провери какво точно се случва в техния бекенд.
• Закони за съхранение на данни: В много юрисдикции интернет доставчиците (ISP) и VPN компаниите са законово задължени да пазят определени метаданни, което прави „липсата на логове“ юридически невъзможна в тези региони.

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

Според Уикипедия, доказателствата с нулево знание (zero-knowledge proofs или ZKP) всъщност са концептуализирани още през 1985 г., за да решат точно тази каша – „доказване на идентичност без разкриване на тайни“. Най-накрая виждаме как тези концепции преминават от математическите трудове в реален програмен код.

В крайна сметка истинският проблем не са просто злонамерените субекти, а самата архитектура. Нуждаем се от система, при която мрежата може да потвърди, че сте платили или имате право на достъп, без реално да знае кой сте „вие“.

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

Какво всъщност представляват доказателствата с нулево знание?

Ако някога сте се опитвали да обясните криптографията на някой, който не е „мрежов експерт“, вероятно познавате това затруднение. Но доказателствата с нулево знание (zero-knowledge proofs или ZKP) всъщност са доста интуитивни, ако за момент спрете да мислите за прости числа и си представите една магическа пещера.

Класическият начин за обяснение е историята за пещерата на Али Баба. Представете си кръгла пещера с два пътя, А и Б, които се срещат при магическа врата в дъното. Пеги знае тайната дума за отваряне на тази врата; Виктор иска доказателство, че тя не лъже, но Пеги не иска да му издава самата парола.

За да го докаже, Пеги влиза в пещерата, докато Виктор чака отвън. След това Виктор извиква: „Излез от път А!“. Ако Пеги е при вратата, тя я отваря и се появява откъм указания път. Ако направят това 20 пъти и тя нито веднъж не сгреши, математическата вероятност тя да знае думата е почти сигурна. Това работи, защото всеки преминат кръг намалява наполовина шанса тя просто да е извадила късмет; след 20 кръга вероятността тя да е измамница е буквално едно на милион. В света на математиката това наричаме „надеждност“ (soundness).

Както отбелязват от Concordium, това е преходът от „споделяне на данни“ към „споделяне на доказателство“. За да може един протокол действително да се счита за ZKP, той трябва да отговаря на три технически критерия:

• Пълнота (Completeness): Ако твърдението е вярно, честният доказващ винаги ще убеди проверяващия. В логиката не са позволени „фалшиви отрицателни“ резултати.
• Надеждност (Soundness): Ако Пеги лъже, тя не трябва да може да подведе Виктор, освен при някакъв нищожен, астрономически малък шанс. Според NIST това често се нарича „ZKP на знанието“, където доказвате, че притежавате „свидетеля“ (witness) – тоест тайната.
• Нулево знание (Zero-knowledge): Това е най-важният елемент. Виктор не научава нищо за самата парола, а само факта, че Пеги я притежава.

В моята сфера на работа често разглеждаме идентичността като риск (liability). Ако един dVPN възел (node) знае вашия публичен ключ, това е информационна следа на ниво пакет. ZKP преобръща тази динамика.

Статия от 2024 г. на Concordium споменава, че за предприятията поверителността се превръща в „базово изискване“, а не просто в допълнителна функция. Независимо дали става въпрос за доказване на пълнолетие пред сайт за търговия или за проверка на здравно досие, ZKP ни позволява да обработваме логиката, без да излагаме самите данни на риск.

Следващата стъпка е да разгледаме как точно това поддържа вашия IP адрес скрит в една децентрализирана мрежа.

Прилагане на ZKP в dVPN екосистемата

И така, как всъщност взимаме тази математика от „магическата пещера“ и я внедряваме в една децентрализирана виртуална частна мрежа (dVPN)? Едно е да обсъждаме теорията на хартия, но когато се сблъскате с необработените пакети данни, преминаващи през даден възел (node), нещата бързо стават сложни. В стандартната мрежа сървърът обикновено проверява вашата самоличност чрез база данни – което е огромен червен флаг за поверителността.

Целта тук е анонимна автентификация. Искаме възелът да знае, че имате правото да използвате честотната лента (bandwidth), без да знае кой сте или каква е историята на вашите плащания.

Повечето съвременни dVPN проекти се насочват към zk-SNARKs (Succinct Non-Interactive Arguments of Knowledge). Както видяхме по-рано, те са изключително ефективни, защото не изискват постоянна комуникация напред-назад между страните.

• Доказателства за абонамент: Можете да докажете чрез блокчейн, че сте платили за месечен план. Възелът верифицира „доказателство“, че вашият портфейл е част от набора на „платилите“, без изобщо да вижда адреса на портфейла ви.
• Контрол на достъпа: Вместо потребителско име и парола, които интернет доставчикът (ISP) може да прехване или възелът да запише в лог файловете си, вие изпращате криптографско доказателство. Това е като да покажете значка „проверен“, без да показвате личната си карта.
• Репутация на възлите: Самите възли също могат да използват ZKP, за да докажат, че не са злонамерени – например да потвърдят, че не са манипулирали пакетите данни, без да разкриват вътрешната архитектура на сървъра си.

В една P2P мрежа вашият IP адрес е практически вашият домашен адрес. Ако операторът на даден възел е некоректен, той би могъл да записва всеки свързан IP адрес. Използвайки ZKP за установяване на връзката (handshake), ние разделяме „самоличността“ от „връзката“.

Според Cloudflare, те са започнали да използват доказателства от типа „един от много“ (one-out-of-many proofs) още през 2021 г. за частна уеб атестация. Това на практика позволява на потребителя да докаже, че принадлежи към група оторизирани потребители (като „платени абонати“), без да разкрива кой конкретен потребител е. Ако гигант от такъв мащаб използва тази технология за верификация на хардуер без изтичане на данни, бъдете сигурни, че dVPN платформите правят същото за потребителските сесии.

Проекти като squirrelvpn вече внедряват тези zk-SNARK ръкостискания, за да гарантират, че дори възелът, към който се свързвате, няма никаква представа кой сте в действителност.

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

Добив на пропускателна способност и токенизирани възнаграждения

Мислете за „добива на пропускателна способност“ (bandwidth mining) като за Airbnb на интернет. Вие позволявате на непознати да преминат през дигиталния коридор на вашата домашна мрежа, а в замяна получавате заплащане под формата на токени. Но без доказателства с нулево знание (ZKP), тези непознати — или самата мрежа — биха могли да видят твърде много от случващото се в дома ви.

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

• Доказателство за маршрутизиране (Proof of Routing): Използваме ZKP, за да потвърдим, че даден възел е обработил определен обем трафик. Възелът предоставя „доказателство“ на блокчейна, което съвпада с „разписката“ на потребителя, но нито една от страните не разкрива съдържанието на данните или крайната цел на пакетите.
• Токенизирани стимули: Операторите печелят възнаграждения въз основа на верифицирано време на работа (uptime) и пропускателна способност (throughput). Тъй като верификацията е с нулево знание, мрежата няма нужда да знае реалната самоличност на оператора, за да преведе токени в портфейла му.
• Справедлив обмен: Както се отбелязва в специализираната литература, тези протоколи гарантират, че „доказващият“ (възелът) може да убеди „проверяващия“ (мрежата), че работата е свършена, без да разкрива чувствителната информация, съдържаща се в тази работа.

Честно казано, виждал съм достатъчно примери за наблюдение от страна на интернет доставчиците (ISP), за да знам, че ако не анонимизирате слоя на плащанията, всъщност не сте защитени. Ако адресът на портфейла ви е свързан с вашия домашен IP адрес и логовете на трафика ви, тогава „VPN“ частта в dVPN става практически безполезна.

Следващата стъпка е да разгледаме как предпазваме мрежата от забавяне (лаг), докато се извършват всички тези сложни математически изчисления — „кратката“ (Succinct) част от пъзела.

Техническите предизвикателства пред ZKP в мрежовите технологии

Вижте, обожавам математиката зад доказателствата с нулево знание (ZKP), но трябва да бъдем реалисти – внедряването им в работеща мрежа в реално време е истинско главоболие. Едно е да докажеш, че знаеш тайна на черната дъска, съвсем друго е да го направиш, докато някой се опитва да стриймва 4K видео през децентрализиран възел (node).

„Краткият“ (Succinct) елемент в zk-SNARKs теоретично трябва да прави нещата бързи, но генерирането на тези доказателства все още консумира процесорни цикли (CPU cycles) като за световно. Ако телефонът ви трябва да извършва тежки изчисления само за да удостовери един пакет данни, батерията ви ще се срине, а латентността (latency) ще скочи до небето.

От моя опит в анализа на ниво пакет, всяка милисекунда е от критично значение за маршрутизирането. Когато добавите ZKP, вие на практика налагате „изчислителен данък“ върху всяко ръкостискане (handshake) на протокола.

• Натоварване на процесора (CPU Overhead): Генерирането на доказателство е много по-трудно от неговата проверка. Повечето потребители на dVPN използват мобилни устройства или евтини рутери, които не са точно суперкомпютри, така че страната на „доказващия“ (prover) се превръща в тясно място.
• Бъгове в логическите вериги (Circuit Bugs): Ако математиката не е перфектна, се получават „недостатъчно ограничени вериги“ (under-constrained circuits). Докладите за сигурност от компании като Trail of Bits отбелязват, че огромното мнозинство от SNARK бъговете идват именно от такива логически пропуски, чрез които хакер потенциално би могъл да фалшифицира доказателство.
• Мрежово забавяне: Интерактивните доказателства изискват постоянна комуникация напред-назад. Дори при неинтерактивните, самият размер на някои доказателства може да бъде проблем. Например, zk-STARKs са различен тип ZKP, които не изискват „доверена настройка“ (trusted setup), което ги прави по-сигурни, но те имат много по-голям размер на доказателствата, което може да задръсти точно тази честотна лента, която се опитвате да пестите.

Честно казано, повечето разработчици все още се опитват да намерят онази „златна среда“, в която сигурността е безкомпромисна, но интернетът не се усеща като dial-up връзка от 1995-та.

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

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

И така, каква е крайната цел на цялата тази математика? Честно казано, предстои ни пълна трансформация, при която „поверителност чрез дизайн“ (privacy by design) няма да бъде просто маркетингов слоган, а твърдо кодирана реалност в мрежата.

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

Следващата ера на интернет няма да се определя от това кой събира най-много данни, а от това кой ще намери начин да се нуждае от най-малко. Тук се появяват zkVM (виртуални машини с нулево знание). Те ни позволяват да изпълняваме сложна логика – като например проверка дали потребителят е в ограничен регион или има валиден абонамент – извън блокчейна (off-chain), след което просто да публикуваме малко доказателство.

• Мащабиране на поверителността: Инструменти като RISC Zero или Succinct Labs позволяват на разработчиците да пишат логика за доказателства с нулево знание (ZKP) на стандартни езици като Rust. Това означава, че децентрализираните VPN мрежи (dVPN) могат да се мащабират без огромния „изчислителен данък“, за който говорихме по-рано.
• Устойчивост на цензура: Когато даден възел (node) не знае кой сте или до какво осъществявате достъп, за правителствата е много по-трудно да принудят този възел да ви блокира.
• Приемане от бизнеса: Както споменаха от Concordium, компаниите започват да гледат на данните като на пасив (liability). Ако те не съхраняват вашите данни, няма как да ги загубят при пробив в сигурността.

Технологията все още е в ранен етап, но посоката е ясна. Изграждаме интернет, в който не е нужно да молите за поверителност – тя е заложена по подразбиране на ниво протокол. До следващия път, когато ще се потопим в детайлите.