> For the complete documentation index, see [llms.txt](https://www.notbank.com/learn/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://www.notbank.com/learn/academy/pt-br/bitcoin/redes-p2p.md).

# Redes P2P

***

> “Os mineradores constroem blocos; os nós decidem o consenso.”\
> — Parafraseando *Gregory Maxwell*

***

## 1. Introdução

A rede P2P do Bitcoin é a espinha dorsal do sistema.\
Sem ela:

* não haveria consenso
* não haveria propagação de transações
* não haveria mineração coordenada
* não haveria blockchain distribuída

Este capítulo explora:

* Topologia da rede
* Funcionamento de nós completos
* Mensagens do protocolo P2P
* Validação e sincronização
* Relay de blocos e transações
* Proteção contra ataques
* Estrutura de gossip
* Papel sociopolítico do nó soberano

***

## 2. Filosofia de design da rede Bitcoin

Bitcoin é uma rede:

* **descentralizada** (sem servidor central),
* **não permissiva** (qualquer um pode se conectar),
* **pseudônima** (sem identidade obrigatória),
* **robusta** (falhas parciais não afetam o todo),
* **tolerante a alta latência**,
* **sem líderes**,
* baseada em mensagens no estilo *gossip*.

Não é como uma rede corporativa, é mais parecida com **uma colônia de formigas onde cada nó tem pouca informação, mas o sistema global emerge do conjunto.**

***

## 3. Tipos de nós na rede

### 3.1. Nós completos (full nodes)

Estes nós:

* baixam toda a blockchain
* verificam todas as regras de consenso
* rejeitam blocos inválidos
* mantêm o mempool
* retransmitem transações e blocos

São a **força soberana do consenso**.

***

### 3.2. Nós leves (SPV)

Verificação Simplificada de Pagamentos (SPV):

* não verificam regras
* apenas baixam cabeçalhos
* confiam em nós completos

Utilizam **Provas de Merkle** para demonstrar que uma transação está incluída em um bloco.

***

### 3.3. Nós mineradores

São nós completos + hardware especializado (ASICs).\
Usam:

* modelos de bloco (`getblocktemplate`)
* dados do mempool
* sincronização rápida

***

### 3.4. Nós arquivistas

Mantêm todos os estados históricos sem podar.\
São opcionais.

***

## 4. Topologia da rede

O Bitcoin adota uma topologia **mesh não estruturada,** onde cada nó normalmente mantém:

* 8 conexões de saída
* até centenas de entradas (dependendo da configuração)

A rede permanece conectada mesmo diante de perda massiva de nós.

***

## 5. Protocolo P2P: mensageria e estrutura

### 5.1. Mensagens principais

| Mensagem    | Função                       |
| ----------- | ---------------------------- |
| `version`   | Inicia conexão               |
| `verack`    | Confirma versão              |
| `inv`       | Anuncia dados (blocos ou TX) |
| `getdata`   | Solicita dados               |
| `tx`        | Envio de transação           |
| `block`     | Envio de bloco               |
| `getblocks` | Sincronização                |
| `ping/pong` | Verificação de vida          |
| `addr`      | Propagação de nós            |

***

## 6. Propagação de transações

Quando um nó recebe uma transação válida:

1. Ele a verifica completamente.
2. Ele a adiciona ao mempool.
3. Envia uma mensagem `inv` aos seus vizinhos.
4. Eles solicitam a transação se não a tiverem.

Isto é chamado de **protocolo gossip**: difusão redundante.

***

## 7. Propagação de blocos

Os blocos circulam mais rápido que as transações.

Processo:

1. Minerador encontra PoW válido.
2. Envia `inv` aos vizinhos.
3. Eles solicitam o bloco.
4. Verificam cabeçalho, transações e PoW.
5. Difundem por sua vez.

***

### 7.1. Métodos de relay

#### 1. **Relay de bloco padrão**

Envia bloco completo.

#### 2. **Compact Blocks (BIP152)**

Reduz a largura de banda → 90% mais eficiente.

#### 3. **Relay por cabeçalho primeiro**

Envia primeiro o cabeçalho → permite validação preliminar.

***

## 8. Validação de transações e blocos

Os nós completos verificam *tudo*.

***

### 8.1. Validação de transações

Verificam:

* assinaturas
* scripts
* formato
* valores
* ausência de gasto duplo
* existência de UTXOs
* limites de tamanho
* estruturas witness
* sighash correto
* locktime válido

***

### 8.2. Validação de blocos

Verificam:

* PoW
* tamanho
* merkle root
* recompensas
* coinbase válida
* timestamp razoável
* cabeçalho correto
* encadeamento
* todas as transações

***

## 9. Sincronização da blockchain

Processo conhecido como **Initial Block Download (IBD)**.

Passos:

1. Baixar todas as cabeçalhos.
2. Verificar PoW de cada uma.
3. Baixar blocos completos.
4. Verificar transações.
5. Construir o conjunto UTXO.

UTXO final ≈ 4–10 GB\
Blockchain ≈ 500+ GB (dependendo do ano).

***

## 10. Mempool: memória de transações pendentes

Cada nó mantém seu próprio mempool:

* não é global
* não está sincronizado
* cada um aceita/rejeita segundo suas regras
* aplica políticas de taxas
* descarta spam

É um sistema **permissivo**, não um consenso.

***

## 11. Proteção contra ataques P2P

O Bitcoin inclui numerosas defesas.

***

### 11.1. Anti-Sybil

* sem identidade
* PoW limita a utilidade de milhares de nós falsos
* conexões aleatórias
* slots limitados para entradas

***

### 11.2. Anti-DDoS

* limites de taxa
* desconexões automáticas
* punição de pares maliciosos
* banimento temporário
* topologia dispersa

***

### 11.3. Anti-eclipse

* múltiplas conexões
* fontes diversas
* reconexão periódica
* DNS seeds diversos
* rotação de endereços

***

## 12. Teoria dos jogos aplicada a nós

Nós não recebem recompensa financeira.\
Mas recebem **segurança soberana**:

* controle sobre suas regras
* proteção contra inflação
* validação independente
* não depender de terceiros

O incentivo é:

> “Eu verifico minhas próprias moedas → garanto seu valor.”

***

## 13. Soberania e nós completos

Um nó completo é:

* uma ferramenta de autodefesa financeira
* um mecanismo de verificação independente
* um muro contra a inflação
* um regulador do consenso
* um “voto” técnico, não político

Os nós:

* validam
* rejeitam
* protegem
* sincronizam
* conservam a história

***

## 14. Matemática da propagação

O tempo médio de propagação:

<p align="center"><span class="math">T_{prop} \approx \log(N)</span></p>

N = número de nós (\~15k públicos + privados desconhecidos)

Isso permite:

* consenso rápido
* baixa latência
* mínima dessincronização

***

## 15. Proposta de bloco “órfão”

Se dois mineiros encontrarem blocos ao mesmo tempo:

* ambos se propagam
* cada nó temporariamente escolhe um
* eventualmente um é descartado (bloco órfão)

PoW acumulado resolve a corrida.

***

## 16. Futuro do protocolo P2P

Melhorias em desenvolvimento:

* Erlay (relay mais eficiente)
* Forward Block Relay
* BIP324 (criptografia de conexões P2P)
* BlockTorrent (proposto)

***

## 17. Conclusão do capítulo

A rede P2P do Bitcoin é:

* descentralizada
* resistente a ataques
* eficiente
* flexível
* autoorganizadora
* soberana
* verificável
* robusta contra censura

Os nós completos são a **espinha dorsal do consenso**, mais importantes que os mineradores.\
**Sem nós, não há regras.**\
**Sem regras, não há Bitcoin.**

No próximo capítulo entraremos em **a economia do sistema**, analisando teoria monetária avançada aplicada ao Bitcoin.

***

> Executar um nó completo é como possuir um firewall monetário que defende suas economias.

***


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://www.notbank.com/learn/academy/pt-br/bitcoin/redes-p2p.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
