SegWit ou Segregated Witness (Testemunha Segregada), é uma proposta de mudança nas regras do software que rege o protocolo Bitcoin. Teve como objetivo sanar os problemas relacionados a maleabilidade de transações,aumentar a capacidade máxima do bloco e implementar recursos necessários para o suporte a outras aplicações como a Lightning Network (Rede Relâmpago). SegWit se caracteriza como um Soft Fork, isto é, um enrijecimento das regras do protocolo que leva a uma retrocompatibilidade com os antigos blocos da rede. Logo, ao contrário dos Hard Forks, seu ativamento não provoca a criação de uma nova blockchain. Sua ativação foi resultado de um consenso entre os usuários na rede Bitcoin, sendo necessário mais de 95% de aprovação da comunidade pela mudança. No dia 24 de Agosto de 2017, o SegWit foi ativado na rede principal do Bitcoin.
Maleabilidade Uma transação no protocolo Bitcoin é identificado por um número hexadecimal de 64 dígitos chamado de txid (Transaction ID). Este número é gerado usando as informações do endereço Bitcoin do destinatário e as moedas que estão sendo gastas. O txid(ID de Transação) pode ser usado para rastrear informações sobre a transação na blockchain tais como a quantidade de Bitcoin enviados, os endereços de envio e recebimento das moedas e a data da transferência. Contudo, a maneira como o txid é calculado permite que qualquer um possa fazer pequenas alterações na transação. Estas modificações não mudam o valor de Bitcoins sendo gastos, seu destino ou endereço de origem. Porém, afetam o ID de transação. Como exemplo, imagine que as seguintes transações ocorram dentro de um curto período de tempo:
Exemplo: Ana realiza o pagamento de 1 bitcoin a Roberto. Roberto usa o txid vindo da transação de Ana para pagar 1 bitcoin José. Se a transação entre Ana e Roberto for incluída na blockchain usando um txid diferente do informado por Roberto a José, esta última transação se tornará inválida. Caso José tenha oferecido um serviço ou enviado um produto a Roberto, Roberto poderia agir de má fé e não refazer a transação usando o txid válido.
Este problema poderia ser evitado caso José esperasse por algumas confirmações na blockchain antes de realizar sua parte da transação. Contudo, carteiras de bitcoin necessitavam de código extra para lidar com este problemas. Em meados de 2015, a rede bitcoin sofreu alguns ataques baseados na maleabilidade de endereços.
Devido ao problema de maleabilidade nas transações, não é possível criar serviços que dependem ou utilizem múltiplas transações não-confirmadas em sequência, pois uma mudança no ID de Transação pode acabar quebrando o resto da corrente de transações. Isto se torna um grande problema para os Contratos Inteligentes (Smart Contracts) e diversas outras aplicações mais avançadas como: Rede Relâmpago, aumentando enormemente o número de transações por segundo; Trocas Atômicas(Atomic Swaps) entre diferentes criptomoedas; Assinatura de Schnorr, que iriam prover outro aumento na capacidade de transações por bloco; MAST(Merkelized Abstract Syntax Trees), uma forma de aprimorar contratos inteligentes (Smart Contracts); TumbleBit, um rede de segunda camada anônima;
Proposta A Testemunha Segregada (Segregated Witness ou SegWit) é uma modificação ao protocolo do Bitcoin que propõe a separação dos dados de assinatura de uma transação — designados por testemunha (witness) — do restante conteúdo da transação.
A proposta foi desenvolvida com o objetivo de resolver o problema da maleabilidade das transações, aumentar a capacidade efetiva dos blocos e possibilitar a implementação de soluções de segunda camada, mantendo a compatibilidade com versões anteriores através de um soft fork.
Separação dos dados de assinatura No formato tradicional das transações Bitcoin, os dados de assinatura fazem parte da informação utilizada para calcular o identificador da transação (txid). Como as assinaturas podem ser alteradas sem invalidar a transação, é possível modificar o txid, originando o problema conhecido como maleabilidade de transações.
A solução proposta pelo SegWit consiste em mover os dados de assinatura para uma estrutura separada do bloco, denominada testemunha. Dessa forma, o txid passa a ser calculado apenas com base nos dados principais da transação, excluindo as assinaturas.
Retrocompatibilidade e consenso A Testemunha Segregada foi concebida para ser ativada como um soft fork. Nós que não reconhecem o novo formato continuam a considerar válidas as transações SegWit, uma vez que os dados da testemunha são estruturados de modo a parecerem dados não relevantes para esses nós. Os nós atualizados, por sua vez, validam explicitamente a testemunha e aplicam as novas regras de consenso.
Estrutura de dados da testemunha Para garantir a integridade dos dados segregados, é utilizada uma árvore de Merkle separada para a testemunha. A raiz dessa árvore é incluída no bloco, assegurando que os dados de assinatura fazem parte do consenso da rede, apesar de não integrarem a árvore principal de transações.
Consequências A separação da testemunha elimina a maleabilidade das transações, permitindo que o identificador de uma transação permaneça imutável após a sua criação. Além disso, o SegWit introduz o conceito de unidade de peso, no qual os dados da testemunha têm menor impacto no limite de tamanho dos blocos, aumentando a capacidade efetiva da rede sem alterar diretamente o limite histórico de 1 MB.
Esta abordagem facilita também a introdução de futuras melhorias no protocolo, como novas versões de scripts e mecanismos de assinatura mais eficientes.
Ativação Para que um Soft Fork ou Hard Fork seja ativado, é preciso haver um consenso na rede sobre qual versão do software do Bitcoin será utilizada. A forma de ativação escolhida para o SegWit foi o MASF(Miner Activated Soft Fork), descrito pelo BIP 9 (Bitcoin Improvement Proposal). De acordo com o BIP 9, a atualização começará a ser implantada a partir de uma data inicial e a cada 2016 blocos (em torno de 2 semanas) é feita a quantificação de quantos mineradores sinalizaram acordo sobre a mudança das regras. No caso do SegWit, um minerador indicava acordo com as mudanças sinalizando com o número 1 no campo de versão do bloco, dando assim prova de sua concordância. Para que o SegWit fosse ativado com sucesso, mais de 95% dos mineradores deveriam mostrar acordo entre um período de 2016 blocos (em torno de 2 semanas). Contudo, na ativação através do BIP 9 também existe uma data final definida. Se, até a data final, não houvesse consenso suficiente por parte dos mineradores, a mudança não seria adotada. A data de início do SegWit foi de Novembro de 2016 e se estenderia até Novembro de 2017. No dia 24 de Agosto de 2017, o SegWit foi ativado na rede principal do Bitcoin.
Custos Dentre os principais custos Segregated Witness Costs and Risks, , Bitcoincore.org, 28 de Outubro de 2016 relativos a implantação da Testemunha Segregada temos:
Custos de Serialização
Transações e informações de bloco são serializadas por três motivos principais: Transmissão através da rede peer-to-peer; Armazenamento da blockchain no disco; e Avaliação do limite dos blocos
Testemunha Segregada afeta a serialização em duas formas: O comprometimento da testemunha é incluído na transação da moeda base, adicionando entre 38 e 47 bytes, ou algo em torno de 0,005% de um bloco. Uma nova serialização de transação que inclui os dados de testemunha segregada é definida. Isto adiciona uma sobrecarga de 2 bytes por transação para permitir que os formatos de serialização sejam mais facilmente distinguíveis, e um overhead de 1 byte por entrada para contagem dos itens da testemunha para cada entrada. Isto combina cerca de 1% por transação. Os formatos das transações de Testemunha Segregada tem o seguinte impacto quando serializados (para compreender os termos abaixo olhar , BIP141: Comparado a P2PKH, P2WPKH usa 3 bytes a menos (-1%) in the scriptPubKey, e o mesmo número de bytes de testemunha assim como a assinatura de script P2PKH. Comparado a P2SH, P2WSH usa 11 bytes adicionais (6%) na scriptPubKey, e o mesmo número de bytes que a assinatura de script (scriptSig) P2SH. Comparado a P2PKH, P2WPKH/P2SH usa 21 bytes adicionais (11%), devido ao uso de 24 bytes na scriptPubKey, 3 bytes a menos na scriptSig do que na scriptPubKey da P2PKH, e o mesmo número de bytes de testemunha assim como na scriptSig P2PKH Comparado a P2SH, P2WSH/P2SH usa 35 bytes adicionais (19%), devido ao uso de 24 bytes na scriptPubKey, 11 bytes adicionais na scriptSig comparada a P2SH scriptPubKey, e o mesmo número de bytes de testemunhas da scriptSig da P2SH.
Os percentuais acima são baseados em uma transação de 180 bytes com um entrada e uma saída. Estas proporções permanecem as mesmas à medida que o número de entradas/saídas aumenta, mas decresce se scripts de transações complicadas estão em uso.
Fundamentação A sobrecarga do tamanho da transação é dada por dois fatores: Usando um hash de 256 bits para P2WSH é melhor que o hash de 160 bits para P2SH; e Codificação via P2SH a fim de que as carteiras antigas que não tem suporte a Testemunha Segregada possam enviar fundos que podem ser gastos usando segWit, permitindo ao usuário que recebe ganhar os benefícios de segWit.
Sem esses dois fatores, a sobrecarga seria negligenciada em 3 bytes a menos para P2WPKH e 1 byte a mais para P2WSH.
Custos de validação de blocos
Com a Testemunha Segregada, processamento adicional é apresentado quando se valida um bloco, com o fim de verificar a Árvore de Merkle da Testemunha, e lidar com as transações de testemunha codificadas por P2SH. Isto requer cerca de 5 hashes SHA256 adicionais por transação, um SHA256 adicional por entrada P2SH-codificada-P2WSH, e um HASH160 adicional por saída P2SH-codificada-P2WPKH. Isto entretanto é apenas cerca de 6 execuções de SHA256 sobre a maioria dos 4MB de dados, ou praticamente cerca de 24MB de dados SHA256 ao todo, o que deveria ser traduzido em no máximo 15 segundos adicionais por bloco em um Raspberry Pi v1, ou menos de um décimo de um segundo em um hardware mais capaz.
Riscos
Riscos de introduzir bugs
O conjunto de ajustes é uma grande mudança para o Bitcoin, e foi lançada, apesar de não ter sido ativada na rede de Bitcoin principal, no Bitcoin Core 0.13.0. Qualquer grande mudança como esta corre uma variedade de riscos, tais como: Bugs definitivos: erros podem ser cometidos no projeto ou implementação levando a resultados inesperados e prejudiciais Erros de usuário: mudanças no sistema podem ocasionar em confusão para os usuários, resultando no uso incorreto do sistema, que por sua vez podem levar a resultados prejudiciais. Interações no ecossistema: partes diferentes do ecossistema Bitcoin podem ter premissas de codificação rígida que serão violadas com a atualização. Por exemplo, aplicações que analisam o armazenamento dos blocos de bitcoin precisarão ser atualizados para compreender a nova serialização.
Riscos devido a blocos maiores
Testemunha Segregada atualizou o limite de bloco de 1MB para um limite de unidade de peso de bloco de 4MB, contando os dados serializados de testemunha como uma unidade, e os dados do bloco central como quatro unidades. Com as transações que usam as características Testemunha Segregada sendo usadas, esta mudança permitirá mais dados a serem incluídos por bloco (com 100% das transações usando características da Testemunha Segregada é esperado cerca de 2MB de dados por bloco, entretanto no pior caso poderia subir para 4MB de dados por bloco).