I2P never routes a message through one shared circuit like a VPN, and never reuses the same path both ways like Tor. Every peer keeps separate pools of short-lived outbound tunnels (for messages it sends) and inbound tunnels (for messages it receives), each direction independently garlic-routed through different, randomly chosen hops:
Sender → [OB hop 1 → hop 2 → … → hop L] → gateway
Recipient's [IB gateway → hop 2 → … → hop L] → Recipient
A hop only ever learns the previous and next hop — never the full path, and never both endpoints — unless the adversary controls a hop directly. What matters for de-anonymization is not the middle of the tunnel but its endpoints: the first outbound hop (sees the sender) and the inbound gateway (feeds the recipient). If an adversary controlling a fraction f of all routers lands on both endpoint roles for the same exchange, it can correlate message timing across the gap and link sender to recipient — this simulator's core formula:
p(single tunnel pair compromised) ≈ f²
risk after N tunnel-pool builds ≈ 1 − (1 − p)ᴺ
Two consequences this model makes visible: (1) adding more hops raises latency and per-hop overhead but does not reduce endpoint-compromise probability, since only the two endpoint hops matter statistically; (2) a low per-build risk still creeps toward certainty as a session accumulates many tunnel rebuilds (I2P rebuilds tunnels roughly every 10 minutes), which is why real I2P deployments favor tunnel pool diversity (more parallel tunnels, unpredictable selection) and peer profiling to keep an adversary's effective router share low, rather than relying on hop count alone.
- Tunnel length — hops per tunnel; changes latency, not endpoint risk.
- Tunnel pool size — parallel tunnel pairs shown at once; wider pools spread traffic across more independently-drawn endpoints.
- Adversary router share (f) — fraction of the network run by a colluding attacker; drives p = f².
- Build New Tunnel Pool — draws a fresh random path per tunnel and updates the cumulative risk curve.