SegWit

O que foi a atualização Segregated Witness?

BIP 141: Segregated Witness

A atualização Segregated Witness (SegWit) em 2017 mudou a estrutura dos dados de transação no Bitcoin.

O principal motivo dessa atualização foi corrigir a maleabilidade de transações (vou explicar isso em um instante). A outra mudança significativa foi um aumento do tamanho do bloco.

Qual foi a principal mudança?

Transação legada

Em uma transação legada, o código de destravamento (e as assinaturas) fica ao lado de cada entrada, então o código de destravamento fica espalhado por todos os dados da transação.

O TXID é então criado a partir dos dados inteiros da transação:

Diagrama mostrando a posição das assinaturas em uma transação legada e o TXID sendo criado a partir de todos os dados da transação.

Transação SegWit

Em uma transação segwit, porém, todo o código de destravamento (e as assinaturas) é movido para o final dos dados da transação.

O TXID é então criado a partir de todos os dados da transação, exceto o código de destravamento:

Diagrama mostrando a posição das assinaturas em uma transação segwit e o TXID sendo criado a partir de todos os dados da transação exceto as assinaturas.

Como resultado, o TXID em uma transação segwit só é influenciado pelos efeitos da transação (a movimentação de bitcoins) e não pelo código necessário para validar a transação (ou seja, as assinaturas necessárias para destravar os bitcoins para gasto).

Diagrama destacando como o código de destravamento não é mais incluído como parte do TXID em uma transação segwit.

Então, em essência, você separou a parte de "validação" (código de destravamento) do resto da transação.

Se você chamasse esse código de validação de dados de testemunha (witness), como um criptógrafo poderia, dá para dizer que você "segregou a testemunha". *pisca*

Quais são os benefícios?

  1. Corrige a maleabilidade de transações
  2. Aumento da capacidade do bloco

1. Corrige a maleabilidade de transações

No Bitcoin, a maleabilidade de transações se refere ao fato de que o TXID de uma transação pode ser alterado modificando as assinaturas:

Diagrama mostrando o TXID de uma transação legada sendo alterado pela modificação das assinaturas dentro dos dados da transação.

Uma assinatura pode ser alterada invertendo o valor s. A assinatura continua válida e a transação tem o mesmo efeito, mas o TXID é diferente.

Isso significa que, quando você envia uma transação legada para a rede, qualquer nó tem a capacidade de mudar o TXID antes de repassá-la:

Diagrama mostrando o TXID de uma transação legada sendo modificado depois de a transação ser enviada para a rede bitcoin.

Em algum momento, sua transação chegará à blockchain com um TXID diferente do que você esperava, o que seria meio irritante.

Porém, se as assinaturas não fazem mais parte do TXID, não é mais possível para outra pessoa mudar o TXID da sua transação depois:

Diagrama mostrando o TXID de uma transação segwit permanecendo o mesmo depois de ser enviada para a rede bitcoin.

Então, em outras palavras, o SegWit torna os TXIDs confiáveis.

2. Aumento da capacidade do bloco

Devido ao fato de o código de destravamento ter sido movido para um novo campo de testemunha nos dados da transação, a forma como os tamanhos dos blocos eram calculados também pôde ser alterada.

Antes, as transações eram medidas em bytes, e o limite de tamanho do bloco era de 1.000.000 bytes (1 MB):

Diagrama mostrando transações e capacidade de bloco medidas em bytes.

Com o SegWit, as transações não são mais medidas em bytes. Em vez disso, transações e blocos receberam uma nova métrica chamada peso (weight):

Diagrama mostrando transações e capacidade de bloco medidas em unidades de peso.

Então, basicamente, o limite de tamanho do bloco é multiplicado por 4 para dar o novo limite de peso do bloco.

Cada byte em uma transação é então também multiplicado por 4 para dar um peso de transação. Porém, você só multiplica os bytes de dados de testemunha por 1, o que basicamente dá um desconto de 75% no espaço que o "código de destravamento" ocupa em um bloco.

Então você poderia dizer que os dados de destravamento ocupam um quarto do espaço que ocupavam antes, o que significa que há mais espaço no bloco no geral para dados de transação.

O SegWit foi um aumento do tamanho do bloco?

Sim, cada bloco agora pode ter mais de 1.000.000 bytes (1 MB) de tamanho.

Então, embora o limite de tamanho do bloco não tenha sido aumentado por um número específico de bytes, o peso com desconto para os dados de destravamento significa que os blocos podem ultrapassar o limite anterior de 1 MB.

Só porque o tamanho do bloco mudou de 1.000.000 bytes para 4.000.000 unidades de peso, isso não faz do SegWit um aumento absoluto do tamanho do bloco para 4 MB.

Isso porque um bloco típico não será preenchido exclusivamente com dados de testemunha (1 unidade de peso por byte). Em vez disso, as transações contêm uma combinação de dados normais (4 unidades de peso) e dados de testemunha (1 unidade de peso). Então o "aumento do tamanho do bloco" varia dependendo da composição das transações em um bloco.

De quanto foi o aumento de tamanho do bloco com o SegWit?

A atualização SegWit aumentou o tamanho máximo para blocos típicos para cerca de 1,8 MB.

Veja bem, um bloco típico de transações consiste em cerca de 60% de dados de destravamento1. Então, se calcularmos o peso de um bloco de 1 MB composto por dados de transação "típicos", obtemos:

400.000 bytes * 4 = 1.600.000 unidades de peso
600.000 bytes * 1 =   600.000 unidades de peso

Peso Total        = 2.200.000 unidades de peso

Agora, se um bloco pode pesar no máximo 4.000.000 unidades de peso, podemos calcular de quanto é esse aumento:

4.000.000 / 2.200.000 = 1,81

Então você poderia dizer que isso foi, na prática, um aumento do limite de tamanho do bloco para 1,8 MB.

1. Cheguei a esse número de 60% percorrendo os arquivos blk.dat e somando os dados de scriptSig de todas as transações de um bloco, comparando com o tamanho total do bloco. Não fiz um teste exaustivo, mas 60% parece uma média justa.

Por que as mudanças foram implementadas dessa forma?

Ou, colocando de outro jeito…

Se você quer corrigir a maleabilidade de transações e aumentar a capacidade do bloco, certamente há uma forma mais direta de fazer isso? Por que você precisa reestruturar os dados da transação e criar uma nova métrica chamada "peso do bloco"?

Boa pergunta. E você tem razão – essas mudanças poderiam ter sido feitas de forma muito mais simples. Por exemplo, você poderia simplesmente ter feito isto:

Diagrama mostrando o código de destravamento sendo ignorado em uma transação legada ao criar um TXID, e um aumento direto do tamanho do bloco para 2 MB.

Porém, se você fizesse isso, as transações e os blocos se tornariam "inválidos" sob as regras atuais.

Basicamente, isso significa que os nós da rede rejeitariam essas novas transações e blocos, porque não cumprem suas regras de como transações e blocos devem "parecer".

Diagrama mostrando os nós existentes na rede rejeitando blocos que usam as novas mudanças de hard fork.

Por exemplo, uma das regras era que cada bloco deveria ter 1 MB ou menos.

Portanto, se você quisesse fazer essas mudanças, precisaria fazer todos na rede atualizarem seu software (e, obviamente, concordarem com as mudanças).

Porque, se não fizesse, acabaria com uma rede que constrói duas blockchains diferentes – nós atualizados construindo uma blockchain com as novas regras, e nós antigos continuando a construir uma blockchain com as regras antigas.

Diagrama mostrando a blockchain sendo dividida em duas versões separadas devido a uma mudança de hard fork.

Isso é conhecido como hard fork. Pode funcionar, mas é arriscado e causará problemas para quem não atualizar.

Como o SegWit evitou um hard fork?

Em vez de o SegWit ser um hard fork, ele foi implementado como um soft fork.

Com a atualização SegWit, as transações e os blocos ainda seguem as regras atuais da rede bitcoin, então todos os nós ainda veem os blocos SegWit como válidos. Portanto, nós "antigos" aceitarão esses "novos" blocos e os adicionarão às suas blockchains também.

Diagrama mostrando nós antigos que não atualizaram aceitando os novos blocos e transações SegWit.

Portanto, nós antigos ainda acompanham os novos nós, mesmo que não atualizem.

Diagrama mostrando tanto nós antigos quanto atualizados acompanhando a mesma versão da blockchain após uma mudança de soft fork.

Com um soft fork, todos permanecem em sincronia com uma única versão da blockchain.

A desvantagem para os nós "antigos" é que eles não conseguem aproveitar os novos recursos do SegWit até atualizarem. Porém, até lá, podem continuar a fazer transações "no estilo antigo" normalmente e acompanhar a blockchain.

Então, resumindo, a atualização SegWit pode parecer uma forma "gambiarra" de corrigir a maleabilidade de transações e aumentar a capacidade do bloco, mas essa abordagem evita o problema de tentar fazer todos atualizarem para o novo software (ou então ficarem para trás).

Quando o SegWit foi ativado?

O SegWit foi ativado em , na altura de bloco 481.824.

Foi quando os nós começaram a aplicar as novas regras de consenso da atualização SegWit para todos os novos blocos e transações.

Como o SegWit entrou em vigor?

A atualização Segregated Witness entrou em vigor quando 95% dos mineradores sinalizaram prontidão para ela.

Os mineradores podem sinalizar sua prontidão usando um número de versão designado nos blocos que mineram.

Diagrama mostrando o campo de versão no cabeçalho do bloco.

O campo de versão faz parte do cabeçalho do bloco.

Então, quando 95% dos blocos tinham esse número de versão, o SegWit foi agendado para ativação:

Diagrama mostrando como a atualização SegWit foi agendada para o próximo período de reajuste após um período de sinalização bem-sucedido.

O limiar de 95% é calculado dentro de um período de reajuste de dificuldade. Se o limiar de 95% for atingido, o soft fork é ativado no início do próximo período de ajuste de dificuldade (que é de 2016 blocos, ou cerca de 2 semanas).

Havia um prazo para a ativação?

Sim, esta era a janela de ativação:

Início:
Prazo final:

Se mineradores suficientes não sinalizassem sua prontidão para a atualização Segregated Witness até a meia-noite de 15 de novembro de 2017, a proposta teria expirado.

Linha do tempo da ativação

Aqui está uma tabela mostrando o número de blocos sinalizando para o SegWit em cada período de alvo até a ativação:

Início Período de Alvo Blocos Sinalizando Percentual
439.488 a 441.503451/201622,37%
441.504 a 443.519487/201624,16%
443.520 a 445.535520/201625,79%
445.536 a 447.551521/201625,84%
447.552 a 449.567489/201624,26%
449.568 a 451.583468/201623,21%
451.584 a 453.599485/201624,06%
453.600 a 455.615537/201626,64%
455.616 a 457.631532/201626,39%
457.632 a 459.647582/201628,87%
459.648 a 461.663614/201630,46%
461.664 a 463.679671/201633,28%
463.680 a 465.695698/201634,62%
465.696 a 467.711663/201632,89%
467.712 a 469.727622/201630,85%
469.728 a 471.743642/201631,85%
471.744 a 473.759825/201640,92%
473.760 a 475.775917/201645,49%
475.776 a 477.7911440/201671,43%
477.792 a 479.8072016/2016100,00%

Como você pode ver, o limiar de 95% de mineradores sinalizando prontidão para o SegWit foi ultrapassado durante o período de ajuste de dificuldade entre os blocos 477.792 e 479.807.

Consequentemente, a atualização SegWit foi ativada 2.016 blocos (cerca de 2 semanas) depois, no bloco 481.824:

InícioPeríodo de AlvoNota
479.808 a 481.823SegWit Travado (Locked In)
481.824 em dianteSegWit Ativado
  • O período de alvo de 439.488 a 441.503 foi o primeiro período de sinalização após o início da janela de ativação.
  • 100% dos blocos entre 477.792 e 479.807 sinalizaram para a atualização SegWit.
  • Há um intervalo de um período de alvo em que o soft fork fica "travado" (locked in) antes de ser ativado.

Por que a decisão sobre a ativação foi dada aos mineradores?

Porque, se você quer que um soft fork seja bem-sucedido, você quer a maioria dos mineradores minerando o "novo" tipo de bloco na blockchain.

Isso é para que a blockchain com os "novos" blocos ultrapasse qualquer blockchain sendo construída com blocos "antigos" (de quaisquer mineradores não atualizados que ainda pudessem estar minerando).

Como resultado, a "nova" blockchain será construída mais rápido do que qualquer blockchain sendo construída com blocos "antigos", então todos os nós naturalmente adotarão a mesma cadeia mais longa:

Diagrama mostrando a maioria dos mineradores construindo a cadeia mais longa com novos blocos após a atualização SegWit.

Ter a maioria do poder de mineração mantém todos na rede na mesma cadeia.

Então, ter uma forte maioria de mineradores a bordo permite uma atualização tranquila, pois garante que toda a rede convergirá para uma única blockchain.

Não é necessariamente que os mineradores sejam o grupo mais capacitado para decidir sobre os méritos de uma atualização via soft fork; é mais que eles são necessários para garantir uma atualização tranquila para toda a rede.

O que acontece se eu não rodar a atualização SegWit?

Se você está rodando um nó antigo (ex.: Bitcoin Core v0.13.0 ou inferior), quaisquer nós SegWit aos quais você esteja conectado vão remover todos os dados de testemunha das transações antes de enviá-las para você.

Diagrama mostrando um nó antigo não recebendo os dados de testemunha de transações segwit quando conectado a um nó atualizado.

O que isso significa é:

Então, basicamente, seu nó receberá uma versão "leve" das transações SegWit.

Como eu atualizo?

É esse o espírito.

O SegWit já existe há tanto tempo que é improvável que você se depare com algum software que não o suporte (a menos que seja obviamente antigo).

Recursos

Agradecimentos

Leitura adicional