Comparisons

Note on comparisons: All technical comparisons in this document describe architectural approaches and design trade-offs, not critiques of specific products. Software evolves. The focus is on helping you understand where Shurli fits. If you spot an inaccuracy, corrections are welcome via GitHub issues or pull requests.

How does Shurli differ from centralized VPN tools?

The core architectural difference comes down to how coordination works.

Centralized VPN tools use a coordination server controlled by the vendor. Your devices register with that server, authenticate through it, and rely on it to broker connections. Your identity lives in their database, your device graph is visible to their infrastructure, and your ability to connect depends on their service being online and their terms remaining acceptable.

Shurli takes the opposite approach: fully decentralized coordination via a Kademlia DHT and local configuration files. Identity is an Ed25519 key pair generated on your machine. Authorization is a local authorized_keys file listing which peer IDs are allowed. There is no account, no sign-in, no external dependency for authentication or discovery.

Architecture

Privacy & Sovereignty

Features

Strengths of the decentralized approach

• No central authority - No account, no coordination server, no vendor dependency
• Importable library - pkg/sdk can be embedded into any Go application
• CGNAT/Starlink proven - Relay-based architecture works through symmetric NAT
• Self-hosted relay - You run your own relay on a $5 VPS
• GPU inference use case - Purpose-built for exposing Ollama/vLLM through CGNAT

Strengths of the centralized approach

• IP-layer VPN - Virtual network interface; any protocol works transparently
• Mature ecosystem - Mobile apps, web dashboard, ACLs, SSO, subnet routing
• Performance - WireGuard is kernel-level and extremely fast
• Scale - Handles thousands of devices in an organization
• Zero config - “Install and sign in” onboarding
• Platform coverage - Runs everywhere including iOS, Android, containers

Self-hosted control planes: a middle ground

Some open-source projects offer self-hosted coordination servers that eliminate the vendor dependency. You run the coordination server yourself, so there is no third-party account requirement and no external control over your network. However, the architecture still requires a coordination server - it is self-hosted rather than vendor-hosted, but not eliminated. The WireGuard transport layer remains the same, and you still manage a centralized piece of infrastructure. These sit in between: more sovereign than a vendor-hosted control plane, less decentralized than Shurli’s DHT-based approach.

How does Shurli differ from other P2P and mesh tools?

The P2P networking landscape includes several architectural approaches. Each makes different trade-offs around NAT traversal, relay strategy, onboarding, and sovereignty.

Architecture categories

libp2p-based overlay networks

Some projects use the same libp2p stack as Shurli but operate at the IP layer (TUN/TAP VPN) rather than TCP service proxy. They use DHT for discovery and NAT hole-punching via libp2p, with IPv6 routing support. The key architectural difference: IP-layer operation (requiring TUN interfaces and root privileges) vs TCP service proxy (user-space, no special privileges). These typically have no invite/onboarding flow or relay-first architecture.

QUIC-native P2P tools

Some projects use QUIC directly instead of libp2p, building P2P reverse proxies with NAT traversal inspired by tools like frp, ngrok, or rathole. Without libp2p, they lack DHT discovery, the broader protocol ecosystem, and typically require manual configuration rather than automated onboarding.

DHT-assisted hole-punching libraries

Several P2P networking libraries provide DHT-assisted hole punching as building blocks rather than end-user tools. Their DHT nodes actively assist with hole punching coordination, which can achieve higher success rates in some NAT scenarios because the DHT nodes actively broker the handshake. These power encrypted P2P communication apps and data replication systems.

QUIC-based P2P connectivity libraries

Some Rust-based libraries offer “dial by public key” P2P connectivity with higher NAT traversal success rates than libp2p (~90%+ vs ~70%), using aggressive probing and multiple strategies. These are libraries, not end-user tools. Some have transport adapters for integration with libp2p, allowing their NAT traversal to be used within libp2p-based applications.

Certificate-based overlay networks

Some projects use a certificate authority model with custom protocols (not WireGuard, not libp2p) to create full mesh overlay networks. Lighthouse nodes help peers discover each other’s addresses. The critical limitation: no relay fallback. If hole-punching fails (e.g., behind CGNAT or Starlink), the connection simply does not work.

Self-hosted coordination planes

Several projects offer self-hosted alternatives to centralized VPN services, providing open-source coordination servers, management dashboards, and signal servers. These are WireGuard-based, not libp2p. They replicate the architecture of centralized VPN tools with self-hosted infrastructure, rather than building something structurally different.

Architecture comparison

Blockchain P2P networks as reference points

These are not competitors but useful reference points. Their P2P stacks solve different problems (block propagation, consensus) but share underlying technology with Shurli:

How do relay architectures compare?

Three broad approaches to relay design exist in the P2P networking space: self-hosted relays where you control the infrastructure, vendor-operated relays where the service provider runs them, and persistent relay services that maintain always-on connections.

Hole-punching success (when no relay is needed)

Important: With Starlink CGNAT (symmetric NAT), hole-punching success is 0% for all of them. Every single one falls back to relay. The hole-punch success rates only matter for regular NAT (home routers, etc.).

Relay quality (when traffic stays on relay)

All three are roughly equivalent in relay quality. The relay is a dumb pipe forwarding encrypted bytes. Performance depends on infrastructure, not protocol.

Connection establishment speed

Circuit Relay v2 is slower because it involves a reservation step and DHT lookup. Persistent and vendor-operated relays maintain always-on connections.

How do P2P networking stacks compare?

These comparisons are reference points showing where Shurli’s libp2p foundation sits in the broader P2P landscape. Bitcoin and Ethereum are not competitors - they solve different problems (block propagation, consensus) - but their P2P stacks share enough architectural overlap to be instructive.

Bitcoin’s P2P stack

Bitcoin’s P2P protocol has less overhead per message, but it cannot do what Shurli needs.

The comparison

Why Bitcoin P2P is “faster”

It is simpler, not fundamentally faster. Bitcoin uses raw TCP with a 24-byte binary header and zero encryption. No protocol negotiation, no multiplexing, no security handshake. It is lean because it trusts nothing at the network layer - blocks are verified cryptographically after receipt anyway.

Why it does not matter for Shurli

Bitcoin P2P cannot traverse NAT or CGNAT at all. If both sides cannot directly reach each other, Bitcoin nodes simply cannot connect inbound. Users behind ISP CGNAT cannot run full Bitcoin nodes that accept inbound connections. Bitcoin originally had UPnP enabled by default but disabled it due to miniupnpc vulnerabilities. It now uses PCP (Port Control Protocol), which ISP CGNAT equipment intentionally blocks.

NAT/CGNAT traversal is Shurli’s entire reason for existing.

The key research finding

A 2021 study implemented Bitcoin’s block exchange protocol on top of libp2p and found:

“Setting up communication channels is time-consuming, but data transfers are fast”

Once the connection is established, bulk throughput is comparable. The overhead is in the handshake, not the data flow. For Shurli’s use case (long-lived connections proxying SSH, Ollama, XRDP), connection setup latency is a one-time cost that becomes irrelevant.

Source: Barbara Guidi, Andrea Michienzi, Laura Ricci. “A libP2P Implementation of the Bitcoin Block Exchange Protocol.” Proceedings of the 2nd International Workshop on Distributed Infrastructure for Common Good (DICG ‘21), ACM, 2021. DOI: 10.1145/3493426.3493822

What Shurli does to close the gap

These optimizations shipped in Phase 4C:

1. QUIC transport (done) - saves 1 RTT on connection setup (3 RTTs vs 4 for TCP)
2. DCUtR hole punching (done) - bypass relay entirely for direct peer-to-peer
3. Parallel dial racing (done, Batch I) - race DHT and relay in parallel, first wins
4. STUN probing (done, Batch I) - classify NAT type, predict hole-punch success

Once hole punching succeeds, Shurli is essentially just encrypted TCP with 12 bytes of Yamux framing per frame - very close to Bitcoin’s raw TCP speed but with encryption and NAT traversal. Connection warmup and stream pooling remain as future optimizations.

Bottom line

Bitcoin P2P is lean but primitive. It solved a different problem: broadcasting blocks to publicly-reachable nodes. Shurli needs relay + hole punching + encryption, and libp2p is the right tool for that. The performance gap narrows dramatically with QUIC + connection pooling + DCUtR direct connections.

Ethereum’s P2P stack

Ethereum is the most relevant comparison because its consensus layer uses the same libp2p stack that Shurli is built on. Ethereum actually runs two separate P2P networks.

Ethereum’s two P2P layers

Execution layer (devp2p/RLPx) - the original Ethereum networking, predating The Merge:

Consensus layer (libp2p) - adopted for the Beacon Chain (post-Merge):

Why Ethereum chose libp2p for consensus

When Ethereum needed a P2P networking stack for the Beacon Chain - the system securing hundreds of billions of dollars - they evaluated their options and chose libp2p. The reasons:

1. Modularity - swap transports, security, multiplexers independently
2. Multi-language support - Go (Prysm), Rust (Lighthouse), Java (Teku), .NET (Nethermind) all have libp2p implementations
3. Stream multiplexing - essential for gossipsub topic subscriptions
4. Noise protocol - mutual authentication during handshake

Why Ethereum chose discv5 over libp2p’s Kademlia for discovery

Ethereum’s consensus layer uses libp2p for transport and encryption but not for peer discovery. They built discv5 instead:

The key reason: Kademlia DHT maintains routing tables and handles both content routing and peer discovery, which generates more background traffic than needed for pure discovery. discv5 does one thing - find peers - and does it with less bandwidth overhead.

For Shurli: Kademlia DHT is the right choice today because Shurli uses it for both peer discovery and rendezvous coordination, and the bandwidth overhead is negligible at current network sizes. The discv5 approach becomes interesting at larger scales where DHT maintenance traffic is measurable.

What this means for Shurli

Shurli’s libp2p foundation is validated by Ethereum’s consensus layer - the same networking stack secures one of the largest decentralized networks in existence. Shurli also benefits from improvements driven by Ethereum’s scale: gossipsub optimizations, Noise protocol hardening, and transport upgrades all flow back to the shared libp2p codebase.

Where Shurli goes further than Ethereum’s usage:

• Full NAT traversal (AutoNAT v2, circuit relay, DCUtR) - Ethereum validators do not need this
• QUIC as preferred transport - Ethereum consensus still primarily uses TCP
• WebSocket for anti-censorship - Ethereum has no DPI evasion story
• Point-to-point service proxy - different use pattern than gossipsub broadcast

What does Shurli ship that others don’t?

Built-in observability

Most P2P tunnel tools ship with no metrics, no traces, and no structured audit logs. DevOps teams bolt on monitoring after the fact, poorly.

Shurli ships with 53 custom Prometheus metrics (proxy, auth, vault, pairing, deposits, admin socket, ZKP proving/verification, grants, transfers, plugins) alongside libp2p built-in metrics, structured audit logging, and a pre-built Grafana dashboard with 56 panels out of the box. No other P2P tunnel tool ships with this level of built-in observability.

What’s next: Distributed tracing (deferred - 35% CPU overhead not justified yet). OTLP export via Prometheus bridge when users request it.

What are the open problems in P2P networking?

These are genuine gaps in every P2P/VPN/tunnel tool available today, including Shurli:

1. Zero-RTT proxy connection resume

When your network flickers (WiFi to cellular, WiFi dropout), every existing tool drops connections and requires a full reconnection handshake. QUIC 0-RTT session tickets could make reconnection instant - send encrypted data before the server processes the handshake.

Who has it: Nobody in the P2P tunnel space. Difficulty: Medium (requires QUIC transport + session ticket caching).

2. Hardware-backed peer identity

No P2P tool stores peer private keys in TPM 2.0 (Linux servers) or Secure Enclave (macOS/iOS). Keys sit on disk, stealable by anyone with filesystem access.

Who has it: Nobody. Difficulty: Medium (platform-specific APIs: go-tpm, Security.framework).

3. Kernel-bypass relay forwarding

Every relay server processes packets through the kernel network stack (syscalls per packet). eBPF/XDP or DPDK could forward relayed packets at line rate - benchmarks show DPDK achieves 51% better throughput than kernel stack, VPP uses 1/9th the CPUs.

Who has it: Nobody (Cloudflare uses XDP for DDoS, not for relay forwarding). Difficulty: High (Linux-only, requires privileged access).

4. Formally verified protocol state machine

No P2P tool has mathematically proven that its handshake / invite / key exchange protocol is correct. Bugs in state machines cause security vulnerabilities. Formal verification tools like Kani (Rust) and TLA+ can prove correctness.

Who has it: AWS s2n-quic (QUIC only, not application layer). Bert13 (first formally-verified post-quantum TLS 1.3 in Rust). Difficulty: High (requires Rust migration for Kani, or TLA+ model of invite protocol).

5. Cryptographic agility (post-quantum ready)

No P2P tool supports cipher suite negotiation or hybrid classical + post-quantum handshakes. When ML-KEM mandates arrive (2026-2028), every tool will need emergency patches.

Who has it: Nobody in P2P. AWS and Microsoft are preparing at the infrastructure layer. Difficulty: Medium (design cipher negotiation now, implement when libp2p adopts PQC).

Last Updated: 2026-02-28