o problema
Nos quinze anos anteriores a este paper, duas linhagens de sistema de arquivos distribuído deram certo por motivos opostos. A acadêmica produziu coisas como o AFS, que continua em uso, e coisas como o OceanStore, que não pegaram. A comercial produziu Napster, KaZaA e BitTorrent, que juntaram mais de 100 milhões de usuários simultâneos e distribuíram mais dados que qualquer sistema de pesquisa — mas nenhum deles foi desenhado como infraestrutura para outra coisa ser construída em cima. Dá para distribuir uma imagem de disco com BitTorrent; não dá para montar um diretório nele.
Enquanto isso, o sistema de arquivos distribuído que realmente venceu foi o HTTP, e ele endereça por localização: o nome do dado é o servidor que tem o dado. Isso funcionou porque mover arquivo pequeno é barato. Deixa de funcionar quando o problema é hospedar dataset de petabytes, versionar dado grande entre organizações, servir vídeo sob demanda em volume, ou simplesmente garantir que um arquivo importante não suma quando o host morre. Já se abandonou o HTTP para esses casos, com protocolos paralelos. Falta transformá-los em Web. Em paralelo, o Git resolveu a parte de versionar e distribuir mudanças com um Merkle DAG de objetos imutáveis endereçados por hash — só que voltado a código, não a throughput.
a ideia
O IPFS modela tudo como parte do mesmo Merkle DAG. A analogia do próprio autor: um único swarm de BitTorrent trocando objetos dentro de um só repositório Git. Nada é novo isoladamente — DHT vem do Kademlia, o mercado de blocos vem do BitTorrent, o modelo de objeto vem do Git, o namespace autocertificado vem do SFS. A contribuição declarada é o encaixe, mais o BitSwap.
O movimento central é separar dois planos. Objetos são imutáveis, endereçados pelo hash do conteúdo, verificáveis por quem recebe, dedupados por construção e cacheáveis para sempre. Sobre esse plano permanente entra uma camada fina de ponteiros mutáveis. É a mesma dicotomia do Git com objetos e refs, e do Plan 9 com Venti e Fossil.
como funciona
A pilha tem sete camadas. A identidade do nó é hash(hash(PubKey)), gerada por um crypto puzzle do S/Kademlia: você repete a geração de par de chaves até o NodeId ter zeros à esquerda suficientes, o que encarece Sybil. Ao conectar, os peers trocam chave pública e derrubam a conexão se o hash não bater com o NodeId anunciado.
Endereços de rede são multiaddr, strings autodescritivas que encapsulam protocolo (/ip4/10.20.30.40/sctp/1234/); hashes são multihash, com header dizendo qual função e que tamanho de digest. Nada fica preso a uma escolha de função.
O routing é uma DSHT que mistura S/Kademlia com Coral: busca em ⌈log₂(n)⌉ saltos, valores de até 1 KB armazenados direto, valores maiores representados por referências aos NodeIds que servem o bloco. A API é swappable — FindPeer, SetValue, GetValue, ProvideValue, FindValuePeers.
O BitSwap é o mercado. Cada nó anuncia want_list e have_list e mantém um Ledger por parceiro com bytes_sent e bytes_recv. A razão de dívida é r = bytes_sent / (bytes_recv + 1), e a probabilidade de atender um devedor é 1 − 1/(1 + exp(6 − 3r)): despenca quando a dívida passa do dobro do crédito estabelecido. Quem é recusado entra num ignore_cooldown de 10 segundos, para não conseguir rolar o dado várias vezes; conexão sem mensagem por 30 segundos fecha sozinha.
Acima disso, o objeto é só links []IPFSLink mais data []byte opaco. A tabela de links separada é o que permite ao IPFS listar referências, resolver foo/bar/baz andando pelo grafo e fazer GC recursivo sem entender o formato do payload. Sobre esse objeto vêm blob, list, tree e commit — quase Git, com tamanho agregado nos objetos e o tipo list para dedupe de arquivo grande. Não há raiz: todo caminho começa com /ipfs/<hash>, e pinning é o que promete que um objeto e seus descendentes sobrevivem localmente.
O IPNS fecha o buraco: /ipns/<NodeId> aponta para um objeto assinado, publicado como routing.setValue(NodeId, <hash>). Quem lê confere a assinatura contra a chave que gerou o NodeId.
o que isso custou
O paper não tem avaliação. É um draft — a seção de referências está marcada TODO no próprio texto —, não há benchmark, medição de latência nem experimento de rede. Tudo que se afirma sobre desempenho é argumento de projeto.
O custo mais óbvio é a resolução de caminho: cada componente de um path exige uma busca na DHT, conectar a peers e baixar blocos. O autor reconhece o overhead e propõe duas mitigações — cache agressivo de trees, que são pequenas, e flattened trees que listam tudo alcançável com nome composto por barras. Nenhuma das duas é medida.
O BitSwap admite mais buracos que fecha. A escolha de função de estratégia é declarada trabalho futuro; a sigmoide é apresentada como “uma escolha que funciona na prática”, sem dado. O ledger pode ser deliberadamente “perdido” por um nó malicioso para apagar dívida — a defesa é que ele também perde a confiança acumulada, e que o parceiro pode simplesmente recusar negociar. E o incentivo à replicação é fraco por construção: nada obriga terceiros a pinar o seu arquivo, então a Web Permanente depende de alguém se interessar.
Dividir arquivo em blocos não tem resposta: o paper oferece Rabin fingerprints, rolling checksum do rsync, ou uma função que o usuário escreva. Fica com o usuário. E o item mais desconfortável é a ponta amigável do IPNS: como hash não se decora, a saída proposta é TXT record no DNS, links entre peers no estilo web of trust, proquint e serviços de encurtamento — ou seja, a última milha volta a depender de nomes centralizados.
onde isso aparece hoje
O paper é explícito sobre a origem de cada peça, e vale ler as três junto com ele: o roteamento vem de Kademlia, o mercado de blocos vem de Incentives Build Robustness in BitTorrent, e a prioridade a blocos raros — que aqui vira o argumento para um nó buscar o que os peers querem — é o resultado de Rarest First and Choke Algorithms Are Enough.
O vocabulário pegou mais que o sistema. “Content addressing” como identificador de artefato, gateways HTTP servindo hash, e o hábito de tratar o hash como nome canônico saíram daqui para o uso corrente. O Merkle DAG generalizado também é a ponte que o paper desenha explicitamente para blockchains, que ele lista como uma das estruturas modeláveis sobre o mesmo objeto — a linhagem que passa por Bitcoin.
E a nota de rodapé mais consequente está na seção do BitSwap: a ideia de que a moeda virtual do mercado de blocos exigiria um livro-razão global e “será explorada num paper futuro”. Esse paper futuro virou o Filecoin.