Nakamoto Consensus é o nome dado à forma como o Bitcoin chega a um histórico válido e compartilhado sem um árbitro central. Um Full Node, um computador com software que verifica as regras, primeiro rejeita blocos inválidos. Entre os ramos válidos, escolhe então aquele com mais trabalho acumulado. Mais confirmações aumentam a confiança em um pagamento sob certas condições de segurança; não o tornam imediatamente irreversível.
Ana envia um pagamento a Pedro. Ela também poderia assinar outra transação que gastasse os mesmos recursos em favor de Eva. Assinar significa aqui usar uma chave privada, um valor numérico secreto, para criar uma prova verificável de autorização do pagamento. Outras pessoas podem conferir a assinatura sem conhecer esse segredo. As duas assinaturas poderiam ser autênticas, mas os dois pagamentos não cabem em um único histórico válido. Pedro e Eva poderiam até receber as mensagens em ordens diferentes. Por isso, o Bitcoin precisa de mais do que verificar assinaturas: precisa estabelecer uma ordem comum e impedir o gasto duplo. Nakamoto Consensus combina regras, Proof of Work, escolha de ramo e recompensas aos mineradores. O whitepaper de Satoshi, a descrição técnica original do Bitcoin, não usa esse nome posterior. [1] [4]
O Full Node de Pedro não é uma cédula de votação. Um bloco reúne transações em um lote acrescentado ao histórico compartilhado. Uma saída de transação registra um valor e as condições para gastá-lo depois. O software do Full Node verifica transações e blocos por conta própria: se as saídas a gastar ainda estão disponíveis, se suas condições de gasto foram satisfeitas e se a criação de bitcoins respeita o limite permitido. Um minerador pode propor um bloco, mas não contornar essas verificações à vontade. Um bloco inválido continua inválido mesmo com enorme trabalho por trás. Apenas ramos válidos são comparados; um histórico comum exige regras compatíveis entre os participantes. [2] [3]
Se cada computador conectado tivesse um voto, um atacante poderia criar muitos participantes aparentemente independentes. Isso é um Sybil Attack. Em vez de contar nomes, Proof of Work vincula o peso de um ramo a trabalho computacional verificável. Os mineradores calculam hashes, impressões digitais de dados, repetidamente até encontrar um resultado que cumpra uma condição. As tentativas exigem energia e equipamento, enquanto o resultado encontrado é fácil de conferir. Muitas identidades de rede não acrescentam trabalho por si sós. Não se trata de conferir documentos nem de uma votação de todos os nós. [1] [4]
O minerador monta um bloco candidato e altera seu cabeçalho, um resumo compacto do bloco, até que o hash interpretado como número seja menor ou igual ao alvo válido. Não está resolvendo uma equação útil nem quebrando criptografia: está buscando um resultado raro. Dois mineradores podem conseguir isso quase ao mesmo tempo. Parte da rede vê um bloco primeiro, e outra parte vê o concorrente; surgem brevemente dois ramos válidos. Isso não é, por si só, uma pane. Com propagação normal, o trabalho posterior permite que os nós convirjam para o ramo mais forte. [1] [8]
A força de um ramo é medida pelo chainwork, a soma do trabalho atribuído a cada bloco conforme seu alvo. Não é um medidor de eletricidade nem um registro das tentativas realmente feitas. Um minerador pode ter sorte logo no início e outro demorar; com o mesmo alvo, seus blocos válidos têm peso igual. Um Full Node escolhe o ramo válido disponível com a maior soma. Assim, “cadeia mais longa” significa mais trabalho, não necessariamente mais blocos. Mudar de ramo é uma reorganização; um pagamento de um bloco abandonado pode ser incluído novamente se continuar válido. [1] [2] [3] [7]
Quando o pagamento de Ana entra em um bloco aceito, tem uma confirmação. Cada bloco seguinte acrescenta outra. Para substituir esse histórico, um ramo concorrente teria de alcançar seu trabalho. Com maioria honesta da potência computacional e propagação suficientemente rápida, o risco de reescrita bem-sucedida geralmente cai com a profundidade. Isso é finalidade probabilística: confiança crescente, não impossibilidade matemática de mudança. O número de confirmações que Pedro espera também depende do valor e do risco do pagamento. Não existe um número universal que garanta segurança em todas as situações. [1] [4]
Se a condição continuasse igual quando chegassem máquinas mais rápidas, os blocos apareceriam mais depressa. Por isso, Difficulty Adjustment recalcula o alvo da rede principal a cada 2016 blocos usando registros de tempo anteriores. A meta é uma média de dez minutos por bloco, aproximadamente duas semanas para esse trecho. Um bloco individual pode chegar muito antes ou depois. O ajuste depende da contagem de blocos, não de uma data: se muita potência desaparecer de repente, chegar ao próximo ajuste pode demorar mais. Não é um regulador instantâneo nem um relógio exato. [2] [8]
Os bitcoins recém-emitidos, o subsídio de bloco, e as taxas de transação remuneram mineradores por blocos que permanecem no histórico aceito. Isso incentiva sua extensão, mas não substitui as condições de segurança. Uma maioria da potência pode reorganizar ramos válidos, omitir pagamentos e tentar reverter seus próprios gastos. Não pode forçar um Full Node a aceitar uma assinatura inválida, emissão excessiva ou gastos alheios sem autorização. O limite de 50% tampouco é um interruptor de segurança: alguns ataques têm chance abaixo dele. Recompensas, sozinhas, não produzem honestidade. [1] [2] [3]
Voltemos a Pedro. Se um atacante controlar todas as conexões do seu nó, poderá mostrar uma visão incompleta dos acontecimentos. Um Eclipse Attack é justamente esse isolamento de rede; as confirmações podem então ter significado diferente daquele que têm com boa conexão ao restante da rede. Dividir a rede em partes desconectadas também dificulta o acordo. A segurança depende da potência adversária, da circulação das mensagens e da verificação honesta. A pesquisa Bitcoin Backbone modela expressamente essas condições. Um percentual de potência sem condições de rede não explica toda a segurança. [4]
Métodos BFT (Byzantine Fault Tolerance) clássicos buscam acordo mesmo com participantes defeituosos ou maliciosos e muitas vezes partem de um grupo conhecido. Exemplos como OM (Oral Messages) e PBFT (Practical Byzantine Fault Tolerance) têm suas próprias condições e regras de troca de mensagens. O Bitcoin lida com participação aberta por meio de trabalho e estabilização probabilística do histórico; não é apenas outro nome para esses métodos. Escolher um ramo válido mais forte também não altera as regras de validade. Mudar regras exige que os participantes adotem software adequado e condições compatíveis. Os mineradores ajudam a determinar qual histórico válido continua, não o que todos devem considerar válido. [5] [6] [9]
Para ter uma visão mais completa, leia este verbete junto com Bitcoin, Proof of Work, Difficulty Adjustment, Regras de consenso, Mineração, Full Node. Também há referências a este verbete em Bit Gold, Reusable Proofs of Work, Byzantine Generals Problem, Sybil Attack.