Sebastian Bürgel(@SCBuergel):We're thinking about this at Gnosis VPN. A mixnet like HOPR can in principle route every packet over a different path to a different exit. The hard part is using that in practice. Gnosis VPN establishes prepaid sessions to an exit. Relays are paid per packet and the exit can only answer through SURBs (single-use reply blocks) the client sends ahead, so it can reply without learning who you are. In theory sessions could be tiny and switch constantly, e.g. keep 100 open and cycle them per target IP. But: 1. Every session has setup overhead through the mixnet 2. Sizing prepayment for tiny sessions is hard: Prepay too little and the session runs dry mid-transfer and stalls while it tops up. Prepay enough to be safe and most of it expires unused. 3. Each session needs its own SURBs sent upfront, so uplink bandwidth scales with the number of sessions rather than with traffic The deeper problem is that the VPN's network interface only sees packets. It can't tell where one request to a server ends and the next begins, and each TCP/QUIC connection is pinned to one exit anyway. HTTP/2 puts many requests on one connection, many sites and apps sit behind the same CDN IPs, and TLS resumption and cookies relink whatever you manage to split. The VPN could try to guess request boundaries from timing, treating an idle gap on a connection as the end of a request. That isn't great either: - HTTP/2 and QUIC run concurrent requests on one connection, so many boundaries have no gap at all. - Keepalives and background traffic keep connections busy, hiding the gaps that do exist. - Any gap threshold is a guess: too short and it splits mid-request, too long and it misses most boundaries. - Even after detecting a gap, the VPN can't move a live connection to another exit. It has to reset the connection to force a reconnect, which costs a full handshake through the mixnet. - The reconnect then usually resumes the old TLS session, which relinks it on the server side anyway. The good news is that the VPN doesn't need to guess. Split tunnelling isolates the apps that matter, like your zkAPI CLI, from the rest of your traffic (like a long running Jitsi call with totally different traffic pattern and trust assumptions). On top of that we can expose a local SOCKS endpoint where each isolation key maps to its own exit from a pool of pre-warmed sessions. The app knows what a request is, so it uses a fresh key and a fresh connection per request, and you get request-by-request delinking for exactly the traffic that needs it.

2026.10.04 09:58

We're thinking about this at Gnosis VPN. A mixnet like HOPR can in principle route every packet over a different path to a different exit. The hard part is using that in practice. Gnosis VPN establishes prepaid sessions to an exit. Relays are paid per packet and the exit can only answer through SURBs (single-use reply blocks) the client sends ahead, so it can reply without learning who you are. In theory sessions could be tiny and switch constantly, e.g. keep 100 open and cycle them per target IP. But: 1. Every session has setup overhead through the mixnet 2. Sizing prepayment for tiny sessions is hard: Prepay too little and the session runs dry mid-transfer and stalls while it tops up. Prepay enough to be safe and most of it expires unused. 3. Each session needs its own SURBs sent upfront, so uplink bandwidth scales with the number of sessions rather than with traffic The deeper problem is that the VPN's network interface only sees packets. It can't tell where one request to a server ends and the next begins, and each TCP/QUIC connection is pinned to one exit anyway. HTTP/2 puts many requests on one connection, many sites and apps sit behind the same CDN IPs, and TLS resumption and cookies relink whatever you manage to split. The VPN could try to guess request boundaries from timing, treating an idle gap on a connection as the end of a request. That isn't great either: - HTTP/2 and QUIC run concurrent requests on one connection, so many boundaries have no gap at all. - Keepalives and background traffic keep connections busy, hiding the gaps that do exist. - Any gap threshold is a guess: too short and it splits mid-request, too long and it misses most boundaries. - Even after detecting a gap, the VPN can't move a live connection to another exit. It has to reset the connection to force a reconnect, which costs a full handshake through the mixnet. - The reconnect then usually resumes the old TLS session, which relinks it on the server side anyway. The good news is that the VPN doesn't need to guess. Split tunnelling isolates the apps that matter, like your zkAPI CLI, from the rest of your traffic (like a long running Jitsi call with totally different traffic pattern and trust assumptions). On top of that we can expose a local SOCKS endpoint where each isolation key maps to its own exit from a pool of pre-warmed sessions. The app knows what a request is, so it uses a fresh key and a fresh connection per request, and you get request-by-request delinking for exactly the traffic that needs it.

커뮤니티로 전달