Soft Fork
Uma mudança compatível com o software antigo
-
Greg Walker - Atualizado em
Um soft fork é quando é feita uma atualização no software do Bitcoin que é compatível com as versões anteriores do software.
Para resumir a diferença entre um soft fork e um hard fork:
- Um hard fork expande as regras do que torna um bloco/transação válido.
- Um soft fork restringe as regras do que torna um bloco/transação válido.
Com um soft fork, os nós que não atualizam seu software ainda conseguem aceitar blocos/transações criados pelo software atualizado. Portanto, nós que não atualizam conseguem se manter atualizados com a blockchain e não ficam para trás.
Para tornar uma mudança via soft fork bem-sucedida, você só precisa que uma maioria dos mineradores da rede atualize para a nova versão do software. Porque, se você tem uma maioria de mineradores atualizando, o poder de mineração deles vai construir a cadeia mais longa de blocos atualizados (que os nós antigos vão adotar).
Cenário
Como você cria um soft fork?
Para criar um soft fork, você precisa restringir as regras do que é considerado um bloco ou transação válido.
Em outras palavras, você precisa tornar blocos/transações antes válidos em inválidos.
Por exemplo, digamos que o limite de tamanho do bloco seja 1 MB (a capacidade do bloco agora é medida em peso, mas não se preocupe com isso por enquanto). Uma mudança via soft fork seria criar uma nova regra que restringe o tamanho do bloco para 0,5 MB (parece um passo para trás, eu sei, mas isto é só um exemplo).
Quando mineradores atualizados começam a minerar esses blocos menores, os nós antigos ainda os veem como válidos, então não há ramificação da blockchain como haveria num hard fork.
Método
Como tornar um soft fork bem-sucedido?
Para tornar um soft fork bem-sucedido, você quer uma maioria de mineradores atualizando para a nova versão do software.
Isso porque os nós sempre aceitam a cadeia mais longa de blocos. Então, se a maioria dos mineradores está minerando os blocos atualizados com as regras restritas, os nós antigos naturalmente adotam isso como sua blockchain.
Então, mesmo que uma minoria de mineradores antigos continue construindo a blockchain com blocos antigos, eles não conseguirão competir com a velocidade em que os novos blocos estão sendo minerados pelos mineradores atualizados, de modo que os nós antigos vão adotar a mesma versão da blockchain que os nós atualizados.
Riscos
Quais são os riscos de um soft fork?
O principal risco de um soft fork é se você não conseguir a maioria dos mineradores atualizando.
Isso resultaria na blockchain se dividindo em duas, pois uma maioria de mineradores antigos continuaria minerando blocos antigos que são incompatíveis com a nova versão do software.
E como os blocos antigos formam a cadeia disponível mais longa, os nós antigos vão adotá-la como sua blockchain. Porém, os nós atualizados vão rejeitar esses blocos antigos (porque esses blocos agora são inválidos segundo suas regras atualizadas), e vão adotar a cadeia disponível mais longa contendo apenas os novos blocos.
Então, mais uma vez, assim como em um hard fork, você tem duas versões paralelas da blockchain: uma contendo blocos antigos e outra contendo blocos novos.
Porém, diferente de um hard fork, onde as duas cadeias nunca podem convergir, essa divisão de cadeia pode ser resolvida colocando mais poder de mineração na nova cadeia. Se os mineradores atualizados conseguem construir a cadeia mais longa, os nós antigos fazem uma reorganização da cadeia para adotar a blockchain feita com os novos blocos.
Assim, ao conseguir que uma maioria de mineradores atualize, você "incentiva" todos na rede a se manterem atualizados com a mesma versão da blockchain.
Compromissos
Qual é a desvantagem de um soft fork?
A maior desvantagem dos soft forks é que eles tendem a tornar o software mais complexo (o Segregated Witness é um exemplo perfeito).
Seria mais fácil fazer atualizações diretas no software por meio de hard forks. Porém, uma mudança via hard fork é indesejável devido ao maior risco de uma divisão de cadeia (e à necessidade de forçar todos a atualizar), então a maioria das atualizações é feita por meio de soft forks.
Como resultado, o fato de você ter de manter as mudanças compatíveis com o software antigo significa que precisa fazer mais contornos técnicos, e isso torna o software mais complexo do que se você tivesse a liberdade de fazer mudanças incompatíveis com os nós antigos.
Em resumo:
- Um hard fork permite substituir regras e código diretamente.
- Um soft fork envolve adicionar mais código para acomodar as novas regras.
Exemplos
Houve soft forks no bitcoin?
Todas as grandes atualizações do Bitcoin até agora foram implantadas como soft forks.
Aqui estão alguns exemplos, incluindo um resumo das novas restrições que introduziram:
1. BIP 16: Pay to Script Hash
Problema
Não havia uma forma conveniente de fazer outras pessoas usarem travas personalizadas de sua escolha ao lhe enviar bitcoins.
Restrição
Um padrão específico de ScriptPubKey agora tem regras de validação adicionais (veja P2SH).
Assim, enquanto o padrão de script de travamento OP_HASH160 OP_PUSHBYTES_20 digest OP_EQUAL antes exigia apenas que você fornecesse algum dado cujo hash resultasse em digest para destravá-lo, agora você precisa fornecer algum dado na forma de um script de travamento personalizado cujo hash resulte em digest e que possa ser avaliado e destravado em uma segunda etapa de execução.
Em outras palavras, regras adicionais foram acrescentadas para como um script de travamento específico pode ser destravado.
2. BIP 30: Transações duplicadas
Problema
Não se pensava ser possível ter transações duplicadas no Bitcoin.
Porém, transações coinbase em blocos diferentes poderiam ter o mesmo TXID, permitindo transações duplicadas na blockchain. Isso também permitiria que mais transações duplicadas fossem criadas posteriormente.
Restrição
Os blocos não podem conter uma transação com um TXID que coincida com o de uma transação anterior ainda não totalmente gasta na mesma cadeia.
3. BIP 34: Bloco v2, Altura na Coinbase
Problema
Mesmo após a introdução do BIP 30 (veja acima), ainda era possível que mineradores construíssem transações coinbase duplicadas em blocos diferentes.
Restrição
Uma transação coinbase deve conter a altura do bloco como primeiro campo do ScriptSig. Isso garante que toda transação coinbase será única (e, portanto, terá um TXID único).
Qualquer transação coinbase que não contivesse a altura do bloco atual passaria a ser inválida.
4. BIP 65: OP_CHECKLOCKTIMEVERIFY
Problema
Não havia mecanismo para tornar uma saída de transação não gastável até uma data futura.
Restrição
O opcode OP_NOP2 foi reaproveitado como OP_CHECKLOCKTIMEVERIFY.
Como resultado, o opcode OP_NOP2 deixou de "não fazer nada", e scripts que o usam não mais seriam executados com sucesso sem que regras adicionais fossem satisfeitas.
5. BIP 66: Assinaturas DER estritas
Problema
Falta de consistência na codificação das assinaturas nas transações devido à dependência da biblioteca OpenSSL.
Restrição
Restringir as assinaturas a seguir um único formato de codificação. Isso facilita que implementações do Bitcoin não precisem depender do OpenSSL como dependência.
6. BIP 141: Segregated Witness
Problema
O TXID podia ser modificado depois de enviar uma transação para a rede, o que significava que você não podia depender do TXID para referenciar a transação posteriormente.
Isso acontecia porque o TXID era feito incluindo as assinaturas dentro da transação, e essas assinaturas podiam ser modificadas depois de criadas (ainda assim permanecendo válidas).
Restrição
Dois novos padrões de ScriptPubKey (P2WPKH, P2WSH) que antes eram gastáveis por qualquer um agora só são gastáveis sob certas condições.
Isso permite uma nova estrutura de dados de transação, onde as assinaturas ficam no fim dos dados da transação (em uma nova área de testemunha) e não entram na criação do TXID.
O Segregated Witness também permitiu um aumento do tamanho do bloco. Isso foi possível por não enviar a nova seção de testemunha das transações (contendo as assinaturas) aos nós antigos. Os nós antigos veriam essas saídas como gastáveis por qualquer um de qualquer forma, então as assinaturas não eram necessárias para que as transações fossem consideradas válidas.
7. BIP 341: Taproot
Problema
Um ScriptPubKey revela todas as suas condições de gasto dentro dos dados da transação. Elas podem ser complexas e grandes, e exibir todas as condições de gasto não é bom para a privacidade.
Restrição
Um novo padrão de ScriptPubKey (P2TR) que antes era gastável por qualquer um agora só é gastável sob certas condições. Isso permite um novo mecanismo de travamento e destravamento que revela apenas uma condição de gasto (e não todas as outras condições de gasto que podem ter existido para a trava).
Implantação
Como os soft forks são implantados?
O objetivo de um soft fork bem-sucedido é fazer uma maioria de mineradores concordar com a atualização.
Então, antes de a mudança via soft fork ser ativada, os mineradores são solicitados a sinalizar sua prontidão de antemão. Os mineradores podem sinalizar prontidão definindo um bit específico no campo version do cabeçalho do bloco.
Por exemplo:
00100000 00000000 00000000 00000001 = Bit 0 = CHECKSEQUENCEVERIFY (BIP 65)
00100000 00000000 00000000 00000010 = Bit 1 = Segregated Witness (BIP 141)
00100000 00000000 00000000 00000100 = Bit 2 = Taproot (BIP 341)
Version Bits
Quando 90-95% dos mineradores estão sinalizando que concordam com a atualização dentro de um período de ajuste de dificuldade (e que vão minerar os novos blocos com as novas regras), o soft fork fica "travado" (locked in), e em uma altura de bloco específica os mineradores começam a minerar os novos blocos.
- Os 3 primeiros bits da versão precisam ser
001para poder sinalizar prontidão para soft forks. - Soft forks anteriores (ex.: BIP 16) foram implantados antes desse sistema específico de sinalização ser criado.
- Soft forks geralmente exigem 95% dos mineradores sinalizando para a ativação, mas para o Taproot isso foi mudado para exigir apenas 90%.
Resumo
Um soft fork é uma atualização do software do Bitcoin que é compatível com versões antigas do software. Ele mantém essa compatibilidade restringindo as regras sobre blocos/transações válidos, em vez de relaxá-las como em um hard fork.
O principal benefício de um soft fork é que todos os nós da rede conseguem se manter atualizados com a blockchain mesmo que não atualizem.
A chave para um soft fork bem-sucedido é conseguir que uma maioria de mineradores atualize para a nova versão do software. Ao fazer isso, os mineradores terão o poder de construir a cadeia mais longa de novos blocos/transações, e os nós antigos naturalmente adotarão essa cadeia mais longa contendo os blocos atualizados.
Todas as atualizações do software do Bitcoin até agora foram feitas via soft forks.