Testemunha Segregada

A Testemunha Segregada é uma proposta do desenvolvedor Pieter Wuille, da Bitcoin Core, que utiliza um novo tipo de dado para diminuir a quantidade de dados armazenados em cada transação Bitcoin. Como resultado disso, mais transações caberiam em um bloco, permitindo um aumento prático no tamanho do bloco, sem precisar de uma hard-fork . Além das melhorias relacionadas a escalabilidade, a Testemunha Segregada ajuda com a maleabilidade das transações e diminui o custo de execução para um nó completo, já que menos dados precisam ser armazenados. Com a Testemunha Segregada, a especificação dos efeitos das transações no livro-razão é separada dos dados necessários para provar sua validade (chamado de testemunha, na área de criptografia). Isto elimina completamente todas as formas conhecidas de maleabilidade e permite otimizações significantes pela “podagem” do Bitcoin.

Proposta

A proposta da Testemunha Segregada é baseada sobre o conceito de Sidechain Elements, uma ideia complementar apresentada pelo desenvolvedor Luke Dashjr. Isto foi pensado nos últimos dois meses em cooperação com desenvolvedores da Bitcoin Core. Como tal, à partir da perspectiva de nós de Bitcoin que não usam Testemunha Segregada (vamos chamar de velhos nós), alguns outputs recentemente criados devem em breve usar um tipo 'estranho' de scriptPubKeys. 'Estranho', pois estas scritPubKeys podem dificilmente ser consideradas uma 'fechadura' de fato. Comumente referida como "qualquer um pode gastar", estas scriptPubKeys basicamente não requerem uma assinatura. Adicionalmente, elas irão incluir algum texto sem sentido. Velhos nós irão considerar essas transações sem sentido. Eles irão pensar que qualquer um pode criar uma nova scriptSig, destravando essas outputs, significando que elas são altamente inseguras. Mas ao mesmo tempo, velhos nós não se importam também. Depois de tudo, seus bitcoins estarão bagunçados, e outras pessoas estarão livres para fazer com seus bitcoins o que quiserem. O texto sem sentido será considerado esquisito, mas também necessário. Então eles irão confirmar as transações como válidas e irão repassar para os outros nós. No entanto, nós habilitados com Testemunha Segredada (novos nós) irão notar algo a mais. Eles verão o outro texto sem sentido na scriptPubKey, mas não irão considerar isto sem sentido de fato. Ao invés disso, novos nós irão reconhecer este pedaço de texto como outro - muito especial - tipo de Output. Típicos outputs muitos parecidos, este novo tipo de output irão requerer uma ou muitas assinaturas para destravar o bitcoin. Mas ao contrário dos outputs típicos, este novo tipo de output não irá requerer a assinatura para ser incluído na scripSitg da transação seguinte. Ao invés disso, irá requerer a assinatura para ser incluído em uma nova parte da transação: a Testemunha segregada. A Testemunha Segregada é basicamente um aprimoramento que carrega assinaturas e alguns dados adicionais. Importantemente, Testemunhas Segregadas são completamente ignoradas por velhos nós, mas reconhecidos por novos nós. No entanto, os dados que eles carregam não são hasheados com as outras partes da transação para criar um novo ID. Como tal, tanto os velhos como novos nós irão considerar transações contendo assinaturas em Testemunhas Segregadas válidas. Velhos nós validam elas porque pela sua perspectiva, estas transações não requerem assinaturas em geral (e não veem nenhuma), e novos nós validam elas porque a assinatura requerida está na Testemunha Segregada. E uma vez que ambos velhos e novos nós fazem hash nos dados da transação em um novo ID, todos concordam na elaboração dos blocos e como tal na estrutura da blockchain inteira. (No que é importante que todos os mineradores - ou a grande maioria - devam usar Testemunha Segregada a fim de prevenir duplos gastos e bifurcação de cadeias, ou nenhum deles deverá. Se todos os mineradores usarem Testemunha Segregada, velhos nós na rede devem se perguntar porque algumas transações não estão incluídas nos blocos, mas uma que eles sempre estiveram para os mineradores decidirem quais transações incluir, e uma vez que essas são suas transações, eles não irão se importar.) Mas existe um problema: se assinaturas não tiverem efeito na elaboração da blockchain, a mesma não servirá como prova que assinaturas corretas foram incluídas nas transações. Para ter certeza que estas assinaturas estarão inclusas na blockchain independentemente, os mineradores com Testemunha Segredas habilitadas adicionam uma charada também. Melhor que criar apenas a Árvores de Merkle de todas as transações, isto deve criar um Árvore de Merkle de todas as Testemunhas Segregadas, para espelhar a árvores de transações. A raiz da Testemunha Segregada, então, é incluída no campo input da transação coinbase. Como a raiz da Árvore de Testemunha Segregada muda os dados da transação coinbase, sua ID de transação, portanto influencia o cabeçalho do bloco e, por último, a elaboração da blockchain. A proposta da Testemunha Segregada permite assinaturas serem removidas de transações Bitcoin, enquanto mantém imutabilidade de Bitcoin, fazendo isso sem quebrar qualquer regra de consenso existente.

Custos

Dentre os principais custos 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:

1. 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.
2. 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:

1. 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.
2. 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.
3. 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
4. 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:

1. Usando um hash de 256 bits para P2WSH é melhor que o hash de 160 bits para P2SH; e
2. 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). Na medida que permite um maior volume de transações, pode-se esperar que ocorra o aumento da base de dados UTXO (Unspent Transaction Output) mais rapidamente (com 100% das transações usando as características de Testemunha Segregada, a taxa de crescimento poderá dobrar; no entanto, por causa da Testemunha Segregada ser soft-fork , o pior caso do crescimento UTXO é inalterado). Estes resultados podem ter atributos positivos, mas também podem ter possivelmente pontos negativos significantes:

• Blocos maiores podem resultar numa transmissão de blocos mais devagar, resultando em taxas maiores para os mineradores - dessa maneira pode resultar em menos segurança ou aumentar a centralização.
• Blocos maiores resultarão em requerimentos de recurso ainda maiores para os nós completos, potencialmente causando aos usuários desativarem seus nós, o que resultaria em uma maior centralização.
• Conjuntos maiores de UTXO resultariam em requerimentos de recurso ainda maiores para os mineradores, potencialmente causando aos mineradores compartilharem recursos de validação, o que resultaria em uma maior centralização.

Riscos relacionados a escalonamento de longo prazo

Como descrito acima, com a adoção completa de Testemunha Segregada por todas as transações é esperado que aproximadamente dobre a capacidade . Isto provê um aumento significante na capacidade, em curto e médio prazo, dependendo de quão rápida será essa adoração. Além disso, pelo adição de características que possibilitem duas camadas de rede, algum escalonamento a médio e longo prazo pode ser alcançado. Pelo conserto do bug de escalonamento quadrático da assinatura de hash, a Testemunha Segregada também reduz o risco de impactos negativos devido ao aumento futuro de capacidade. Testemunha Segregada, entretanto, não provê nenhum mecanismo direto para escalonamento de um volume de transações on-chain além daquela com duplicação única. Isto gera o risco de que as abordagens de escalonamento à longo prazo possam ser prevenidas ou atrasadas: as partes interessadas podem considerar que Testemunha Segregada como sendo “suficiente” para que se recusem a trabalhar ou apoiar novos esforços.

Vantagens

A Testemunha Segregada inclui uma ampla gama de características que vão além de simplesmente aumentar a capacidade das blockchains. Podemos citar algumas dessas características:

Ajuste de Maleabilidade

As transações Bitcoin são identificadas por um hash hexadecimal de 64 dígitos chamado de identificador de transação (txid) que é baseado em ambas as moedas gastas e que será capaz de gastar os resultados da transação. Infelizmente, a maneira que o identificador da transação é calculado permite que qualquer um faça pequenas modificações na transação que não mudará seu significado, mas mudará o seu identificador. Isso é chamado de maleabilidade de terceiros. A BIP (Bitcoin Improvement Proposal) 62 tenta endereçar essas emissões de uma maneira fragmentada, mas foi bastante complicado implementar como o consenso checa e portanto foi retirado. Por exemplo, você poderia submeter uma transação com identificador de transação eb32...f001 para a rede mas descobre que uma terceira parte, tal como um nó na rede retransmitindo sua transação, ou o minerador que inclui sua transação em um bloco, modifica suavemente a transação, resultando em uma transação que ainda gasta as mesmas moedas e paga os mesmos endereços, mas sendo confirmado sobre um identificador de transação completamente diferente(79f3...132b, por exemplo). De uma maneira mais geral, se um ou mais assinantes da transação revisam suas assinaturas então a transação permanece válida e paga as mesmas quantidades para os mesmos endereços, mas o identificador de transação muda completamente porque ele é incorporado às assinaturas. O caso geral das mudanças para os dados de assinatura (mas não saídas ou escolha das entradas) que modificam a transação é chamado de maleabilidade da scriptSig. A Testemunha Segregada impede a maleabilidade de terceiros e scriptSig permitindo que usuários Bitcoin movam partes maleáveis da transação nas testemunhas transação, e segregando tais testemunhas para que as mudanças na testemunha não afetem o cálculo do identificador de transação.

Benefícios:

Autores de carteiras podem rastrear bitcoins gastos: esta é a maneira mais fácil para o monitor de status de suas próprias transações de saída simplesmente olhar para elas pelo identificador de transação. Mas em um sistema com maleabilidade de terceiros, carteiras digitais devem implementar um código extra que seja capaz de lidar com mudança de identificadores de transações. Qualquer pessoa que gasta transações não confirmadas: se Alice paga Bob na transação, Bob usa este pagamento para pagar Charlie na transação 2, e então o pagamento de Alice fica maleável e é confirmado com um diferente identificador de transação (txid), então a transação 2 é agora inválida e Charlie não foi pago. Se Bob é confiável, ele irá re-emitir o pagamento para Charlie, mas se ele não for, ele pode simplesmente manter esses bitcoins consigo mesmo. A Rede Lightning: com a maleabilidade de terceiros e da scriptSig consertados, o Rede Lightning é menos complicada de implementar e significantemente mais eficiente em seu uso do espaço na blockchain. Com a maleabilidade da scriptSig removida, isto também seria possível para executar clientes leves da rede Lightning, que terceirizam monitoramento da blockchain, ao invés de cada cliente Lightning precisar também ser um nó Bitcoin completo. Qualquer usando a blockchain: contratos inteligentes hoje, tais como canais de micropagamentos, e novos contratos inteligentes antecipados, tornam menos complicados para projetar, entender e monitorar.

Escala linear de operações sighash

O maior problema com abordagens simples para aumentar o tamanho do bloco do Bitcoin é que para certas transações, o tempo de verificação da escala de assinatura hashing cresce quadraticamente, ao invés de linearmente. Em essência, dobrar o tamanho de uma transação pode dobrar tanto o número de operações de assinatura, como a quantidade de dados que tem que ser embaralhados (hashed) para cada uma das assinaturas a serem verificadas. Isto tem sido visto na prática, onde um bloco individual requer 25 segundos para validar, e transações projetadas maliciosamente poderiam levar mais que 3 minutos. A Testemunha Segregada resolve isto trocando o cálculo do hash da transação por assinaturas para que cada byte de uma transação precise apenas se embaralhado (hashed) no máximo duas vezes. Isto provê a mesma funcionalidade com mais eficiência, de modo que maiores transações possam ainda ser geradas sem correr problemas devido a hash de assinaturas, mesmo se elas são geradas maliciosamente ou blocos (e portanto maiores transações) ainda maiores são suportados.

Benefícios:

Removendo a escala quadrática dos dados embaralhados (hashed) para verificação das assinaturas faz aumentar o tamanho do bloco com mais segurança. Fazer isto sem também limitar o tamanho das transações permite que o Bitcoin continue a suportar pagamentos que vão ou vêm de grandes grupos, tais como pagamentos de recompensa para mineradores ou serviços de crowdfunding. O hash modificado apenas se aplica às operações de assinatura iniciadas a partir dos dados da testemunha, então as operações de assinatura do bloco base continuarão a requerer limites cada vez menores.

Assinatura dos valores de entrada Quando uma carteira de hardware assina uma transação, isto pode facilmente verificar a quantidade total que está sendo gasta, mas pode apenas determinar com segurança a taxa tendo uma cópia completa de todas as transações de entradas que estão sendo gastas, e deve aplicar o hash em cada um dessas para garantir que não está se alimentando de dados falsos. Desde que transações individuais possam ter mais que 1MB de tamanho, isto não é necessariamente uma operação cara, mesmo se a transação que estiver sendo assinada é em si muito pequena. Testemunha Segregada resolve isto fazendo explicitamente hash nos valores entrada. Isto significa que uma carteira de hardware pode simplesmente ser obtida pelo hash da transação, índice e valor (e dizer qual chave pública foi usada), e pode com segurança assinar a transação de gastos, sem se importar no quão grande ou complicada a transação que está gasta foi.

Benefícios:

Fabricantes e usuários de carteiras de hardware são os beneficiários óbvios; no entanto isto provavelmente também faria ser mais fácil assegurar o uso de Bitcoin em um dispositivo pequeno embarcado para aplicações de “Internet das coisas”. Este benefício é apenas disponível quando as transações de gasto enviam à Testemunha Segregada endereços habilitados (ou endereços segwit-via-P2SH).

Aumento da segurança para multi assinatura via processo pay-to-script-hash (PS2H) Pagamentos multi assinatura atualmente usam P2SH que é assegurada por um algoritmo HASH160 de 160 bits (RIPEMD de SHA256). No entanto, se um dos assinantes deseja roubar todos os fundos, eles podem encontrar uma colisão entre um endereço válido como parte de um script multi assinatura e um script que simplesmente paga a eles todos os fundos com apenas 80 bits (280) de trabalho, que já está incluso no domínio de possibilidade para um hacker extremamente bem munido de recursos. Testemunha Segregada resolve isto usando HASH160 apenas para pagamentos diretos a uma chave pública única (onde este tipo de ataque é inútil), enquanto usa hashes SHA256 de 256 bits para pagamentos a um hash de script.

Benefícios:

Todos que pagam contratos inteligentes ou multi assinatura, via Testemunha Segregada, se beneficiam da segurança extra provida pelos scripts.

Versionamento de script

Mudanças para o script Bitcoin permitem melhorar a segurança e também melhorar a funcionalidade. Entretanto, o projeto do script permite apenas mudanças compatíveis com versões anteriores (soft-forking) a serem implementadas pela troca de um dos 10 opcodes OP_NOP extras com um novo opcode que possa talvez trazer falha ao script, mas que por outro lado não faz nada. Isto é suficiente para muitas mudanças - tal como introduzir um novo método de assinatura ou uma característica como OP_CLTV, mas ambas são suavemente hackeáveis (por exemplo, OP_CLTV normalmente tem que ser acompanhada por um OP_DROP) e não pode ser usada para habilitar até mesmo características tão simples como unir duas cadeias. Testemunha Segregada resolve isto incluindo um número de versão para os scripts, para que opcodes adicionais que teriam um hard-fork a ser usada em transações sem Testemunha Segregada possam então ser suportadas simplesmente aumentando a versão do script.

Benefícios:

Mudanças mais fáceis nos opcodes do script farão com que o processo de scripting avançado no Bitcoin seja mais fácil. Isto inclui mudanças tais como introdução das assinaturas de Schnorr, usando chave de recuperação para escolher tamanho das assinaturas, suportar sidechains, ou criar até mesmo de contratos mais inteligentes usando Árvores de Merkle de Sintaxe Abstrata e outras ideias a nível de pesquisa.

Compactação de fraudes de prova Como a base de dados do Bitcoin aumenta, validar a blockchain inteira naturalmente se torna mais caro. Para a descentralização, natureza sem confiança do Bitcoin, é importante permitir aqueles que não podem pagar para validar a blockchain inteira para pelo menos ser capaz de validar da forma mais barata possível dentro do que eles possam pagar. Testemunha Segregada melhora a situação aqui permitindo uma soft-fork futura para ampliar a estrutura da testemunha incluindo dados de compromisso, que permitirão clientes leves (SPV) estabelecer regras de consenso tal como o número de bitcoins introduzidos em um bloco, o tamanho do bloco, e o número de sigops usados em um bloco.

Benefícios:

Provas de fraude permitem usuários SPV ajudar a estabelecer regras de consenso no Bitcoin,que potencialmente aumentará a segurança da rede Bitcoin como um todo, bem como reduzir as maneiras ao qual usuários individuais possam ser atacados. Estas provas de fraude podem ser adicionadas à estrutura de dados da testemunha como parte de uma futura soft-fork, e elas ajudarão clientes SPV a estabelecer as regras nas transações que não fazem uso das características de Testemunha Segregada.

Ganho de eficiência ao não se verificar assinaturas Assinaturas para transações históricas podem ser menos interessantes que assinaturas para futuras transações - por exemplo, Bitcoin Core não verifica assinaturas antes do ponto de verificação mais recente por padrão, e alguns clientes SPVs simplesmente não verificam eles mesmo as assinaturas, confiando que já foi feito por mineradores ou outros nós. No momento, entretanto, dados de assinatura são partes integrantes da transação e devem estar presentes com o fim de se calcular o hash da transação. Segregar os dados de assinatura permite que os nós que não estão interessados dos dados de assinatura podarem a partir do disco, ou evitar fazer o download em primeiro lugar, economizando recursos.

Benefícios:

Com mais transações usando endereços segWit, as pessoas que executam nós podados ou nós SPV serão capazes de operar com menos largura de banda ou espaço de disco.

Ver também

• Lightning Network
• Ethereum
• Bitcoin

Ligações externas

• «BigchainDB: A Scalable Blockchain Database» (PDF) (em inglês) 
• «DECOR+LAMI: A Scalable Blockchain Protocol» (PDF) (em inglês)