O roteiro a seguir foi publicado originalmente no lista de discussão bitcoin-devpor Gregory Maxwell em 07/12/2015.
O Workshop Scaling Bitcoin em HK está terminando. Muitas propostas fascinantes foram apresentadas. Acho que este seria um bom momento para compartilhar minha visão do arco de curto prazo para aumentos de capacidade no sistema Bitcoin. Acredito que estamos numa situação fantástica neste momento e que a comunidade está pronta para seguir um caminho claro e futuro com uma visão partilhada que atenda às necessidades do sistema, ao mesmo tempo que defende os seus valores.
Penso que é importante primeiro expressar claramente alguns dos princípios relevantes que penso que deveriam orientar o desenvolvimento contínuo do sistema Bitcoin.
Bitcoin é dinheiro eletrônico P2P valioso em relação aos sistemas legados devido à autonomia monetária que traz aos seus usuários por meio da descentralização. O Bitcoin procura resolver o problema raiz da moeda convencional: toda a confiança necessária para fazê-lo funcionar.
– Não que a confiança justificada seja uma coisa má, mas a confiança torna os sistemas frágeis, opacos e dispendiosos de operar. As falhas de confiança resultam em colapsos sistémicos, a curadoria de confiança cria desigualdade e aprisionamento de monopólio, e os pontos de estrangulamento de confiança que surgem naturalmente podem ser utilizados de forma abusiva para negar o acesso ao devido processo. Através do uso de provas criptográficas e redes descentralizadas, o Bitcoin minimiza e substitui esses custos de confiança.
Com a tecnologia disponível, existem compromissos fundamentais entre escala e descentralização. Se o sistema for demasiado dispendioso, as pessoas serão forçadas a confiar em terceiros, em vez de aplicarem de forma independente as regras do sistema. Se o uso de recursos do blockchain Bitcoin, em relação à tecnologia disponível, for muito grande, o Bitcoin perde suas vantagens competitivas em comparação com sistemas legados porque a validação será muito cara (precificando muitos usuários), forçando a confiança de volta ao sistema. Se a capacidade for demasiado baixa e os nossos métodos de transacção demasiado ineficientes, o acesso à cadeia para resolução de litígios será demasiado dispendioso, empurrando novamente a confiança para o sistema.
Como o Bitcoin é um dinheiro eletrônico, ele não é um banco de dados genérico; a demanda por armazenamento perpétuo barato e altamente replicado é ilimitada, e o Bitcoin não pode e não irá satisfazer essa demanda por uso não-ecash (não-Bitcoin), e não há vergonha nisso. Felizmente, o Bitcoin pode interoperar com outros sistemas que atendem a outras aplicações e – com sorte e trabalho duro – o sistema Bitcoin pode e irá satisfazer a demanda mundial por dinheiro eletrônico.
Felizmente, há muita tecnologia excelente em desenvolvimento que torna mais fácil navegar pelas compensações.
Primeiro: após vários anos de criação, o Bitcoin Core fundiu recentemente o libsecp256k1, o que resulta em um enorme aumento no desempenho de validação de assinatura. Combinado com outros trabalhos recentes, agora estamos obtendo desempenho do ConnectTip 7x maior no 0.12 do que nas versões anteriores. Isso já demorou muito para acontecer e, sem sua antecipação e trabalho anterior, como headers-first, eu provavelmente estaria defendendo uma redução no tamanho do bloco no ano passado. Esta melhoria no estado da arte para software Bitcoin de produção amplamente disponível prepara o terreno para alguns aumentos de capacidade, ao mesmo tempo que recupera o nosso défice de descentralização. Isso transfere os gargalos da CPU e mais fortemente para a latência de propagação e largura de banda.
Versionbits (BIP9) está se aproximando da maturidade e permitirá que a rede Bitcoin tenha vários soft-forks em voo. Até agora, tivemos que serializar completamente o trabalho do soft-fork e também não tínhamos uma maneira real de lidar com um soft-fork que foi mesclado no núcleo, mas rejeitado pela rede. Tudo isso se resolve no BIP9, o que deverá nos permitir acelerar o ritmo das melhorias na rede. Parece que os versionbits estarão prontos para uso no próximo soft-fork realizado na rede.
A próxima coisa é que, no Scaling Bitcoin Hong Kong, Pieter Wuille apresentou como trazer o Segregated Witness para o Bitcoin. O que se propõe é um garfo macio isso aumenta a escalabilidade e a capacidade do Bitcoin, reorganizando os dados em blocos para lidar com as assinaturas separadamente e, ao fazer isso, os leva para fora do escopo do atual limite de tamanho de bloco.
A proposta específica equivale, na pior das hipóteses, a um aumento no tamanho do bloco de 4 MB. A separação permite novos modelos de segurança, como ignorar o download de dados que você não irá verificar e melhorar o desempenho para clientes lite (especialmente aqueles com alta privacidade). A proposta também inclui provas de fraude que tornam as violações do sistema Bitcoin comprováveis com uma prova compacta. Isso completa a visão de “alertas” descrita na seção “Verificação de pagamento simplificada” do white paper Bitcoin e tornaria possível que clientes leves aplicassem todas as regras do sistema (sob uma nova e forte suposição de que eles não são particionados). de alguém que geraria as provas). O design tem vários outros recursos, como tornar melhorias adicionais mais seguras e eliminar problemas de maleabilidade característicos. Se for amplamente utilizada, esta proposta proporciona um aumento de capacidade de 2x (mais se o multisig for amplamente utilizado), mas o mais importante é que torna essa capacidade adicional – e capacidade futura além dela – mais segura, aumentando a eficiência e permitindo mais compensações (em particular, você pode usar muito menos largura de banda em troca de uma forte suposição de não particionamento).
Existe uma implementação funcional (embora ainda não tenha provas de fraude) em https://github.com/sipa/bitcoin/commits/segwit.
(A palestra de Pieter está em: transcrição, diapositivos, Vídeo).
Tive bom sucesso ao implantar uma versão anterior (hard-fork) do segwit na cadeia lateral Elements Alpha; o segwit soft-fork agora proposto é um design de segunda geração. E acho que é bastante razoável implantar isso em um período de tempo relativamente curto. O design do segwit exige um futuro hardfork compatível com bitcoinj para aumentar ainda mais sua eficiência – mas não é necessário colher a maioria dos benefícios, e isso significa que isso pode acontecer de acordo com seu próprio cronograma e de maneira não controversa.
Indo além do segwit, tem havido alguma atividade considerável em torno de um relé de bloco mais eficiente. Há uma coleção de propostas, algumas decorrentes de um esboço informal meu inspirado no p2pool e algumas inventadas de forma independente, chamadas de “blocos fracos”, “blocos finos” ou “blocos suaves”. Essas propostas baseiam-se em técnicas de retransmissão eficientes (como o protocolo de rede de retransmissão ou IBLT) e movem praticamente todo o tempo de transmissão de um bloco antes que o bloco seja encontrado, eliminando o tamanho do cálculo da corrida órfã. Já precisamos desesperadamente disso com os tamanhos de bloco atuais. Estas ainda não foram implementadas, mas felizmente o caminho parece claro. Já vi pelo menos uma especificação mais ou menos completa e espero ver coisas funcionando usando isso em alguns meses. Esta ferramenta eliminará a latência de propagação de um problema na ausência de comportamento estratégico por parte dos mineradores. Compreender melhor o seu comportamento quando os mineiros se comportam estrategicamente é uma questão em aberto.
Ao mesmo tempo, há muita atividade em andamento relacionada a mecanismos de escalonamento “sem largura de banda”. Mecanismos de escalonamento sem largura de banda são ferramentas como canais de pagamento bidirecionais e de corte de transação que aumentam a capacidade e a velocidade do Bitcoin usando contratos inteligentes inteligentes em vez de maior largura de banda. De forma crítica, estas abordagens atingem directamente o cerne do compromisso entre capacidade e autotomia e podem permitir-nos alcançar uma capacidade muito elevada e uma descentralização muito elevada. O CLTV (BIP65), implantado há um mês e agora ativo na rede, é muito útil para essas técnicas (essenciais para fazer funcionar os reembolsos retidos); O CSV (BIP68/BIP112) está em fase de fusão no núcleo e está fazendo um bom progresso (e provavelmente estará pronto antes do segwit). Outras melhorias no protocolo Bitcoin para escalonamento sem largura de banda estão em andamento: muitas dessas propostas realmente querem soluções anti-maleabilidade (que seriam fornecidas pelo segwit), e há melhorias no sinalizador checksig já propostas e mais sendo trabalhadas, o que seria muito mais fácil de implantar com segwit. Espero que dentro de seis meses possamos ter consideravelmente mais recursos prontos para implantação para permitir essas técnicas. Mesmo sem eles, acredito que estaremos numa posição aceitável no que diz respeito à capacidade no curto prazo, mas é importante capacitá-los para o futuro.
http://diyhpl.us/wiki/transcripts/scalingbitcoin/hong-kong/overview-of-bips-necessary-for-lightning é uma palestra relevante sobre alguns dos recursos de rede desejados para o Lightning, uma proposta de canal de pagamento bidirecional na qual muitas partes estão trabalhando no momento; outras melhorias não relacionadas à largura de banda discutidas no passado incluem o corte de transações, que considero uma leitura obrigatória para a intuição básica sobre como a capacidade de transação pode ser maior que a capacidade do blockchain: https://bitcointalk.org/index.php?topic=281848.0embora existam muitos outros.)
Além disso, existem várias propostas relacionadas a limites flexíveis ou controles dinâmicos de tamanho de bloco alinhados a incentivos, com base em permitir que mineradores produzam blocos maiores a algum custo. Estas propostas ajudam a preservar o alinhamento de incentivos entre os mineiros e os operadores gerais de nós, e evitam que a deserção entre os mineiros prejudique o comportamento do mercado de taxas que acabará por financiar a segurança. Penso que neste momento a capacidade é suficientemente elevada e a capacidade necessária é suficientemente baixa para que não precisemos imediatamente destas propostas, mas elas serão extremamente importantes a longo prazo. Estou planejando ajudar e direcionar essas propostas para uma direção mais concreta nos próximos meses.
(As palestras relevantes incluem http://diyhpl.us/wiki/transcripts/scalingbitcoin/hong-kong/a-flexible-limit-trading-subsidy-for-larger-blocks/.
Finalmente – em algum momento, os aumentos de capacidade acima mencionados podem não ser suficientes. A entrega de melhorias de retransmissão, provas de fraude segwit, controles dinâmicos de tamanho de bloco e outros avanços na tecnologia reduzirão o risco e, portanto, a controvérsia em torno de propostas moderadas de aumento de tamanho de bloco (como 2/4/8 reescalonadas para respeitar o aumento do segwit). O Bitcoin será capaz de avançar com esses aumentos quando as melhorias e a compreensão tornarem seus riscos amplamente aceitáveis em relação aos riscos de não implementá-los. No Bitcoin Core devemos manter os patches prontos para implementá-los conforme a necessidade e a vontade surgir, para evitar que a engenharia básica de software seja o fator limitante.
Nosso progresso recente e atual posicionou bem o ecossistema Bitcoin para lidar com suas atuais necessidades de capacidade. Acho que o que foi dito acima estabelece alguns marcos claros e alcançáveis para continuar a avançar a arte na capacidade do Bitcoin, ao mesmo tempo que nos coloca em uma boa posição para melhorias e evolução adicionais.
DR: Proponho que trabalhemos imediatamente em direção ao soft-fork do bloco segwit de 4 MB, que aumenta a capacidade e escalabilidade, e acelerações recentes e melhorias de retransmissão de entrada tornam o segwit um risco razoável. O BIP9 e o segwit também tornarão outras melhorias mais fáceis e rápidas de implementar. Continuaremos a preparar o cenário para o escalonamento não baseado no aumento de largura de banda, enquanto construímos ferramentas adicionais que tornariam os aumentos de largura de banda mais seguros a longo prazo. Trabalhos futuros prepararão o Bitcoin para novos aumentos, que se tornarão possíveis quando justificados, ao mesmo tempo que fornecerão as bases para torná-los justificáveis.
Obrigado pelo seu tempo,
Postado originalmente na lista de discussão bitcoin-dev em https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-December/011865.htmlpor Gregory Maxwell em 07/12/2015
