# Estrutura de blocos *** > “Os mineradores constroem blocos, mas os nós decidem quais blocos seguir.”\ > — *Princípio fundamental do Bitcoin* *** ## 1. Introdução Bitcoin é uma rede distribuída cujo funcionamento depende de duas estruturas centrais: 1. **blocos** 2. **transações** Ambas estão encadeadas criptograficamente por meio de **árvores de Merkle** e protegidas por **Prova de Trabalho (PoW)**.\ Compreender seu desenho é essencial para entender: * como a informação é organizada * como funcionam os incentivos * como a imutabilidade é garantida * como se alcança consenso sem autoridade central *** ## 2. A cadeia de blocos: estrutura geral Um bloco de Bitcoin é composto por duas partes principais: ┌────────────────────┐\ │ Cabeçalho (80B) │ ← Hash do bloco \ └────────────────────┘\ ┌────────────────────┐\ │ Corpo: transações │ \ └────────────────────┘ *** ### 2.1. Campos do cabeçalho O cabeçalho do bloco tem exatamente **80 bytes**, estruturados assim: | Campo | Tamanho | Descrição | | ----------------- | -------- | ---------------------------- | | version | 4 bytes | Sinaliza regras de validação | | prev\_block\_hash | 32 bytes | Hash do bloco anterior | | merkle\_root | 32 bytes | Raiz da árvore de Merkle | | timestamp | 4 bytes | Hora aproximada | | bits | 4 bytes | Alvo de dificuldade | | nonce | 4 bytes | Contador para PoW | Hash final do bloco: $$\text{hash\_bloque} = SHA256(SHA256(\text{header}))$$ *** ## 3. Corpo do bloco: transações Um bloco contém: * 1 **transação coinbase** (a primeira) * N transações normais Representação conceitual: Block \ ├─ Coinbase TX \ ├─ TX1 \ ├─ TX2\ ├─ ... \ └─ TXn O limite atual é um peso máximo de: $$\text{4,000,000 unidades de weight}$$ após a ativação do `SegWit (BIP141)`. *** ## 4. Árvores de Merkle no Bitcoin As árvores de Merkle permitem: * demonstrar inclusão de transações * reduzir a quantidade de informação necessária para clientes SPV * proteger contra modificações ### 4.1. Construção passo a passo 1. Tirar o hash de cada transação:\ $$h\_i = SHA256d(tx\_i)$$ 2. Agrupar pares e hasheá-los novamente: $$H\_{i,j} = SHA256d(h\_i || h\_j)$$ 3. Repetir até chegar à raiz. *** ### 4.2. Representação ``` Merkle Root / \ Hash 0-3 Hash 4-7 / \ / \ Hash 0-1 Hash 2-3 Hash 4-5 Hash 6-7 / \ / \ / \ / \ TX0 TX1 TX2 TX3 TX4 TX5 TX6 TX7 ``` *** ### 4.3. Provas de inclusão (Merkle Proof) Um cliente SPV pode demonstrar que: $$tx\_j \in \text{bloque}$$ com uma prova de tamanho $$O(\log n)$$. *** ## 5. Transações Bitcoin: estrutura técnica Uma transação consiste em: * **inputs** (entradas) * **outputs** (saídas) Os **inputs** consomem UTXOs anteriores.\ Os **outputs** geram novos UTXOs. *** ### 5.1. Formato geral Transaction \ ├─ Version (4 bytes) \ ├─ TX\_IN\_COUNT \ ├─ \[Inputs] \ ├─ TX\_OUT\_COUNT \ ├─ \[Outputs] \ └─ locktime *** ### 5.2. UTXO: o modelo contábil do Bitcoin O Bitcoin não usa contas.\ Usa um conjunto global de outputs não gastos (*Unspent Transaction Outputs*). Vantagens: * paralelização * facilidade de verificabilidade * proteção contra gasto duplo * simplicidade na validação Formalização: $$UTXO\_{new} = UTXO\_{old} - inputs + outputs$$ *** ## 6. Inputs: consumindo transações anteriores Um input contém: | Campo | Descrição | | ----------- | --------------------------------- | | prev\_txid | hash da transação anterior | | prev\_index | índice do output consumido | | scriptSig | assinatura + dados de desbloqueio | | sequence | usado no locktime | O input prova que o usuário possui a chave privada associada ao UTXO. *** ### 6.1. scriptSig (clássico) Exemplo: ` ` Com `SegWit`, a assinatura vai em um campo diferente (*witness*). *** ## 7. Outputs: criando novos UTXOs Um output contém: | Campo | Descrição | | ------------ | ---------------------- | | value | quantidade em satoshis | | scriptPubKey | condições de gasto | *** ### 7.1. scriptPubKey mais comum (P2PKH) `OP_DUP OP_HASH160 OP_EQUALVERIFY OP_CHECKSIG` *** ### 7.2. P2SH Tipo introduzido pelo BIP16: `OP_HASH160 OP_EQUAL` *** ### 7.3. P2WPKH (SegWit) Formato witness: `0 <20-byte-key-hash>` Benefícios: * menor peso da assinatura * elimina maleabilidade * reduz taxas *** ## 8. Assinaturas em transações O Bitcoin usa `ECDSA` sobre a curva `secp256k1`. Para assinar uma transação constrói-se uma mensagem: $$m = \text{serialización modificada}(\text{TX})$$ Depois: $$firma = ECDSA\_sign(privkey, m)$$ *** ### 8.1. Tipos de Sighash O Bitcoin permite diferentes modos de assinar: | Código | Efeito | | --------------- | ----------------------------- | | SIGHASH\_ALL | Assina inputs e outputs | | SIGHASH\_NONE | Assina inputs, outputs livres | | SIGHASH\_SINGLE | Assina o input correspondente | | ANYONECANPAY | Modifica os inputs permitidos | *** ## 9. A transação coinbase É a primeira transação em cada bloco. ### 9.1. Características: * não tem inputs válidos * cria novos bitcoins * inclui recompensa (subsídio + taxas) * contém um **script arbitrário** com mensagens opcionais Exemplo clássico: a mensagem do bloco gênesis. *** ### 9.2. Subsídio $$\text{Subsidio actual} = 50 \cdot 2^{-n}$$ onde * $$n$$ = número de halvings transcorridos *** ## 10. Como as transações são verificadas Um nó verifica: 1. **Formato correto** 2. **Assinaturas válidas** 3. **Existência dos UTXOs** 4. **Não haver gasto duplo** 5. **Outputs não excederem inputs** 6. **Sighash válido** 7. **Script executado sem erro** *** ### 10.1. Avaliação de scripts Bitcoin Script é uma linguagem simples, não Turing completa. Exemplo de avaliação `P2PKH`: scriptSig: ` `\ scriptPub: `OP_DUP OP_HASH160 OP_EQUALVERIFY OP_CHECKSIG` *** ## 11. Validação de blocos Para aceitar um bloco: 1. Hash do bloco < Target 2. Todas as transações válidas 3. Tamanho correto 4. Recompensa correta 5. Prev\_block\_hash coincide 6. O Merkle Root coincide 7. Timestamp razoável *** ## 12. Representação matemática do encadeamento Se: * $$B\_i$$ = Bloco i * $$H(B\_i)$$ = Hash do cabeçalho do bloco i então: $$\text{prev\_hash}(B\_i) = H(B\_{i-1})$$ que produz: $$B\_0 \rightarrow B\_1 \rightarrow B\_2 \rightarrow \dots$$ A segurança depende de: $$\text{Costo de reorganización} \approx \text{PoW acumulado}$$ *** ## 13. Conclusão do capítulo Neste capítulo vimos: * como um bloco está estruturado * como as transações são organizadas e verificadas * que papel a árvore de Merkle desempenha * como a integridade da cadeia é assegurada * por que o sistema UTXO é superior a um modelo baseado em contas Todos esses elementos são a base da camada fundamental do Bitcoin. *** > Se você entende um bloco, entende o Bitcoin.\ > Se você entende a árvore de Merkle, entende por que é imutável. *** --- # Agent Instructions: 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: ``` GET https://www.notbank.com/learn/academy/pt-br/bitcoin/estrutura-de-blocos.md?ask= ``` The question should be specific, self-contained, and written in natural language. 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.