Expansão fora da cadeia: análise profunda

1. A necessidade de escalabilidade

A visão futura da blockchain é a descentralização, a segurança e a escalabilidade, mas geralmente apenas dois desses objetivos podem ser alcançados, o que é conhecido como o problema do triângulo impossível. Ao longo dos anos, as pessoas têm explorado como aumentar a capacidade de processamento e a velocidade das transações da blockchain, garantindo ao mesmo tempo a descentralização e a segurança, ou seja, resolver o problema da escalabilidade, que é um dos tópicos quentes no processo de desenvolvimento atual da blockchain.

Definição de descentralização, segurança e escalabilidade da blockchain:

• Descentralização: qualquer pessoa pode se tornar um nó para participar da produção e verificação do sistema; quanto maior o número de nós, maior o grau de descentralização, garantindo que a rede não seja controlada por um pequeno número de grandes participantes centralizados.

• Segurança: Quanto maior o custo para obter controle sobre o sistema, maior a segurança, a cadeia pode resistir a ataques de uma proporção maior de participantes.

• Escalabilidade: a capacidade da blockchain de processar um grande número de transações.

A primeira grande bifurcação do rede Bitcoin originou-se de questões de escalabilidade. Com o aumento do número de usuários e volume de transações, a rede Bitcoin, com um limite de 1MB por bloco, começou a enfrentar problemas de congestionamento; a partir de 2015, a comunidade Bitcoin começou a ter divergências sobre a questão da escalabilidade, com uma parte a apoiar a ampliação do bloco e a outra a acreditar que deveria ser utilizada a solução Segwit para otimizar a estrutura da cadeia principal. Em 1 de agosto de 2017, o Bitcoin ABC, que apoia a ampliação do bloco, lançou um sistema cliente de 8MB, resultando na primeira grande bifurcação da história do Bitcoin, dando origem à nova moeda BCH.

A rede Ethereum também opta por sacrificar parte da escalabilidade para garantir a segurança e a descentralização da rede. Embora a rede Ethereum não limite o volume de transações como a rede Bitcoin, restringindo o tamanho dos blocos, ela, de certa forma, converte isso em um limite para as taxas de combustível que um único bloco pode acomodar, mas o objetivo é o mesmo: alcançar o Consenso Sem Confiança e garantir uma ampla distribuição de nós.

Desde os CryptoKitties de 2017, passando pelo verão DeFi, até o surgimento posterior de aplicações on-chain como GameFi e NFT, a demanda do mercado por capacidade de processamento tem aumentado continuamente, mas mesmo a Ethereum, que é Turing completa, consegue processar apenas 15 a 45 transações por segundo (TPS), resultando em um aumento nos custos de transação e um prolongamento dos tempos de liquidação, tornando a operação de grande parte dos Dapps insustentável. Toda a rede se tornou lenta e cara para os usuários, e o problema da escalabilidade da blockchain precisa ser resolvido com urgência. A solução ideal de escalabilidade é: aumentar a velocidade das transações e a capacidade de processamento da rede o máximo possível, sem sacrificar a descentralização e a segurança.

2. Tipos de planos de escalabilidade

Nós dividimos as soluções de escalabilidade em duas grandes categorias, a escalabilidade em cadeia e a escalabilidade fora da cadeia, com base no critério "se altera um nível da rede principal".

2.1 expansão na cadeia

Conceito central: uma solução que atinge um efeito de escalabilidade através da alteração de uma camada do protocolo da mainnet, sendo a principal solução atual a fragmentação.

A escalabilidade na cadeia tem várias soluções, este artigo não se aprofundará, abaixo estão brevemente enumeradas duas soluções:

• A opção um é expandir o espaço do bloco, ou seja, aumentar o número de transações empacotadas em cada bloco, mas isso aumentará os requisitos para dispositivos de nós de alto desempenho, elevará a barreira de entrada para os nós e reduzirá o grau de "descentralização".

• A segunda opção é o sharding, dividindo o livro-razão da blockchain em várias partes, onde não é mais cada nó a participar de todos os registos, mas sim diferentes shards, ou seja, diferentes nós responsáveis por registos distintos, permitindo que o cálculo em paralelo possa processar múltiplas transações simultaneamente; isso pode reduzir a pressão computacional sobre os nós e o limiar de entrada, aumentando a velocidade de processamento de transações e o grau de descentralização; porém, isso significa que a potência computacional da rede é dispersa, o que pode reduzir a "segurança" de toda a rede.

Alterar o código do protocolo principal da rede pode ter efeitos negativos imprevisíveis, uma vez que qualquer pequena vulnerabilidade de segurança subjacente pode ameaçar gravemente a segurança de toda a rede. A rede pode ser forçada a bifurcar ou interromper a atualização de reparo. Por exemplo, o incidente de vulnerabilidade de inflação do Zcash em 2018: o código do Zcash é baseado na modificação do código da versão 0.11.2 do Bitcoin. Em 2018, um engenheiro descobriu uma vulnerabilidade crítica no código subjacente, que permitia a emissão ilimitada de tokens, e a equipe levou 8 meses para corrigir secretamente o problema, divulgando o incidente apenas após a correção.

2.2 fora da cadeia expansão

Conceito central: solução de escalabilidade que não altera o protocolo da rede principal de camada um existente.

O plano de escalabilidade fora da cadeia pode ser subdividido em Layer2 e outras soluções:

3. Fora da cadeia expansão do plano

3.1 Canais de Estado

3.1.1 Resumo

Os canais de estado determinam que os utilizadores só precisam interagir com a rede principal quando o canal é aberto, fechado ou para resolver disputas, e que as interações entre utilizadores sejam realizadas fora da cadeia, a fim de reduzir o tempo e o custo financeiro das transações dos utilizadores, além de permitir que o número de transações não tenha limites.

Os canais de estado são protocolos P2P simples, adequados para "aplicações baseadas em turnos", como, por exemplo, um jogo de xadrez entre duas pessoas. Cada canal é gerido por um contrato inteligente multi-assinatura que opera na rede principal, e esse contrato controla os ativos depositados no canal, valida as atualizações de estado e arbitra disputas entre os participantes ( com base em provas de fraude que possuem assinatura e carimbo de data/hora ). Após a implementação do contrato na rede blockchain, os participantes depositam um montante de fundos e o bloqueiam; após a confirmação da assinatura de ambas as partes, o canal é oficialmente aberto. O canal permite transações sem limite de número entre os participantes fora da cadeia (, desde que o valor líquido das transferências não exceda o total de tokens depositados ). Os participantes se alternam enviando atualizações de estado um ao outro, aguardando a confirmação da assinatura da outra parte. Assim que a outra parte confirmar a assinatura, essa atualização de estado é considerada concluída. Normalmente, as atualizações de estado acordadas por ambas as partes não são enviadas para a rede principal; apenas em caso de disputa ou fechamento do canal, é que se recorre à confirmação da rede principal. Quando é necessário fechar o canal, qualquer um dos participantes pode fazer um pedido de transação na rede principal; se o pedido de saída receber aprovação unânime de assinatura, ele é executado imediatamente na cadeia, ou seja, o contrato inteligente distribui os fundos restantes bloqueados com base no saldo de cada participante no estado final do canal; se outros participantes não aprovarem a assinatura, todos devem aguardar o término do "período de desafio" para receber os fundos restantes.

Em suma, a solução de canais de estado pode reduzir significativamente a carga computacional na rede principal, aumentar a velocidade das transações e diminuir os custos das transações.

3.1.2 Linha do tempo

• 2015/02, Joseph Poon e Thaddeus Dryja publicaram o rascunho do white paper da Lightning Network.
• 2015/11, Jeff Coleman fez a primeira síntese sistemática do conceito de State Channel, propondo que o Payment Channel do Bitcoin é um subcaso do conceito de State Channel.
• 2016/01, Joseph Poon e Thaddeus Dryja publicaram oficialmente o white paper "The Bitcoin Lightning Network: Scalable Off-Chain Instant Payments" propondo a solução de escalabilidade do Bitcoin Lightning Network Payment Channel( canal de pagamento), que é utilizado apenas para processar pagamentos de transferências na rede Bitcoin.
• 2017/11, a primeira especificação de design sobre State Channel baseada no framework Payment Channel, chamada Sprites, foi proposta.
• 2018/06, Counterfactual apresentou um design de Canais de Estado Generalizados muito detalhado, sendo este o primeiro design completamente relacionado a canais de estado.
• 2018/10, o artigo Generalised State Channel Networks apresenta os conceitos de State Channel Networks e Virtual Channels.
• 2019/02, o conceito de canais de estado foi expandido para canais N-Partido, Nitro é o primeiro protocolo construído com base nessa ideia.
• Em 2019/10, Pisa expandiu o conceito de Torres de Vigia para atender à necessidade de todos os participantes estarem constantemente online.
• 2020/03, Hydra apresentou Canais Isomórficos Rápidos.

3.1.3 Princípios Técnicos

A figura 1 mostra o fluxo de trabalho tradicional na cadeia: Alice e Bob interagem com o contrato inteligente implantado na rede principal, e os usuários alteram o estado do contrato inteligente enviando transações para a cadeia. A desvantagem é que isso traz os problemas de tempo e custo discutidos acima.

A figura 2 mostra o fluxo de trabalho geral que a maioria dos protocolos de canais de estado segue: em uma situação otimista, Alice e Bob precisam executar a mesma operação que antes, mas desta vez eles usam um canal de estado, em vez de interagir com um contrato na cadeia.

• Primeiro passo, Alice e Bob interagem com o endereço do contrato em cadeia ( depositando fundos de suas EOA pessoais, 1,2), esses fundos são bloqueados no contrato até que o canal seja fechado, momento em que o saldo é devolvido ao usuário; após a confirmação das assinaturas, o canal de estado entre os dois é oficialmente aberto.
• Segundo passo, Alice e Bob podem teoricamente realizar um número ilimitado de transações fora da cadeia ( linha azul ) através do canal, os participantes comunicam-se mutuamente por meio de mensagens assinadas criptograficamente ( em vez de se comunicar com a rede blockchain ). Ambos os usuários precisam assinar cada transação para evitar o problema de gasto duplo. Através dessas mensagens, eles propõem atualizações de estado de suas contas e aceitam as atualizações de estado propostas pelo outro.
• Terceiro passo, se Alice quiser fechar o canal e encerrar a transação com Bob, Alice precisa enviar ao contrato o estado final de sua conta ( interação 3). Se Bob assinar e aprovar, o contrato irá liberar os fundos bloqueados de acordo com o estado final e retorná-los ao usuário correspondente ( interação 4,5). Se Bob não responder à assinatura, o contrato liberará os fundos bloqueados de volta ao usuário correspondente após o término do período de contestação.

A figura 3 mostra o fluxo de trabalho do canal de estado em um cenário pessimista: inicialmente, os dois participantes depositam fundos ( interação 1, 2), e então começam a trocar atualizações de estado ( linha azul pontilhada ). Suponha que em algum momento, Bob não responda à atualização de estado assinada enviada por Alice ( interação 3), nesse momento, Alice pode iniciar um desafio submetendo seu último estado válido ao contrato ( interação 4), que também contém a assinatura anterior de Bob, provando assim que a última transação foi aprovada por Bob e que o estado final foi confirmado por Bob. Em seguida, o contrato permite que Bob responda dentro de um determinado período, submetendo o próximo estado ao contrato; se Bob responder, os dois podem continuar a transacionar dentro do canal de estado; se Bob não responder dentro desse período, o contrato fecha automaticamente o canal de estado e devolve os fundos a Alice ( interação 5).

3.1.4 Vantagens e desvantagens

Vantagens:

• Alta escalabilidade: transações ilimitadas podem ser realizadas
• Baixa latência: transações concluídas instantaneamente
• Baixo custo: transações fora da cadeia têm praticamente nenhum custo
• Privacidade: transações fora da cadeia não serão registradas na cadeia principal
• Disponibilidade: mesmo que a cadeia principal tenha problemas, os canais de estado ainda podem ser utilizados.

Desvantagens:

• Bloquear fundos: ambas as partes precisam bloquear fundos
• Permanecer online: os participantes precisam estar continuamente online para monitorar o estado do canal
• Custo de criação de canal: A abertura de canal requer interação com a cadeia principal, o custo é alto
• Fechar o atraso: Fechar o canal requer esperar o período de contestação
• Contraparte limitada: o canal só pode negociar com uma contraparte fixa
• Não é adequado para uso em grande escala: não é amigável para o usuário comum

3.1.5 Aplicação

Rede Lightning do Bitcoin

Resumo:

A Lightning Network é um canal de pagamentos de baixo valor na rede Bitcoin, cuja evolução técnica global passou por: a construção de um canal de pagamento unidirecional usando 2/2 multisig, a adição de RSMC(Revocable Sequence Maturity Contract) que possibilitou a construção de um canal de pagamento bidirecional, e, posteriormente, a inclusão de HTLC(Hash Time Lock Contract) que expandiu o canal de pagamento para pagamentos em grupo, culminando na construção da rede de pagamentos, ou seja, a Lightning Network. Através de canais de pagamento de baixo valor fora da cadeia, e utilizando intermediários para formar uma rede de transações, é possível resolver o problema de escalabilidade da rede Bitcoin. O uso geral da Lightning Network segue o processo "depósito(estabelecer canal)→transação da Lightning Network(atualizar estado do canal)→reembolso/liqidação(encerrar canal)"; teoricamente, a Lightning Network pode processar um milhão de transações por segundo.

Linha do tempo:

• Em fevereiro de 2015, Joseph Poon e Thaddeus Dryja publicaram o rascunho do white paper da Lightning Network;
• Em janeiro de 2016, foi lançada a versão oficial do white paper e fundada a Lightning Labs;
• Em 15 de março de 2018, a Lightning Labs lançou a primeira versão da rede principal do Lightning Network, Lightning Network Daemon (LND) versão 0.4.
• No início de 2021, a capacidade pública da Lightning Network (TVL) era de apenas cerca de 40 milhões de dólares.