# Peer-to-peer, do Napster ao enxame: as arquiteturas que sobreviveram à pirataria

> Napster, Gnutella, Kazaa, eMule, BitTorrent - quatro anos de compartilhamento de arquivos produziram cinco arquiteturas de rede distintas, cada uma resolvendo a fraqueza de que a anterior morreu. O índice centralizado, a inundação não estruturada, o supernó, a tabela hash distribuída e o enxame - o que cada um de fato era, como o tribunal moldou a topologia, e por que essas ideias hoje movem silenciosamente o Skype, os CDNs de streaming e as blockchains.

Source: https://ronutz.com/pt-BR/learn/peer-to-peer-evolution  
Updated: 2026-07-23

---

## Um problema, cinco respostas

O compartilhamento de arquivos peer-to-peer se propôs a resolver um único problema: deixar uma multidão de computadores comuns encontrar e trocar arquivos entre si, sem nenhuma empresa dona da biblioteca. Entre 1999 e 2003 esse problema foi respondido de cinco maneiras diferentes, e a razão de haver cinco é que cada projeto morreu de uma fraqueza específica que o seguinte foi construído para corrigir. Lida em ordem, a história não é uma lista de aplicativos, e sim uma aula limpa sobre os compromissos dos sistemas distribuídos - e a faísca que habilitou tudo isso foi um codec. O MP3 (MPEG-1 Audio Layer III, do Instituto Fraunhofer, padronizado em 1993) encolheu uma música de dezenas de megabytes de áudio de CD para três ou quatro, pequena o bastante para trafegar por uma linha discada, e ao fazê-lo desprendeu a música do disco físico. Tudo o que se segue é o que aconteceu quando o arquivo ficou sem peso.

## O índice centralizado: Napster (1999)

A sacada do Napster foi separar as duas tarefas que um sistema de compartilhamento precisa fazer: **encontrar** um arquivo e **transferi-lo**. A transferência era genuinamente peer-to-peer - sua máquina baixava direto da máquina de outro usuário. Mas o **encontrar** passava por um servidor central que guardava o índice de quem tinha o quê. Esse híbrido é a razão de o Napster ter sido ao mesmo tempo explosivamente rápido de crescer (26 milhões de usuários no início de 2001) e trivialmente fácil de matar: o índice era uma única empresa num único endereço. Quando a indústria fonográfica venceu o processo *A&M Records v. Napster* em 2001, havia uma só tomada a puxar, e puxá-la encerrou a rede. A arquitetura carregava sua própria certidão de óbito.

## Descentralização pura: Gnutella e LimeWire (2000)

A resposta do Gnutella foi apagar o servidor por completo. Não havia índice central - para buscar, seu cliente perguntava aos vizinhos, que perguntavam aos vizinhos deles, e a consulta **inundava** para fora salto a salto. Nada ficava num único endereço, então nada podia ser processado até o silêncio, e o LimeWire e seus semelhantes cavalgaram essa rede por anos. O custo era aritmético: inundar cada consulta a cada vizinho gera um tráfego que cresce mais rápido que os resultados úteis, então o Gnutella puro escalava mal e desabava sob a própria tagarelice. A correção da própria rede antecipou a ideia seguinte - ela criou uma estrutura de duas camadas de **ultrapeers**, nós estáveis e bem conectados que blindavam os peers "folha" comuns da inundação, cortando drasticamente o custo das consultas. A descentralização havia aprendido que precisava de alguma hierarquia de volta.

## O compromisso do supernó: FastTrack e Kazaa (2001)

O Kazaa, construído sobre o protocolo proprietário **FastTrack**, fez dessa hierarquia o centro do projeto. O FastTrack promovia usuários bem conectados a **supernós** - sua máquina comum se conectava a um supernó, que indexava os arquivos das dezenas de nós folha ao seu redor e conversava com outros supernós para responder buscas. Era o índice do Napster estilhaçado em milhares de pedaços e empurrado para dentro da multidão, que é exatamente por que não havia um único servidor a desligar. O Kazaa acrescentou um segundo truque que apontava direto para o futuro: o **download de múltiplas fontes**, puxando trechos diferentes do mesmo arquivo de vários peers ao mesmo tempo. Também carregava o pecado original da época - spyware e adware embutidos - que fez tanto quanto qualquer processo para matar a confiança do usuário comum. Os autores do FastTrack eram engenheiros estonianos, entre eles Jaan Tallinn, trabalhando com Niklas Zennstrom e Janus Friis; as mesmas pessoas pegaram a ideia do supernó quase intacta e construíram o **Skype** sobre ela em 2003. A arquitetura sobreviveu à pirataria por dois anos e um modelo de negócio.

## A virada estruturada: eDonkey, eMule e a DHT

A rede eDonkey começou com servidores de índice, mas seu cliente de código aberto **eMule** popularizou o salto que tornou dispensável qualquer coisa central: a **tabela hash distribuída**. Uma DHT transforma "quem tem este arquivo?" de uma pergunta em broadcast numa consulta. Todo arquivo tem um hash, todo peer tem um ID no mesmo espaço de endereços, e um algoritmo de roteamento por chave - a rede **Kad** do eMule usa **Kademlia** (2002), cuja elegante métrica de distância XOR localiza qualquer chave num número logarítmico de saltos - significa que a localização de um arquivo é *calculada*, não buscada. Não há servidor a apreender nem inundação em que se afogar, apenas uma agenda de endereços auto-organizada espalhada por cada participante. Essa foi a mudança arquitetural mais profunda de toda a história: das redes **não estruturadas**, que acham coisas perguntando por aí, para as redes **estruturadas**, que acham coisas por aritmética. O eMule a combinou com um sistema de filas que recompensava a paciência, o que o tornou a ferramenta preferida para arquivos grandes e raros que as redes mais rápidas nunca mantinham vivos.

## O enxame: BitTorrent (2001)

O BitTorrent, de Bram Cohen, fez mais uma separação e mudou tudo. Ele deixou de tratar um arquivo como algo que se baixa de uma fonte e passou a tratá-lo como um conjunto de **pedaços** que se montam a partir de um **enxame**. Todo mundo baixando o mesmo arquivo também está enviando os pedaços que já tem, então arquivos populares ficam *mais rápidos* conforme mais gente os quer - o inverso exato da curva cliente-servidor, onde popularidade é congestionamento. A genialidade está no incentivo: o algoritmo de estrangulamento **tit-for-tat** (olho por olho) do BitTorrent envia preferencialmente a peers que enviam de volta, o que resolve discretamente o problema do carona que deixava as redes anteriores apodrecerem em sugadores. O BitTorrent também separou de forma limpa as duas tarefas que o Napster fundira. Encontrar peers foi primeiro um **tracker** (um pequeno servidor de coordenação), depois uma **DHT** (a Mainline DHT, Kademlia de novo) que tornou os trackers opcionais, depois os **magnet links** que substituíram o arquivo .torrent por nada além de um hash. Transferir era o enxame. Mate qualquer uma das partes e as outras seguem, e é por isso que o BitTorrent, sozinho entre estes, nunca de fato foi embora.

## O tribunal como restrição de projeto

É tentador ler isto como pura engenharia, mas a lei moldou a topologia tão diretamente quanto a banda. *A&M v. Napster* (2001) estabeleceu que um índice central significava responsabilidade contributiva e indireta - então os projetos seguintes removeram o centro. Quando a indústria perseguiu as redes de supernós, o *MGM Studios v. Grokster* (2005) da Suprema Corte dos EUA forneceu uma nova teoria: a regra da **indução** sustentou que promover uma ferramenta para violação criava responsabilidade independentemente da arquitetura da ferramenta, o que encerrou a vida americana do FastTrack e empurrou os donos do Kazaa a um acordo de nove dígitos em 2006. O julgamento do **Pirate Bay** na Suécia (2009) mandou seus operadores para a prisão e virou o drama de tribunal definidor do movimento. O padrão é inconfundível: cada derrota jurídica selecionava um sucessor mais descentralizado, até que o *Grokster* estabeleceu que a descentralização sozinha não era escudo se você anunciasse a intenção. A arquitetura podia escapar de uma intimação; não podia escapar de um júri decidindo o que você quis construir.

## Por que ele "morreu" - e as quatro forças que o mataram

No fim dos anos 2000 as redes abertas de compartilhamento definharam, e não principalmente por causa de um único processo. Quatro forças convergiram. A **pressão jurídica** elevou o custo e o medo para operadores e usuários igualmente. A **higiene** desmoronou a experiência por dentro: as redes se encheram de vírus, spyware e arquivos falsos deliberados (muitas vezes semeados pela própria indústria) até achar uma cópia limpa virar trabalho. A **banda larga** substituiu a discada, tornando o streaming em tempo real viável, de modo que você já não precisava sequer possuir o arquivo. E a **conveniência** encerrou o caso: o mercado descobriu que as pessoas pagariam de bom grado pelo acesso se o serviço legal fosse mais rápido, mais seguro e mais bem organizado que a pirataria. O YouTube e os lockers de download direto chegaram por volta de 2005; o Spotify e a Netflix tornaram o streaming o padrão até o fim da década, entregando tudo a partir de nuvens centralizadas e **redes de distribuição de conteúdo** - um retorno, na prática, a um modelo cliente-servidor muito sofisticado.

## Ele não morreu de verdade

Os aplicativos morreram; as arquiteturas estão em toda parte. O Skype era o projeto de supernó do FastTrack de fones de ouvido. O **IPFS** é uma DHT endereçada por conteúdo para a web inteira, usando a mesma linhagem Kademlia do eMule e do BitTorrent. Redes blockchain fofocam transações peer-to-peer sobre overlays não estruturados que seriam familiares a qualquer engenheiro do Gnutella. O **WebRTC** põe conexões peer entre navegadores em toda chamada de vídeo. Até os CDNs, a resposta centralizadora da era do streaming, experimentam discretamente a entrega assistida por peers para aliviar a própria banda. As guerras do compartilhamento foram, em retrospecto, um laboratório público de quatro anos para sistemas distribuídos, e os vencedores foram as ideias, não os produtos.

Um ramo da árvore genealógica das redes descentralizadas fica deliberadamente à parte de tudo isso, porque otimiza uma coisa inteiramente diferente - não a distribuição, mas o **anonimato**. O **Tor**, o roteador cebola, é um overlay descentralizado como estes, mas existe para esconder *quem* está falando em vez de espalhar *o que* é compartilhado, e seu projeto de criptografia em camadas merece um texto dedicado só seu, em vez de um parágrafo aqui. Esse artigo está a caminho.