em Blog, Notícias Bitcoin, Notícias Blockchain

No dia 5/Ago, Peter Todd publicou um artigo em seu blog trazendo detalhes sobre a Segwit, aumento de tamanho de bloco do bitcoin e também sobre alguns dos assuntos mais polêmicos do momento: Soft-fork e Hard-fork.

Abaixo segue a tradução para português que fiz do seu artigo.


Progresso sobre as propostas de Hard-Fork seguindo o Aumento de Bloco Segwit

Com o lançamento inicial da segwit se aproximando do release inicial em testnet no Bitcoin Core v0.13.0 – prevista para ser lançada em breve na mainnet no Bitcoin Core v0.13.1 – eu imaginei que seria uma boa ideia checar o trabalho sendo feito no potencial hard-fork que se seguiria e se a comunidade deveria decidir por aceitar a proposta segwit.

Antes de tudo, para recapitular, além de muitas outras melhorias, tais como a correção do ataque de maleabilidade, a correção da verificação de ataque DoS de assinaturas de transações muito longas, uma melhor maneira de atualizar o sistema de scripting no futuro, etc. segwit aumenta o tamanho máximo do bloco para até 4MB . No entanto, porque é um soft-fork – uma mudança retro-compatível com o protocolo – só a testemunha (witness – assinatura) pode tirar proveito desse aumento de bloco; dados non-witness ainda são limitados a 1MB total por bloco. Com os padrões de transações atuais, é esperado que os blocos pós-segwit não usarão todos os 4 MB de dados serializados permitidos pelo limite de tamanho máximo de bloco pós-segwit.

Em segundo lugar, há duas evoluções possíveis para o protocolo Bitcoin que irão reduzir ainda mais a quantidade de dados de assinaturas que a maioria das transações precisa: assinaturas Schnorr e as assinaturas agregadas BLS. Basicamente, ambas as melhorias permitem a combinação de múltiplas assinaturas, antigamente em nível de transação e futuramente em um nível por bloco.

Em fevereiro passado alguns membros da comunidade de mineração e alguns da comunidade de desenvolvedores se reuniram para discutir potenciais hard-forks, com o objetivo de chegar com uma proposta razoável à comunidade em geral, para posterior discussão e construção de consenso. Vejamos ao que esse esforço levou.

1) Ethereum: lições a serem aprendidas

Mas, primeiro, Ethereum. Ou como alguns dizem, o Etherea:

A batalha para Etherea. https://t.co/2ATQRQRXnH
– Samson Mow (@Excellion) 31 de julho de 2016

Se você estiver acompanhando de perto o universo das criptomoedas, você provavelmente sabe que a comunidade Ethereum foi dividida em duas, após um muito controverso hard-fork para o protocolo Ethereum. Para simplificar a história, uma característica não intencional em um smart-contract, chamado de “The DAO”, foi explorada por um ‘ainda desconhecido indivíduo’, e drenou cerca de US $ 50 milhões em moeda Ethereum (ethers) do contrato. Enquanto alguns “atacantes white-hat” conseguiram recuperar a maioria dos fundos na DAO, um hard-fork foi proposto com o intuito de reescrever o blockchain do Ethereum para recuperar todos os fundos – uma ação que muitos, inclusive eu, têm descrito como um resgate (bailout).

O resultado tem sido uma grande confusão. Este não é o lugar para falar sobre todo o profundo drama que se sucedeu, mas eu acho que é justo dizer que a comunidade Ethereum descobriu da maneira mais difícil que só porque você dá o mesmo nome de um protocolo já existente a um novo protocolo, não obriga todos a usá-lo. Como escrito, o que há um mês era chamado de “Ethereum” – Ethereum Classic – agora tem 20% do hashpower total do blockchain do resgate, e a apenas dois ou três dias atrás chegou em torno de 30%. Quanto ao valor de mercado, enquanto o total combinado para os dois blockchains é semelhante ao da chain de antes do fork, é possível que haja uma falha: há provavelmente um monte de moedas em ambos blockchains que não são realmente acessíveis e não representam ativos líquidos no mercado. Há uma boa chance de uma quantidade significativa de valor ter sido perdida.

Em particular, ambas as chains sofreram significativamente de problemas de transaction replay. Basicamente, devido à forma como o protocolo Ethereum foi  projetado – em particular sobre o fato de que o Ethereum não se baseia em um modelo UTXO – quando o blockchain Ethereum se divide e faz transações em uma chain, muito  possivelmente a transação também será válida para outra chain. Ambos os ataques e acidentes fizeram com que operações de uma chain acabassem sendo transmitidas para a outra, ocasionando um gasto não intencional. Este não foi um problema inesperado:

. @Petertoddbtc sabíamos que isso iria acontecer semanas antes do lançamento, nós não quisemos implementar replay-protection por causa da complexidade da implementação
– Vlad Zamfir (@VladZamfir) 31 de julho de 2016

… E isso levou a grandes perdas. Entre outras, a Coinbase perdeu uma quantidade desconhecida de fundos que eles podem ter que adquirir de volta. Pior ainda, a BTC-e perdeu praticamente todos seus valores de moedas originais Ethereum (ethers) – aparentemente se tornando insolvente – e, em vez de retornar os recursos dos clientes, eles decidiram declarar que o Ethereum original seria um golpe.

Uma coisa particularmente assustadora sobre este tipo de problema é ele que pode produzir uma demanda artificial para uma chain, que poderia até morrer: todos nós sabemos que a Coinbase esteve fazendo um trabalho de bastidores para comprar ethers substitutos, para compensar os que perdeu devido ao replay attack.

Mais genericamente, ainda sobre o fato de que a divisão da comunidade mostrou a dificuldade – e imprevisibilidade – de realização de consenso, de manter o consenso, e de dimensionar o consenso. Por exemplo, enquanto a comunidade Ethereum votou através da moeda como sugeri, a participação foi extremamente baixa – cerca de 5% – com uma minoria significativa na oposição (e note que as moedas das exchanges foram colocados numa lista negra de votação por razões técnicas). Além disso, o voto dos mineradores também teve baixa participação, e novamente, significativa oposição minoritária.

No que diz respeito ao drama resultante de uma divisão da moeda, algo que eu acho que poucos na comunidade técnica haviam considerado, é que as exchanges podem ter incentivos perversos para incentivá-la. A separação resultou em volume significativo de negociação da moeda pré-fork, status quo, Ethereum, o que obviamente é muito rentável para as exchanges. A segunda exchange a listar a chain status quo foi Poloniex, que atua em mais de 100 mercados Bitcoin, para uma ampla variedade de moedas de nicho – seu negócio é normalmente de moedas de nicho que não necessariamente possuem grande apelo.

Finalmente, tenha em mente que, enquanto isso tem sido ruim para o Ethereum, poderia ser ainda pior para o Bitcoin: ao contrário do Ethereum, o Bitcoin, na verdade, tem pouco uso no comércio e é usado por usuários que não estão, necessariamente, atualizados com as últimas notícias. Precisamos proceder com cuidado com todas as mudanças que não sejam retro-compatíveis se quisermos manter os usuários informados e protegê-los de envio e recebimento de moedas em blockchains que não tenham muita força.

2) Fazendo um split seguro

Então, como podemos dividir a rede de forma segura? Luke Dashjr escreveu tanto uma BIP como um código código preliminar para fazer uma combinação de hard-fork e soft-fork.

Esta não é uma idéia nova, de fato Luke postou-o para a lista de discussão bitcoin-dev em fevereiro passado, e tem sido reconhecido como uma opção sobre as opções dos anos anteriores; Eu, pessoalmente, mencionei-o neste blog em janeiro passado.

A idéia é basicamente que façamos um hard-fork – uma mudança que cria incompatibilidade nas regras – e envolvê-lo em um soft-fork para que todos os nós sejam forçados a escolher uma chain ou outra. O novo conjunto de regras do soft-fork é simples: nenhuma transação é permitida em tudo. Supondo que a maioria do hashpower (mineradores) optará por adotar o fork, os nós que não tomarem uma decisão sofrerão um ataque de 51% e seguirão por uma chain vazia, não podendo fazer quaisquer transações.

Para aqueles que não optarem por adotar o hard-fork, eles precisarão fazer um novo hard-fork para continuar transacionando. Isso pode ser tão simples como colocar o número do bloco onde houve a divisão em uma lista negra, ou algo mais complexo como uma mudança no proof-of-work.

No lado positivo, a proposta de Luke maximiza a segurança em muitos aspectos: enquanto a maioria do hashpower adota o fork, ninguém vai aceitar acidentalmente fundos não intencionais provenientes de uma chain.

2.1) Dando voz a todos

É notável que o que Luke chama de “soft-hardfork” também tem sido chamado de “soft-fork forçado” por mim, assim como um “evil fork” por muitos outros – o nome você dá a ele é uma questão de perspectiva. De um ponto de vista técnico, a ideia é um ataque de 51% contra aqueles que não optarem por apoiar o novo protocolo; é notável que quando eu disse isso a alguns mineradores, eles ficaram muito preocupados com o precedente que poderia abrir se mal executado.

Curiosamente, devido a detalhes de implementação, o hard-fork do Ethereum foi semelhante à sugestão de Luke: clientes Ethereum pré-fork, em geral, não conseguiam  iniciar devido a uma falha de implementação – na maioria dos casos – então todos foram obrigados a adquirir um novo software. No entanto, o Ethereum ainda se dividiu em duas moedas economicamente distintas.

Isso mostra que a tentativa de matar a cadeia indesejada de um split com um ataque de 51% não é uma panaceia: as pessoas podem e vão optar por usar a cadeia que eles quiserem se houver controvérsia. Por isso, é muito sábio conseguir um amplo consenso da comunidade em primeiro lugar.

Curiosamente, a proposta de exclusão de partes de hard-fork de Tom Harding também pode ser usada para medir o consenso. Basicamente, como um mecanismo anti-replay, as wallets poderiam começar (des)habilitando as partes de uma nSequence nos inputs de transações que um hard-fork tornaria inválidas, enquanto simultaneamente, um soft-fork poderia (des)habilitar uma parte diferente já inválida; o hard-fork poderia tornar uma segunda parte válida (usuários de nLockTime não poderiam (des)habilitar nenhuma das partes, fazendo com que suas transações fossem válidas em ambas as chains). Isso nos permite medir facilmente se a rede está pronta para um fork observando qual porcentagem de transações está definindo a parte anti-replay corretamente – um sinal de que estão rodando um software que está pronto para um hard-fork no futuro.

Em segundo lugar, eu tenho trabalhado em mecanismos mais concretos com base na sinalização/voto proporcional às moedas acumuladas, em particular, mecanismos out-of-band baseados em mensagens assinadas e amostragem probabilística que poderia oferecer uma melhor privacidade e resistência à censura, e dar voz aos “hodlers” que não estão necessariamente fazendo operações frequentes. Meu trabalho recente em tornar mais práticas as TXO comprometidas é parte desse esforço.

2.2) Tamanho UTXO

O desconto de dados de assinatura do Segwit tem o importante efeito de desencorajar a criação de novos UTXOs, em favor de gastar os já existentes, com a esperança de resultar em um crescimento reduzido das UTXO. Como uma cópia completa do conjunto UTXO é (atualmente) um requisito obrigatório para a execução de um nó completo (fullnode), mesmo com o prunning, é importante que nós tenhamos uma taxa de crescimento sustentável das UTXOs.

Matt Corallo tem trabalhado para encontrar as melhores formas de contabilizar adequadamente o custo para a rede, como um todo, da criação da UTXO, e ele me disse que estará publicando seu trabalho em breve. Além disso, eu tenho trabalhado em uma solução de longo prazo sob a forma de TXO comprometidas, que espero que possa eliminar totalmente o problema, permitindo que a UTXO seja arquivada, invertendo o  ônus de armazenamento para as wallets ao invés de todos os nós do Bitcoin. Além disso, Bram Cohen tem trabalhado em tornar as estruturas de dados, necessárias para as TXO comprometidas, mais rápidas em si mesmas, otimizando os padrões de acesso ao cache.

2.3) Latência de propagação de bloco

Uma preocupação significativa com qualquer aumento de bloco – incluindo segwit – é que quanto maior os requisitos de largura de banda, maior a centralização do hashpower devido aos efeitos que a alta latência tem entre grandes e pequenos mineradores. Matt Corallo recentemente tem feito uma quantia significativa de trabalho para mitigar esse efeito com seus blocos compactos – a ser lançado em v0.13.0 – e sua próxima geração de ‘rede de relay de blocos’ FIBRE.

Além disso, eu tenho feito uma pesquisa para compreender melhor as limitações dessas abordagens em contraditório, semi-contraditório, e “indiferentes” cenários.

2.4) Anti-Repetição

Eu mencionei o trabalho de Tom Harding, acima; Eu também vou mencionar que Gregory Maxwell propôs uma solução genérica – e muito robusta – para anti-repetição (anti-replay attack): as transações tem que se comprometer com um recente, mas não tão recente (com mais de ~100 blocos) hash de bloco (block hash). Enquanto isso tem algumas desvantagens potenciais em uma grande reorganização – as transações podem tornar-se permanentemente inválidas devido a hashes de bloco diferentes – desde que os hashes de bloco comprometidos também não seja muito recente, a ideia resolve os replay attacks nas chains de maneira robusta, de uma forma que é completamente genérica não importando quantos forks venham a acontecer. Por exemplo, uma maneira razoável de se implementar seria que as wallets se recusassem a fazer transações no primeiro ou segundo dia após o hard-fork, e então usar um blockhash pós-fork em todas as transações para garantir que elas não possam ser repetidas em um chain indesejada.

Peter Todd

Link para o artigo original: https://petertodd.org/2016/hardforks-after-the-segwit-blocksize-increase