Guerra do tamanho dos blocos

Imaginemos duas necessidades comuns. Anna quer enviar bitcoin sem esperar muito nem pagar uma taxa elevada. Pavel mantém um nó completo: um computador que verifica blocos e transações por si. Quer poder verificar o seu dinheiro sem equipamento caro. Ambas as necessidades fazem sentido, mas mais dados em cada bloco também exigem mais transmissão e verificação. Era este equilíbrio que estava no centro da Block Size War. Um bloco é um conjunto de transações acrescentado ao histórico de pagamentos partilhado pela rede. Anna e Pavel são personagens ilustrativas. No debate real de 2015–2017 participaram programadores, operadores de mineração, plataformas de câmbio, fornecedores de carteiras e utilizadores. Discordavam da capacidade e da forma de introduzir alterações em segurança. O Bitcoin não tinha um diretor que escolhesse uma opção e ordenasse a todos que a adotassem. [1] [11] [13]

Antes do SegWit, as regras limitavam cada bloco a 1 MB, ou 1 000 000 de bytes. Não era um número fixo de pagamentos: as transações ocupam espaços diferentes. Surge um bloco aproximadamente a cada dez minutos, em média. Quando a procura excede a capacidade, os mineradores costumam dar prioridade a transações com taxas mais altas por unidade de espaço; as outras esperam. Os defensores de blocos maiores queriam acrescentar espaço diretamente à rede base e manter os pagamentos acessíveis. Os opositores receavam as exigências de ligação, computadores e rápida propagação dos blocos. Se menos pessoas conseguissem verificar por si, mais utilizadores dependeriam de terceiros. Um limite maior não acelera, por si só, a criação de blocos nem garante taxas baixas para sempre: a procura e a utilização efetiva continuam a contar. [1] [2] [13]

Um programador pode escrever software e um minerador produzir um bloco com ele. Mas quem opera um Full Node escolhe as regras que o seu nó verifica. Nem uma maioria do poder de cálculo consegue obrigar um nó inalterado a aceitar um bloco contrário às suas regras. Esse poder ajuda a escolher entre cadeias válidas; não torna válido um bloco inválido. Isto não atribui um voto a cada nó numa eleição mundial, nem permite a uma pessoa impedir outras de sair. As empresas escolhem o que aceitam, os mineradores o que mineram e os utilizadores aquilo a que dão valor. Regras incompatíveis podem originar duas redes. Um acordo empresarial podia apoiar uma alteração, mas não reescrever automaticamente os programas e as decisões de todos. [11] [12]

As propostas eram documentadas como BIP, sigla de Bitcoin Improvement Proposal. Um BIP explica uma proposta para que outros a possam analisar e discutir. Receber um número não significa que a rede a tenha adotado. Gavin Andresen propôs no BIP 101 elevar o limite para 8 MB, com aumentos posteriores segundo um calendário. O plano previa aproximadamente duplicá-lo de dois em dois anos e estabelecia condições de ativação. Mike Hearn e Andresen defendiam o Bitcoin XT, software alternativo que oferecia este caminho. Publicar o programa não equivalia a alterar as regras de toda a rede. Os nós antigos rejeitariam blocos acima do limite existente. Tratava-se de um Hard Fork: uma alteração que alargava o conjunto de blocos permitidos e exigia outras regras para os aceitar. A discussão deixou de ser apenas quanto espaço acrescentar. Quem mudaria, como se coordenaria a transição e o que aconteceria se uma parte significativa discordasse? [1] [18] [13]

Eric Lombrozo, Johnson Lau e Pieter Wuille descreveram outra abordagem no BIP 141. O SegWit reorganizou os dados das transações e introduziu o peso do bloco, limitado a 4 000 000 weight units. A parte chamada witness contém, nomeadamente, dados que permitem verificar a autorização para gastar. Estes não desapareceram nem deixaram de ser verificados; passaram a ter outro tratamento no cálculo do peso. A capacidade depende da composição das transações, em vez de simplesmente autorizar blocos comuns de quatro megabytes. O peso define como os dados contam para o limite do bloco: um byte de dados base conta como 4 unidades, enquanto um byte adicional relacionado com witness conta como 1. Transações com o mesmo tamanho em bytes podem, por isso, consumir pesos diferentes. A capacidade depende também dos tipos de transações utilizados. Nas transações abrangidas, o SegWit também impediu a alteração do identificador através de mudanças nos dados de assinatura. Isso facilitou os canais de pagamento em que assenta a Lightning Network. Foi concebido como Soft Fork: os novos blocos válidos enquadram-se nas regras antigas, embora os nós antigos não verifiquem todas as novas restrições. O Bitcoin Core 0.13.1 incluiu o mecanismo de ativação; lançar o software não ativou o SegWit por si só. [2] [3]

Em 23 de maio de 2017, a Digital Currency Group publicou o New York Agreement, um acordo entre empresas e mineradores. Associava o apoio ao SegWit a um Hard Fork para 2 MB no prazo de seis meses. Este segundo passo ficou conhecido como SegWit2x, implementado pelo projeto btc1. Para alguns participantes era um compromisso aceitável: cada lado receberia parte do que pretendia. Outros rejeitavam a segunda alteração e a forma de a promover. O apoio de uma empresa não representava automaticamente o consentimento de todos os clientes. Mais tarde, o Bitcoin Core esclareceu que o btc1 não era uma atualização obrigatória do seu programa e que apoiar SegWit não significava apoiar SegWit2x. Ao ler notícias da época, importa distinguir: duas alterações no mesmo acordo continuavam a ser duas alterações de regras diferentes. [6] [7] [11]

O autor sob pseudónimo Shaolin Fry propôs o BIP 148, uma forma de UASF, ou Soft Fork ativado pelos utilizadores. A partir de 1 de agosto de 2017, segundo Median Time Past, os nós com essa regra rejeitariam blocos sem sinalização SegWit, salvo se a ativação já estivesse fixada ou efetiva. Se mineração e aceitação de blocos divergissem, a rede podia dividir-se. Não era um interruptor sem risco acionado por todos em conjunto. Median Time Past é o valor central depois de ordenar as marcas temporais dos últimos 11 blocos, não a hora no relógio de cada utilizador. A sinalização consistia numa marca no cabeçalho do bloco que exprimia o apoio do minerador àquela implementação; a marca não ativava, por si só, as novas regras. James Hilliard descreveu no BIP 91 uma coordenação com um limiar inferior: 269 de 336 blocos, cerca de 80 %. Depois de entrar em vigor, os participantes rejeitariam blocos que não sinalizassem o apoio ao mecanismo original do SegWit. A coordenação de julho reduziu o perigo de conflito em torno do prazo de agosto. Não significou que o próprio SegWit já estivesse fixado ou ativo em julho: continuava a seguir o seu mecanismo BIP 9. [4] [5] [9] [19]

O Bitcoin Cash separou-se em 1 de agosto de 2017. O software Bitcoin ABC permitia blocos maiores nesse ramo, então com um limite predefinido de 8 MB. Desde a separação, as redes tinham regras e moedas próprias. Partilhar o histórico anterior não permitia transferir livremente pagamentos posteriores entre BTC e BCH. Bitcoin Cash não era SegWit2x, e Bitcoin ABC não era btc1. Confundir os nomes mistura a separação de agosto com outro plano suspenso mais tarde. Também diferiam na replay protection: como impedir a repetição de uma transação na outra cadeia. Para os utilizadores, havia uma consequência prática: operar num ramo não devia gastar involuntariamente fundos do outro. Também não era seguro introduzir as chaves comuns em qualquer ferramenta que prometesse novas moedas. [8] [15] [11]

O SegWit entrou no estado LOCKED_IN no bloco 479 808, em 9 de agosto de 2017. O período de decisão tinha terminado; restava um período de espera antes da aplicação das novas regras. A ativação ocorreu no bloco 481 824, em 24 de agosto. As duas alturas distam 2 016 blocos. A coordenação BIP 91 em julho, a fixação em agosto e a ativação foram acontecimentos distintos. Faltava a segunda etapa do SegWit2x, prevista para a altura 494 784. Em 8 de novembro, os organizadores, liderados por Mike Belshe, anunciaram a suspensão: segundo o comunicado, não tinham obtido acordo suficiente para uma transição tranquila. O Bitcoin não perdeu o SegWit já ativo, nem o Bitcoin Cash desapareceu. Terminou esta tentativa concreta de transformar o apoio empresarial e mineiro num aumento do limite do Bitcoin. [9] [10] [12] [14] [16] [17]

A disputa mostrou que o Bitcoin pode mudar, mas escrever código, reunir assinaturas de empresas e conseguir a aceitação de regras são tarefas diferentes. Não provou que os programadores não tenham influência, que os mineradores não importem ou que todas as decisões futuras tenham o mesmo resultado. Capacidade, verificação acessível e acordo entre participantes não se resolvem apenas mudando o nome de uma atualização. Perante uma proposta, pergunte primeiro o que altera, quais os nós que passariam a discordar e como seria ativada. Distinga depois a proposta, o software publicado e as regras efetivamente em vigor. Os BIP e o código da época documentam mecanismos; as declarações dos diferentes grupos documentam as suas posições. Nenhuma declaração de um participante constitui, só por si, uma história imparcial de todo o conflito. [1] [6] [11] [12]