Persistent BitTorrent Trackers: A Research Perspective on Portable Reputation

November 26, 2025
5 min read
Persistent BitTorrent Trackers: A Research Perspective on Portable Reputation

Private BitTorrent trackers are a long-running attempt to enforce cooperation in an otherwise open P2P protocol. By maintaining upload/download ratios and gating access, they create a crude but effective incentive mechanism for seeding.

From a systems and security perspective, however, today’s trackers have three fundamental weaknesses (as also summarized by IC3):

  1. Reputation is siloed and non-portable across trackers.
  2. Trackers rely on centralized, failure-prone and censorable infrastructure.
  3. Upload statistics are self-reported and thus easy to manipulate.

Our paper, Persistent BitTorrent Trackers, revisits this design space and proposes a new architecture that uses cryptography, trusted execution environments (TEEs), and smart contracts to construct portable, verifiable reputation for BitTorrent-like systems. Two of the authors, Shunfan Zhou and Hang Yin, are affiliated with Phala .

This post summarizes the core ideas from a researcher’s point of view: the problem formulation, the design, and how this fits into the broader line of work on verifiable off-chain behavior.


Problem setting and design goals

We start from the standard private tracker model:

  • Peers exchange data using BitTorrent or a similar P2P protocol.
  • A tracker maintains per-user statistics (uploaded, downloaded) and derives ratios or reputation scores.
  • Access to content or communities is conditioned on maintaining sufficient ratio.

In this model, we consider three key goals:

  1. Portability of reputation

    Reputation should not be bound to a single tracker’s database. If a tracker disappears or a user joins a new tracker, their past seeding history should remain meaningful and recoverable.

  2. Robustness to operator failure and censorship

    The system should not rely on a single trusted operator or centralized server. Tracker functionality should survive churn, failures, and realistic adversarial pressure.

  3. Verifiability of accounting

    Upload statistics should be grounded in cryptographic evidence rather than untrusted self-reporting from clients. Ideally, “I uploaded X to Y” must be backed by proofs that Y actually received X.

We also impose practical constraints: the solution should be compatible with existing P2P protocols at the conceptual level, and it should not require fully homomorphic encryption or heavy MPC for every transfer.


High-level approach

Our design combines three components:

  • Signed download receipts issued by receivers.
  • A TEE-based tracker enclave that aggregates and verifies these receipts.
  • A smart contract that stores and updates global, portable reputation.

The resulting system separates concerns cleanly:

  • Peers handle data exchange and receipt generation.
  • The TEE tracker provides integrity for aggregation logic and state transitions.
  • The blockchain provides a shared, long-lived, and auditable reputation registry.

Cryptographic receipts: turning traffic into claims

The first abstraction is the notion of a receipt.

When peer B downloads data from peer A, B periodically issues a signed receipt of the form:

“I, B, confirm receiving X bytes from A in context C.”

Receipts are bound to cryptographic identities (public keys). They can be batched or rate-limited, but conceptually they encode: “this amount of traffic actually flowed.”

Key properties:

  • Non-repudiation: B cannot later deny that it acknowledged receiving X from A.
  • Attribution: Receipts identify both parties and the volume of data.
  • Composability: Collections of receipts can be aggregated into higher-level statistics.

Crucially, this reverses the trust direction: instead of A claiming to have uploaded to B, B is the one attesting to what it received.


TEEs as verifiable aggregators

Collecting and verifying receipts at scale raises a trust problem: who aggregates them?

Naively, a centralized server could ingest receipts and maintain per-peer counters, but then we reintroduce the same assumptions that private trackers already suffer from: trust in a single operator’s honesty and correctness.

We use a trusted execution environment (e.g., Intel TDX) to run the tracker logic inside an enclave. The TEE provides:

  • Code integrity: The tracker code that processes receipts is fixed and attested.
  • State confidentiality and integrity: The internal state (e.g., intermediate counters, pending updates) is protected from the host OS and operator.
  • Remote attestation: External parties can verify that they are interacting with an enclave running the expected code.

Within the enclave, the tracker:

  1. Verifies signatures on receipts.
  2. Checks protocol rules (e.g., no double-counting, rate limits, identity checks).
  3. Maintains a local view of per-peer reputation.
  4. Periodically generates authenticated updates destined for the blockchain contract.

The TEE does not eliminate all trust (e.g., we inherit the TEE’s hardware assumptions), but it significantly narrows the trusted computing base compared to a conventional server.


Smart contracts for persistent reputation

The final component is an on-chain reputation registry.

A smart contract stores for each peer identity a reputation measure derived from verified receipts (e.g., net uploaded bytes, time-weighted upload, or more sophisticated scoring functions).

The TEE enclave periodically submits aggregated updates to this contract, accompanied by evidence that they originate from an attested tracker. Depending on the concrete protocol, this can be done via:

  • Signature schemes tied to the enclave’s attestation key.
  • Aggregated proofs that a given batch of updates is consistent with valid receipts.

Once updates are accepted, the contract’s state becomes the canonical source of truth for reputation. This immediately yields:

  • Portability: Any tracker or application can query the same on-chain state. Users do not lose their reputation when individual trackers disappear.
  • Auditability: Reputation logic is transparent; the contract’s update rules are visible and verifiable.
  • Composability: Other systems (e.g., token incentives, access control mechanisms) can build on top of the same reputation.

In effect, we move from “each tracker keeps its own private database” to “there is a shared, publicly verifiable ledger of contributions,” with the TEE acting as a bridge between noisy off-chain behavior and on-chain state.


Security and robustness considerations

From a research viewpoint, several questions arise naturally.

  1. Sybil resistance

    Cryptographic receipts alone do not prevent Sybil attacks: an adversary controlling many identities could generate fake traffic among them. Mitigating this requires additional mechanisms (e.g., identity costs, rate limits, or cross-layer checks). Our design focuses on verifiable accounting; Sybil resistance is an orthogonal and complementary problem.

  2. Collusion between peers

    Two colluding peers could fake receipts without actual data transfer. Countermeasures may include random audits, bandwidth proofs, or integration with network-level measurements. We discuss the threat model and acknowledge that preventing all forms of collusion remains an open challenge.

  3. TEE assumptions and attacks

    Our approach inherits the standard TEE threat model: correctness and confidentiality rely on the hardware and its implementation. Side-channel attacks and future vulnerabilities are relevant concerns. The system is designed so that compromise of a given TEE does not retroactively forge past receipts, but it can affect aggregation until detected or rotated.

  4. Availability and decentralized deployment

    Although we move reputation to a blockchain, the tracker functionality itself still needs to be available. Multiple enclaves, possibly run by different operators, can redundantly process receipts and submit updates, reducing reliance on any single entity.

These aspects define a rich space for future work: more robust reputation functions, redundancy among enclaves, and tighter integration with Sybil-resistant identity systems.


Relation to broader research directions

The design of persistent BitTorrent trackers sits at the intersection of several trends:

  • Verifiable off-chain behavior: Using hardware attestation and cryptographic proofs to tie real-world actions (here: bandwidth provision) to on-chain state.
  • Decentralized reputation systems: Moving from platform-specific, siloed scores to shared, portable reputation primitives.
  • TEE-assisted protocols: Leveraging enclaves as efficient alternatives to fully cryptographic constructions for many coordination and accounting tasks.

In that sense, BitTorrent is a concrete and familiar testbed, but the pattern is broader: any system where “service provision” must be measured and rewarded can potentially adopt similar building blocks.


Conclusion

Persistent BitTorrent Trackers revisits a mature but fragile ecosystem with modern tools. By combining:

  • receiver-signed download receipts,
  • TEE-based aggregation, and
  • on-chain reputation,

we obtain a design where contribution is both portable across communities and grounded in cryptographic evidence, rather than fragile self-reporting.

Two of the co-authors, Shunfan Zhou and Hang Yin, are members of the Phala team, reflecting our broader interest in trustworthy off-chain compute and decentralized infrastructure.

For researchers interested in P2P incentives, TEEs, or reputation systems, the full paper provides a more formal treatment of the protocol, assumptions, and security properties:

Persistent BitTorrent Trackers — [https://eprint.iacr.org/2025/2131.pdf]

Recent Posts

Related Posts