A visão futura da blockchain é a descentralização, segurança e escalabilidade, mas geralmente só é possível realizar duas dessas, o que é conhecido como o problema do triângulo impossível da blockchain. Ao longo dos anos, as pessoas têm explorado maneiras de resolver esse dilema, aumentando a taxa de transferência e a velocidade das transações da blockchain, garantindo a descentralização e a segurança, ou seja, resolver o problema da escalabilidade, que é um dos tópicos mais quentes no processo de desenvolvimento atual da blockchain.
A descentralização, a segurança e a escalabilidade da blockchain são definidas da seguinte forma:
Descentralização: qualquer pessoa pode se tornar um nó para participar da produção e validação do sistema blockchain, quanto maior o número de nós, maior o grau de descentralização, garantindo que a rede não seja controlada por participantes centralizados.
Segurança: Quanto maior o custo necessário para obter o controle do sistema de blockchain, maior a segurança, a cadeia pode resistir a ataques de uma maior proporção de participantes.
Escalabilidade: a capacidade da blockchain de processar um grande número de transações.
A primeira grande bifurcação do network Bitcoin resultou de problemas de escalabilidade. Com o aumento do número de usuários e do volume de transações, a rede Bitcoin, com um limite de 1MB por bloco, começou a enfrentar problemas de congestionamento. Desde 2015, a comunidade Bitcoin tem divergências sobre a questão da escalabilidade, com uma parte a apoiar a expansão do bloco e a outra a defender a otimização da estrutura da cadeia principal através da solução Segregated Witness. Em 1 de agosto de 2017, o sistema cliente desenvolvido pelo Bitcoin ABC, com blocos de 8MB, começou a operar, resultando na primeira grande bifurcação do Bitcoin, e assim nasceu a nova moeda BCH.
A rede Ethereum também optou por sacrificar uma parte da escalabilidade para garantir a segurança e a descentralização da rede. Embora não haja uma limitação do tamanho do bloco, como no Bitcoin, a quantidade de transações é limitada através da restrição das taxas de gás que um único bloco pode acomodar, com o objetivo de alcançar um Consenso Sem Confiança e garantir a ampla distribuição dos nós.
Desde os CryptoKitties de 2017, passando pelo verão DeFi, até o surgimento de aplicações na cadeia como GameFi e NFT, a demanda do mercado por capacidade de processamento tem aumentado constantemente. Mas mesmo o Ethereum, que é Turing completo, consegue processar apenas 15-45 transações por segundo, o que resulta em custos de transação mais altos e tempos de liquidação mais longos, tornando difícil para a maioria dos Dapps suportarem os custos operacionais, e toda a rede se torna lenta e cara para os usuários. O problema da escalabilidade da blockchain precisa ser resolvido urgentemente. A solução de escalabilidade ideal é: aumentar a velocidade de transação e a profundidade da rede blockchain o máximo possível, sem sacrificar a descentralização e a segurança.
2. Tipos de soluções de escalabilidade
De acordo com o padrão "se a camada principal da rede será alterada", as soluções de escalabilidade podem ser divididas em duas grandes categorias: escalabilidade em cadeia e escalabilidade fora da cadeia.
2.1 expansão na cadeia
Conceito central: uma solução para aumentar a capacidade, mudando um nível do protocolo da mainnet, sendo a principal solução atualmente a fragmentação.
A expansão em cadeia tem várias soluções, listando brevemente duas:
A opção um é expandir o espaço do bloco, aumentando o número de transações empacotadas em cada bloco, mas isso aumentará os requisitos para dispositivos de nós de alto desempenho, reduzindo o grau de "descentralização".
A opção dois é a fragmentação, que divide o livro-razão da blockchain em várias partes, onde diferentes nós são responsáveis por diferentes registros, e o cálculo paralelo pode processar várias transações ao mesmo tempo. Isso pode reduzir a pressão de cálculo nos nós e o limiar de entrada, aumentar a velocidade de processamento das transações e o grau de descentralização, mas reduzirá a "segurança" de toda a rede.
Alterar o código de um protocolo de rede principal pode causar efeitos negativos imprevisíveis, pois qualquer pequena vulnerabilidade de segurança na camada subjacente pode ameaçar seriamente a segurança de toda a rede, que pode ser forçada a realizar um fork ou a interromper atualizações de reparo. Por exemplo, o incidente da vulnerabilidade de inflação da Zcash em 2018: o código da Zcash é baseado no código modificado da versão 0.11.2 do Bitcoin, e em 2018 um engenheiro descobriu uma vulnerabilidade crítica no código subjacente, permitindo que os tokens fossem emitidos sem limites. A equipe levou 8 meses para corrigir isso em segredo, e o incidente só foi tornado público após a correção da vulnerabilidade.
2.2 fora da cadeia expansão
Conceito central: solução de escalabilidade que não altera o protocolo da camada principal existente.
O plano de escalabilidade fora da cadeia pode ser subdividido em Layer2 e outras soluções:
Layer2: construir novas camadas sobre a cadeia principal, processar a maior parte das transações e cálculos, interagir com a cadeia principal apenas quando necessário. Inclui canais de estado, cadeias laterais, Plasma, Rollups, etc.
Outras soluções: não construir uma nova camada, mas sim implementar a escalabilidade através de outras técnicas. Como Validium, Volition, etc.
3. Profundidade de soluções para expansão fora da cadeia
Canais de Estado 3.1
3.1.1 Resumo
Os canais de estado estipulam que os usuários só precisam interagir com a rede principal ao abrir, fechar ou resolver disputas no canal, realizando as interações entre usuários fora da cadeia, a fim de reduzir o tempo e o custo das transações, e permitindo que o número de transações não seja limitado.
Os canais de estado são protocolos P2P simples, adequados para "aplicações baseadas em turnos", como um jogo de xadrez entre duas pessoas. Cada canal é gerido por um contrato inteligente de múltiplas assinaturas que opera na rede principal, que 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 contêm assinaturas e carimbos de tempo. Após o contrato ser implantado na rede blockchain, os participantes depositam um montante e o bloqueiam; após a confirmação com a assinatura de ambas as partes, o canal é oficialmente aberto. O canal permite transações gratuitas fora da cadeia entre os participantes sem limites de número (, desde que o valor líquido das transferências não exceda o total de tokens depositados ). Os participantes alternam o envio de atualizações de estado um ao outro, aguardando a confirmação da assinatura do outro. Uma vez que a outra parte confirma com a assinatura, a 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 ao fechar o canal, é que se recorre à confirmação da rede principal. Quando é necessário fechar o canal, qualquer participante pode fazer um pedido de transação na rede principal; se o pedido de saída receber a aprovação unânime de todos os participantes, a execução na cadeia ocorre imediatamente, ou seja, o contrato inteligente distribui os fundos bloqueados restantes de acordo com o saldo de cada participante no estado final do canal; se outros participantes não aprovarem com assinatura, todos devem aguardar o término do "período de contestação" para receber os fundos restantes.
Em suma, o esquema 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 rede Lightning.
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 o esquema de escalabilidade da rede Lightning do Bitcoin, Payment Channel ( canal de pagamento ), que é utilizado apenas para processar transferências de pagamento na rede Bitcoin.
2017/11, a primeira especificação de design sobre State Channel baseada na estrutura de Payment Channel, Sprites, foi proposta.
2018/06, a Counterfactual apresentou um design de Canais de Estado Generalizados muito detalhado, sendo este o primeiro design totalmente relacionado a canais de estado.
2018/10, o artigo Generalised State Channel Networks introduziu 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 baseado nessa ideia.
2019/10, Pisa para resolver o problema de todos os participantes precisarem estar online continuamente, expandiu o conceito de Watchtowers.
2020/03, a Hydra propôs 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 de antes, mas desta vez eles usam um canal de estado, em vez de interagir com o contrato na cadeia.
Primeiro passo, Alice e Bob interagem depositando fundos do EOA pessoal para o endereço do contrato em cadeia (, 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 da assinatura, o canal de estado entre os dois é oficialmente aberto.
O segundo passo, Alice e Bob podem teoricamente realizar um número ilimitado de transações fora da cadeia ( linha azul pontilhada ), os participantes comunicam-se entre si através de mensagens assinadas criptograficamente ( em vez de se comunicarem com a rede blockchain ). Ambos os usuários precisam assinar cada transação para evitar fraudes 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 terminar a transação com Bob, Alice precisa enviar o estado final da sua conta ( para o contrato, interagindo 3). Se Bob assinar e aprovar, o contrato liberará os fundos bloqueados de acordo com o estado final e os retornará ao usuário correspondente (, interagindo 4,5). Se Bob não responder com a 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 uma situação pessimista: inicialmente, dois participantes depositam fundos ( interação 1, 2), e então começam a trocar atualizações de estado ( linha pontilhada azul ). Suponha que em algum momento, Bob não responda à atualização de estado assinada enviada por Alice ( interação 3), neste ponto, Alice pode iniciar um desafio ao submeter ao contrato seu último estado válido ( interação 4), que também contém a assinatura anterior de Bob, provando que a última transação foi aprovada por Bob e que o estado final foi confirmado por Bob. Então, o contrato permite que Bob responda por um período de tempo submetendo o próximo estado ao contrato; se Bob responder, os dois podem continuar a negociar no 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:
Confirmação instantânea da transação
Alta capacidade de processamento
Baixos custos de transação
Boa privacidade
Desvantagens:
É necessário bloquear fundos
É necessário que todos os participantes estejam online em tempo real
A retirada tem atraso
O custo de inicialização do canal é alto
Reabrir o canal é um incômodo
A complexidade da rede de canais é alta
3.1.5 Aplicação
Rede Lightning do Bitcoin
Resumo:
A Lightning Network é um canal de pagamento de baixo valor na rede Bitcoin, cuja evolução técnica geral passou por: a construção de canais de pagamento unidirecionais com multi-assinaturas 2/2, a adição de RSMC(Revocable Sequence Maturity Contract) permitindo a construção de canais de pagamento bidirecionais, e depois a adição de HTLC(Hash Time Lock Contract) que expande os canais de pagamento para pagamentos em grupo, culminando na construção da rede de pagamento, que é a Lightning Network. Através de canais de pagamento de baixo valor fora da cadeia, e utilizando intermediários, é possível formar uma rede de transações que resolve o problema de escalabilidade da rede Bitcoin. O uso geral da Lightning Network segue o fluxo "depósito(estabelecer canal)→transação na Lightning Network(atualizar estado do canal)→reembolso/liquidaçã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;
A versão oficial do white paper foi lançada em janeiro de 2016 e a Lightning Labs foi fundada;
Em 15 de março de 2018, a Lightning Labs lançou a primeira versão principal da rede Lightning, o 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, com cerca de 100 mil usuários a utilizar a Lightning Network.
Em junho de 2021, El Salvador anunciou que adotaria o bitcoin como moeda de curso legal,
Ver original
Esta página pode conter conteúdo de terceiros, que é fornecido apenas para fins informativos (não para representações/garantias) e não deve ser considerada como um endosso de suas opiniões pela Gate nem como aconselhamento financeiro ou profissional. Consulte a Isenção de responsabilidade para obter detalhes.
17 Curtidas
Recompensa
17
5
Repostar
Compartilhar
Comentário
0/400
LiquidationSurvivor
· 9h atrás
o triângulo da morte que já foi muito debatido
Ver originalResponder0
GateUser-00be86fc
· 9h atrás
Escolher dois entre três é realmente mortal.
Ver originalResponder0
GateUser-bd883c58
· 9h atrás
Um verdadeiro enigma triangular, que nunca pode ser resolvido.
Análise da solução de escalabilidade fora da cadeia: Princípios e aplicações da tecnologia do canal estatal
Explicação Profunda da Expansão fora da cadeia
1. A necessidade de escalabilidade
A visão futura da blockchain é a descentralização, segurança e escalabilidade, mas geralmente só é possível realizar duas dessas, o que é conhecido como o problema do triângulo impossível da blockchain. Ao longo dos anos, as pessoas têm explorado maneiras de resolver esse dilema, aumentando a taxa de transferência e a velocidade das transações da blockchain, garantindo a descentralização e a segurança, ou seja, resolver o problema da escalabilidade, que é um dos tópicos mais quentes no processo de desenvolvimento atual da blockchain.
A descentralização, a segurança e a escalabilidade da blockchain são definidas da seguinte forma:
Descentralização: qualquer pessoa pode se tornar um nó para participar da produção e validação do sistema blockchain, quanto maior o número de nós, maior o grau de descentralização, garantindo que a rede não seja controlada por participantes centralizados.
Segurança: Quanto maior o custo necessário para obter o controle do sistema de blockchain, maior a segurança, a cadeia pode resistir a ataques de uma maior proporção de participantes.
Escalabilidade: a capacidade da blockchain de processar um grande número de transações.
A primeira grande bifurcação do network Bitcoin resultou de problemas de escalabilidade. Com o aumento do número de usuários e do volume de transações, a rede Bitcoin, com um limite de 1MB por bloco, começou a enfrentar problemas de congestionamento. Desde 2015, a comunidade Bitcoin tem divergências sobre a questão da escalabilidade, com uma parte a apoiar a expansão do bloco e a outra a defender a otimização da estrutura da cadeia principal através da solução Segregated Witness. Em 1 de agosto de 2017, o sistema cliente desenvolvido pelo Bitcoin ABC, com blocos de 8MB, começou a operar, resultando na primeira grande bifurcação do Bitcoin, e assim nasceu a nova moeda BCH.
A rede Ethereum também optou por sacrificar uma parte da escalabilidade para garantir a segurança e a descentralização da rede. Embora não haja uma limitação do tamanho do bloco, como no Bitcoin, a quantidade de transações é limitada através da restrição das taxas de gás que um único bloco pode acomodar, com o objetivo de alcançar um Consenso Sem Confiança e garantir a ampla distribuição dos nós.
Desde os CryptoKitties de 2017, passando pelo verão DeFi, até o surgimento de aplicações na cadeia como GameFi e NFT, a demanda do mercado por capacidade de processamento tem aumentado constantemente. Mas mesmo o Ethereum, que é Turing completo, consegue processar apenas 15-45 transações por segundo, o que resulta em custos de transação mais altos e tempos de liquidação mais longos, tornando difícil para a maioria dos Dapps suportarem os custos operacionais, e toda a rede se torna lenta e cara para os usuários. O problema da escalabilidade da blockchain precisa ser resolvido urgentemente. A solução de escalabilidade ideal é: aumentar a velocidade de transação e a profundidade da rede blockchain o máximo possível, sem sacrificar a descentralização e a segurança.
2. Tipos de soluções de escalabilidade
De acordo com o padrão "se a camada principal da rede será alterada", as soluções de escalabilidade podem ser divididas em duas grandes categorias: escalabilidade em cadeia e escalabilidade fora da cadeia.
2.1 expansão na cadeia
Conceito central: uma solução para aumentar a capacidade, mudando um nível do protocolo da mainnet, sendo a principal solução atualmente a fragmentação.
A expansão em cadeia tem várias soluções, listando brevemente duas:
A opção um é expandir o espaço do bloco, aumentando o número de transações empacotadas em cada bloco, mas isso aumentará os requisitos para dispositivos de nós de alto desempenho, reduzindo o grau de "descentralização".
A opção dois é a fragmentação, que divide o livro-razão da blockchain em várias partes, onde diferentes nós são responsáveis por diferentes registros, e o cálculo paralelo pode processar várias transações ao mesmo tempo. Isso pode reduzir a pressão de cálculo nos nós e o limiar de entrada, aumentar a velocidade de processamento das transações e o grau de descentralização, mas reduzirá a "segurança" de toda a rede.
Alterar o código de um protocolo de rede principal pode causar efeitos negativos imprevisíveis, pois qualquer pequena vulnerabilidade de segurança na camada subjacente pode ameaçar seriamente a segurança de toda a rede, que pode ser forçada a realizar um fork ou a interromper atualizações de reparo. Por exemplo, o incidente da vulnerabilidade de inflação da Zcash em 2018: o código da Zcash é baseado no código modificado da versão 0.11.2 do Bitcoin, e em 2018 um engenheiro descobriu uma vulnerabilidade crítica no código subjacente, permitindo que os tokens fossem emitidos sem limites. A equipe levou 8 meses para corrigir isso em segredo, e o incidente só foi tornado público após a correção da vulnerabilidade.
2.2 fora da cadeia expansão
Conceito central: solução de escalabilidade que não altera o protocolo da camada principal existente.
O plano de escalabilidade fora da cadeia pode ser subdividido em Layer2 e outras soluções:
Layer2: construir novas camadas sobre a cadeia principal, processar a maior parte das transações e cálculos, interagir com a cadeia principal apenas quando necessário. Inclui canais de estado, cadeias laterais, Plasma, Rollups, etc.
Outras soluções: não construir uma nova camada, mas sim implementar a escalabilidade através de outras técnicas. Como Validium, Volition, etc.
3. Profundidade de soluções para expansão fora da cadeia
Canais de Estado 3.1
3.1.1 Resumo
Os canais de estado estipulam que os usuários só precisam interagir com a rede principal ao abrir, fechar ou resolver disputas no canal, realizando as interações entre usuários fora da cadeia, a fim de reduzir o tempo e o custo das transações, e permitindo que o número de transações não seja limitado.
Os canais de estado são protocolos P2P simples, adequados para "aplicações baseadas em turnos", como um jogo de xadrez entre duas pessoas. Cada canal é gerido por um contrato inteligente de múltiplas assinaturas que opera na rede principal, que 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 contêm assinaturas e carimbos de tempo. Após o contrato ser implantado na rede blockchain, os participantes depositam um montante e o bloqueiam; após a confirmação com a assinatura de ambas as partes, o canal é oficialmente aberto. O canal permite transações gratuitas fora da cadeia entre os participantes sem limites de número (, desde que o valor líquido das transferências não exceda o total de tokens depositados ). Os participantes alternam o envio de atualizações de estado um ao outro, aguardando a confirmação da assinatura do outro. Uma vez que a outra parte confirma com a assinatura, a 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 ao fechar o canal, é que se recorre à confirmação da rede principal. Quando é necessário fechar o canal, qualquer participante pode fazer um pedido de transação na rede principal; se o pedido de saída receber a aprovação unânime de todos os participantes, a execução na cadeia ocorre imediatamente, ou seja, o contrato inteligente distribui os fundos bloqueados restantes de acordo com o saldo de cada participante no estado final do canal; se outros participantes não aprovarem com assinatura, todos devem aguardar o término do "período de contestação" para receber os fundos restantes.
Em suma, o esquema 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 rede Lightning.
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 o esquema de escalabilidade da rede Lightning do Bitcoin, Payment Channel ( canal de pagamento ), que é utilizado apenas para processar transferências de pagamento na rede Bitcoin.
2017/11, a primeira especificação de design sobre State Channel baseada na estrutura de Payment Channel, Sprites, foi proposta.
2018/06, a Counterfactual apresentou um design de Canais de Estado Generalizados muito detalhado, sendo este o primeiro design totalmente relacionado a canais de estado.
2018/10, o artigo Generalised State Channel Networks introduziu 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 baseado nessa ideia.
2019/10, Pisa para resolver o problema de todos os participantes precisarem estar online continuamente, expandiu o conceito de Watchtowers.
2020/03, a Hydra propôs 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 de antes, mas desta vez eles usam um canal de estado, em vez de interagir com o contrato na cadeia.
Primeiro passo, Alice e Bob interagem depositando fundos do EOA pessoal para o endereço do contrato em cadeia (, 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 da assinatura, o canal de estado entre os dois é oficialmente aberto.
O segundo passo, Alice e Bob podem teoricamente realizar um número ilimitado de transações fora da cadeia ( linha azul pontilhada ), os participantes comunicam-se entre si através de mensagens assinadas criptograficamente ( em vez de se comunicarem com a rede blockchain ). Ambos os usuários precisam assinar cada transação para evitar fraudes 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 terminar a transação com Bob, Alice precisa enviar o estado final da sua conta ( para o contrato, interagindo 3). Se Bob assinar e aprovar, o contrato liberará os fundos bloqueados de acordo com o estado final e os retornará ao usuário correspondente (, interagindo 4,5). Se Bob não responder com a 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 uma situação pessimista: inicialmente, dois participantes depositam fundos ( interação 1, 2), e então começam a trocar atualizações de estado ( linha pontilhada azul ). Suponha que em algum momento, Bob não responda à atualização de estado assinada enviada por Alice ( interação 3), neste ponto, Alice pode iniciar um desafio ao submeter ao contrato seu último estado válido ( interação 4), que também contém a assinatura anterior de Bob, provando que a última transação foi aprovada por Bob e que o estado final foi confirmado por Bob. Então, o contrato permite que Bob responda por um período de tempo submetendo o próximo estado ao contrato; se Bob responder, os dois podem continuar a negociar no 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:
Desvantagens:
3.1.5 Aplicação
Rede Lightning do Bitcoin
Resumo: A Lightning Network é um canal de pagamento de baixo valor na rede Bitcoin, cuja evolução técnica geral passou por: a construção de canais de pagamento unidirecionais com multi-assinaturas 2/2, a adição de RSMC(Revocable Sequence Maturity Contract) permitindo a construção de canais de pagamento bidirecionais, e depois a adição de HTLC(Hash Time Lock Contract) que expande os canais de pagamento para pagamentos em grupo, culminando na construção da rede de pagamento, que é a Lightning Network. Através de canais de pagamento de baixo valor fora da cadeia, e utilizando intermediários, é possível formar uma rede de transações que resolve o problema de escalabilidade da rede Bitcoin. O uso geral da Lightning Network segue o fluxo "depósito(estabelecer canal)→transação na Lightning Network(atualizar estado do canal)→reembolso/liquidação(encerrar canal)"; teoricamente, a Lightning Network pode processar um milhão de transações por segundo.
Linha do tempo: