*Este artigo foi escrito por Lucas de C. Ferreira, community manager da Ripio no Brasil e cofundador do Radar BTC.
O Bitcoin não está parado no tempo. Ao contrário de muitas altcoins que já tiveram seu desenvolvimento paralisado pelo bear market, o Bitcoin não está nem perto de ficar pronto.
(E ao mesmo tempo, ele está prontíssimo).
Ao contrário do que muitos pensam, a comunidade de desenvolvedores da criptomoeda não se conformou com o nível de escalabilidade, fungibilidade e privacidade do protocolo.
Diversas soluções estão sendo desenvolvidas e é de algumas delas que eu pretendo falar nesse artigo.
SegWit
O Segregated Witness já é um velho conhecido de quem acompanha o mercado. Trata-se de uma mudança na organização das informações dos blocos que coloca as assinaturas das transações separadas dos outros dados transacionais do bloco.
Além de isso permitir que os blocos contenham mais do que 1MB de informação (aumentando a capacidade de transações por bloco), corrige alguns problemas de maleabilidade no identificador das transações.
O SegWit facilita a adição de novas funcionalidades, layers 2 (segundas camadas) e o uso dos smart contracts do Bitcoin (já que torna a linguagem de script do Bitcoin mais fácil de ser atualizada).
Além disso, elimina algumas possibilidades de manipulação de transações que podiam ser utilizadas anteriormente em tentativas de fraudes.
A adoção do SegWit, no entanto, atingiu um nível muito abaixo do esperado. Segundo dados do OXT, pouco mais de 35% das transações de Bitcoin são formatadas utilizando as regras de SegWit.
Isso pode ser explicado por baixos incentivos ao uso, já que, no ano de 2018, as taxas de transação ficaram bem mais baixas e o benefício das transações menores usando SegWit não são tão relevantes.
Lightning Network
A Lightning Network (LN) também não é desconhecida dos entusiastas do criptomercado, já que o protocolo de pagamentos de segunda camada é há algum tempo alardeado como “a” solução para os problemas de escalabilidade do Bitcoin, utilizando uma rede de canais de pagamento bidirecionais
Os números de crescimento do uso da rede são animadores, já que em pouco menos de um ano, já são por volta de 2600 nodes com canais ativos e pouco mais de 18 mil canais.
Mas há um porém: apesar de a capacidade da rede estar beirando os 500 BTC, Larry Cermak mostrou em uma publicação no The Block (recomendadíssima) que 63,98% dessa capacidade se tornou disponível no início de novembro quando surgiram 20 nodes da LNBIG.com. E ninguém sabe quem está por trás da LNBIG.com. Isso vai na direção do que muitos críticos da LN apontavam — concentração da liquidez da rede em poucos players.
Outra preocupação muito frequente dos críticos é na taxa muito alta de falhas de roteamento das transações, como apontado em Junho passado pela Diar, principalmente para valores um pouco mais altos.
Mesmo na época, a resposta dos desenvolvedores foi de que o relatório da Diar era péssimo e que a Lightning estava em Beta. Portanto, os valores eram limitados propositalmente para garantir a segurança dos fundos dos usuários. Esses limites já têm sido gradativamente aumentados.
Além disso, uma série de melhorias técnicas estão no horizonte para melhorar o roteamento das transações, como:
- “Atomic Multi-Path Payments (AMP)” – permitem que pagamentos parciais caminhem por diferentes canais, melhorando a liquidez da rede;
- “Splicing” – permite que os usuários tirem ou adicionem saldo em seus canais sem a necessidade de fechar o canal e abrir novamente;
- eltoo e Channel Factories – uma espécie de “camada intermediária” entre onchain e lightning, vão facilitar a comunicação dos estados dos canais. Isso evita perda de fundos e permitirá que canais sejam abertos entre vários usuários com apenas duas transações onchain;
- entre outras coisas que são melhor descritas no ótimo texto do Arjun Balaji para o The Block ou no de Aaron Van Wirdum para a Bitcoin Magazine.
Schnorr Signatures
O Bitcoin utiliza um esquema de assinaturas conhecido como Elliptic Curve Digital Signature Algorithm (ECDSA). Existe um outro algoritmo conhecido como Schnorr, que entregaria ao Bitcoin:
- mais velocidade na verificação das assinaturas;
- maior fungibilidade,
- além de permitir multi-assinatura de forma nativa, agregando várias assinaturas em uma só.
Essa nova forma de agregar as assinaturas não só diminuiria o tamanho do input, como seria um incentivo a coinjoin, já que passaria a ser bastante vantajoso enviar em uma mesma transação bitcoins vindos de mais de um usuário direcionados a mais de um usuário.
Acreditava-se que “Schnorr Signatures” seriam muito difíceis de se implementar, pois demandariam um Hard Fork. No entanto, essa é uma das várias implementações que se tornaram possíveis via Soft Fork devido ao SegWit.
Em suas apostas para 2019, no Medium, Arjun Balaji diz que tem 75% de confiança de que as assinaturas Schnorr serão implementadas ainda esse ano. Se ele estiver correto, será uma ótima notícia para escalabilidade, fungibilidade e privacidade da blockchain do Bitcoin.
Dandelion
Todo mundo já aprendeu que o Bitcoin não é exatamente anônimo, não é? Pelo contrário, existem várias maneiras de rastrear de onde vieram as transações.
Uma delas é a seguinte: quando um node envia uma transação, ele fica transmitindo essa transação para diversos outros nodes em busca de um minerador que inclua sua transação em um bloco. Muitas vezes esse processo de difusão acaba revelando o endereço IP daquele usuário.
É aí que entra a proposta conhecida como Dandelion: no lugar de o node transmitir a transação para vários nodes, ele envia para um outro node aleatório, que envia para outro e assim continua. Quando um node recebe a transação, joga um pequeno jogo de probabilidade para decidir se continua propagando para um node aleatório (90% de chance de continuar) ou se finalmente transmite para a rede (difusão).
Quando finalmente algum node transmite a transação, todos os outros nodes pelos quais a transação passou percebem isso e transmitem ao mesmo tempo. Assim, a dificuldade de traçar de onde veio a transação fica muito maior.
Mais uma ótima implementação que trará mais privacidade ao Bitcoin!
MAST
O Bitcoin, em todas as suas transações, utiliza scripts que definem como os bitcoins podem ser gastos. Qualquer transação possui pelo menos uma dessas condições. Uma transação simples determina que os bitcoins poderão ser gastos desde que assinados por quem os está recebendo.
Existem ainda transações mais complexas, como as que utilizam timelock (impede o gasto daqueles bitcoins por um tempo determinado) ou multisig (requerem mais de uma assinatura para que uma transação seja feita).
Além disso, pode-se também mesclar mais de uma condicionante, fazendo com que uma transação que só poderia ser assinada com duas-de-três chaves possa ser assinada com apenas uma, caso tenham se passado 5 anos, por exemplo.
Esses tipos de transações possuem dois problemas: tamanho da transação e privacidade.
Ambos são resolvidos pela implementação chamada de MAST (Merkelized Abstract Syntax Tree). Com MAST, todas essas condicionantes são hasheadas individualmente e inseridas em uma árvore de Merkle, que também é então hasheada.
Assim, as condições da transação não são expostas por padrão. Também pode-se verificar que uma condição foi inserida na árvore de Merkle sem expor as outras condições.
Taproot
Ainda existe uma questão em relação ao MAST: todos sabem que uma transação complexa está sendo realizada. Mesclando os potenciais do MAST e assinaturas Schnorr, temos a Taproot.
Muitas vezes essas transações mais complexas incluem formas “cooperativas” de realizar a transação (quando, por exemplo, são necessárias as assinaturas de três diferentes pessoas) e incluem uma alternativa ‘não-cooperativa’, isso é, quando um dos participantes da transação quebra a confiança entre as partes se recusando a assinar.
Com Taproot, ninguém fica sabendo que aquela transação não era como outra qualquer e apenas é revelado que ela era mais complexa caso tenha que ser realizada da forma ‘não-cooperativa’.
Só estamos começando
Há diversas outras melhorias sendo desenvolvidas, como:
Covenants, que vão possibilitar maior complexidade nos scripts, viabilizando novos instrumentos financeiros e casos de uso;
Bulletproofs, para privacidade.
Além dessas, diversas implementações vão tornar os light nodes (não full-nodes) mais leves, seguros, eficientes.
Isso tudo sem falar nas sidechains, como RSK, Liquid e Drivechain.
Elas ainda são bastante embrionárias e dependem de alguns recursos pouco “descentralizados”, como a confiança em grandes federações.
RSK, por exemplo, possui seu token Super Bitcoin com uma “peg” 1:1, mas depende de federações.
De qualquer maneira, esse é justamente um ponto que os defensores do Bitcoin apontam como um trunfo: a camada base do protocolo se mantém conservadora e modificações são feitas com muito cuidado, enquanto experiências mais arrojadas são feitas nas sidechains e layer 2 solutions. A Lightning Network, por exemplo, pode dar errado e isso não afetará a blockchain.
O desenvolvimento de todas essas aplicações é mais lento do que alguns de nós gostaríamos, já que não é trivial.
O grupo core de desenvolvedores do Bitcoin é bastante reticente em realizar hard forks e procura formas de implementar as soluções que sejam compatíveis com versões anteriores.
Existem desenvolvedores trabalhando no código de todas essas features (a Blockstream, essa semana, adicionou o código referente a Schnorr em sua biblioteca para testes) e todas elas possuem uma aceitação relativamente alta entre os desenvolvedores.
Resta saber se encontrarão maior resistência quando próximas de serem implementadas.
Clique aqui e siga o Portal do Bitcoin no Instagram
