Autor: Viktor Bunin, Coinbase Cloud Protocol Expert Compilador: Qianwen, ChainCatcher
Faz um tempo que não uso o Lightening (mais tarde chamado de "Rede Lightning").
A última vez que trabalhei nisso foi em 2019, quando me juntei a Elizabeth Stark e outros líderes comunitários para organizar a primeira Lightning Network Conference em Berlim. Desde então, passei a maior parte do tempo trabalhando em outros protocolos e, embora ainda seja amigo de pessoas como Elizabeth, meu entendimento de como a Lightning Network realmente funciona diminuiu. Depois de reexaminar, percebi que não era só eu, mas a maioria dos meus amigos também.
Este post é para aqueles que não usaram a Lightning Network recentemente. Ele discutirá equívocos que eu ou outros que vi. Se eu perdi algum ponto positivo, por favor, mande-me uma linha no Twitter.
**Equívoco 1: Você deve executar seu próprio nó para usar a Lightning Network sem custódia, o que impede que usuários comuns usem dispositivos móveis. **
Isso era verdade há alguns anos, mas agora os usuários podem usar a Lightning Network em dispositivos móveis por meio de clientes leves não gerenciados. Os usuários estão sempre no controle de suas chaves, e a experiência da carteira com o Lightning Light Client é a mesma que chamar Alchemy ou Infura via RPC ao usar Ethereum.
**Equívoco 2: O remetente e o destinatário devem estar online ao mesmo tempo para que os pagamentos Lightning sejam bem-sucedidos (sem pagamentos offline/síncronos). **
Essa situação ainda existe, mas com algumas soluções interessantes. As carteiras móveis Lightning sem custódia podem receber pagamentos por meio de tarefas em segundo plano ou notificações por telefone, mesmo quando a carteira não está sendo executada em primeiro plano. No entanto, essa abordagem é limitada pelos sistemas operacionais móveis. Os sistemas operacionais modernos limitam a quantidade de computação feita por aplicativos em segundo plano para economizar bateria. Receber alguns pagamentos do LN é bom, mas se muitos forem recebidos em um curto período de tempo, eles começarão a expirar devido a restrições computacionais.
A longo prazo, os desenvolvedores do protocolo Lightning Network estão trabalhando na especificação Async Payments, que permitirá latências sem confiança arbitrariamente longas. Essencialmente, o pagamento é creditado a partir do nó do remetente, mas se o nó do destinatário ficar offline, o pagamento fica no LSP do remetente (Lightning Network/Liquidity Service Provider, geralmente executado pela própria carteira), até que o destinatário volte a ficar online. ** Espera-se que essa atualização aconteça no próximo ano, mas ainda não há data oficial de lançamento. **No entanto, isso requer que as carteiras participantes contenham LSP, o que pode impedir sua adoção como uma solução em toda a rede.
**Equívoco 3: Lightning Network exige que ambos os usuários invistam a mesma quantidade de BTC no canal para abrir o canal. **
Isso não é verdade. Na maioria dos clientes da Lightning Network, o canal é aberto unidirecional por padrão, portanto, apenas o remetente precisa investir fundos no canal e o beneficiário pode ser um novo endereço vazio. Esse mal-entendido decorre do white paper da Lightning Network, onde os exemplos se referem consistentemente a canais de financiamento bidirecionais.
Na verdade, é baseado em uma história de fundo interessante. O canal de pagamento mais antigo (Spilman) permitia apenas pagamentos unidirecionais. A inovação da Rede Lightning está na realização de fundos duplos e pagamento bidirecional, sendo que o canal não possui prazo de vencimento. Talvez seja por isso que o artigo da Lightning Network se concentra tanto nisso. Esta foi uma invenção significativa em relação aos designs de protocolo conhecidos na época.
**Mito 4: A Lightning Network exige que os usuários especifiquem faturas específicas e de finalidade única, o que é uma péssima experiência para o usuário. **
Isso foi realmente verdade no começo. Mas agora com o endereço Lightning Network, é basicamente o ENS da Lightning Network. Eles são ativados por lnurl-pay, que permite aos usuários enviar BTC para viktor@example.com por meio da Lightning Network, independentemente do valor e da duração.
**Equívoco 5: Os usuários precisam entender e escolher Bitcoin e Lightning Network ao enviar BTC. **
Deve ter sido assim antes. Mas é diferente agora. Agora, eles têm um código QR unificado que agrupa perfeitamente o endereço on-chain com a fatura da Lightning Network para que a carteira de envio possa escolher a rota correta. Abra o CashApp, vá para a guia Bitcoin. Observe que, embora o Cash App suporte a Lightning Network, não há opção para selecionar a Lightning Network. Isso ocorre porque eles estão usando o código QR unificado.
No entanto, isso não resolve o problema de um único saldo - o saldo BTC de um usuário ainda pode ser dividido na cadeia e na Lightning Network. Esse problema pode ser resolvido até certo ponto por Submarineswap e/ou Splicing, mas minha visão de longo prazo é que os usuários nem perceberão que isso é um problema, nem perceberão que a Lightning Network existe porque a carteira e outros fornecedores lidam com as complexidades subjacentes que ficarão ocultas sob uma experiência de usuário suave.
**Mito nº 6: A Lightning Network é ineficiente em termos de capital e, portanto, não é viável. **
Essa discussão é delicada e tentarei ser o mais neutro possível.
A Lightning Network usa um modelo hub-and-spoke. A porção hub-to-hub da rede é altamente eficiente em termos de capital devido à alta taxa de “alocação de capital por unidade” de grandes canais entre trocas, carteiras de custódia, LSPs e nós de roteamento otimizados.
No entanto, onde a ineficiência de capital da rede Lightning está nas bordas - usuários sem custódia. Para usuários de Lightning de custódia, as carteiras precisam apenas manter grandes canais com outros hubs e realizar contabilidade interna dos saldos do usuário. Para usuários sem custódia, a carteira deve manter um canal de financiamento aberto separado com cada usuário. O desafio é como manter a alocação e gestão contínuas de liquidez nesses canais.
Para dar um exemplo concreto: um usuário de carteira sem custódia deseja enviar 0,1 BTC para um amigo por meio da Lightning Network. Supondo que haja liquidez suficiente no canal entre eles e o provedor de carteira e todos os nós ao longo do caminho, o pagamento será bem-sucedido. Mas agora a carteira está com um problema - eles têm 0,1 BTC no canal do lado deles, se o usuário não receber nenhum pagamento (assim reequilibrando o canal), esse 0,1 BTC ficará ocioso ali, causando baixa ineficiência do provedor da carteira. Nesse ponto, os provedores de carteira devem decidir se preservam a liquidez ou retiram a liquidez fechando canais (o que cria uma experiência ruim para o usuário) ou unindo canais (que são invisíveis para os usuários).
Para usuários não custodiais, esse problema de ineficiência de capital marginal é um problema de otimização muito irritante, que é objetivamente pior do que o modelo baseado em conta, independentemente do tamanho da transação. No entanto, este não é um problema insolúvel. Desde que não seja impossível, deve ser bem-sucedido, que também é o lema da comunidade de desenvolvedores Bitcoin.
Além da dificuldade de otimização de capital, outro desafio advém dos custos associados ao gerenciamento de canal e liquidez, pois cada emenda, fechamento de canal, etc. requer uma transação na cadeia. O orçamento de segurança do Bitcoin depende de um grande aumento nas taxas de transação, mas se as taxas de transação aumentarem para US$ 30 a US$ 60, o gerenciamento de canal será proibitivamente caro em escala e a Lightning Network sem custódia pode não estar disponível para uma grande parte da população mundial. As carteiras Lightning hospedadas atualmente têm uma vantagem devido aos incentivos incorporados e provavelmente crescerão ainda mais à medida que as taxas on-chain aumentarem, pois seu modelo de conta omnibus torna o gerenciamento de canal muito menos frequente. A comunidade está trabalhando duro para corrigir isso e garantir que as carteiras Lightning sem custódia continuem sendo cidadãs de primeira classe na rede, mas ainda não há uma solução clara.
A Lightning Network ainda tem um longo caminho a percorrer para ser simples, perfeita e completamente abstrata. Ainda existem muitos casos extremos e os usuários não gerenciados ainda não aproveitaram a melhor experiência do usuário. No entanto, muitos problemas já foram resolvidos e muitos mais serão resolvidos nos próximos anos. Agora que o raio chegou, o trovão pode estar muito longe?
Ver original
Esta página pode conter conteúdos de terceiros, que são fornecidos apenas para fins informativos (sem representações/garantias) e não devem ser considerados como uma aprovação dos seus pontos de vista pela Gate, nem como aconselhamento financeiro ou profissional. Consulte a Declaração de exoneração de responsabilidade para obter mais informações.
Esclarecendo 6 equívocos sobre a rede Lightning do Bitcoin
Autor: Viktor Bunin, Coinbase Cloud Protocol Expert Compilador: Qianwen, ChainCatcher
Faz um tempo que não uso o Lightening (mais tarde chamado de "Rede Lightning").
A última vez que trabalhei nisso foi em 2019, quando me juntei a Elizabeth Stark e outros líderes comunitários para organizar a primeira Lightning Network Conference em Berlim. Desde então, passei a maior parte do tempo trabalhando em outros protocolos e, embora ainda seja amigo de pessoas como Elizabeth, meu entendimento de como a Lightning Network realmente funciona diminuiu. Depois de reexaminar, percebi que não era só eu, mas a maioria dos meus amigos também.
Este post é para aqueles que não usaram a Lightning Network recentemente. Ele discutirá equívocos que eu ou outros que vi. Se eu perdi algum ponto positivo, por favor, mande-me uma linha no Twitter.
**Equívoco 1: Você deve executar seu próprio nó para usar a Lightning Network sem custódia, o que impede que usuários comuns usem dispositivos móveis. **
Isso era verdade há alguns anos, mas agora os usuários podem usar a Lightning Network em dispositivos móveis por meio de clientes leves não gerenciados. Os usuários estão sempre no controle de suas chaves, e a experiência da carteira com o Lightning Light Client é a mesma que chamar Alchemy ou Infura via RPC ao usar Ethereum.
**Equívoco 2: O remetente e o destinatário devem estar online ao mesmo tempo para que os pagamentos Lightning sejam bem-sucedidos (sem pagamentos offline/síncronos). **
Essa situação ainda existe, mas com algumas soluções interessantes. As carteiras móveis Lightning sem custódia podem receber pagamentos por meio de tarefas em segundo plano ou notificações por telefone, mesmo quando a carteira não está sendo executada em primeiro plano. No entanto, essa abordagem é limitada pelos sistemas operacionais móveis. Os sistemas operacionais modernos limitam a quantidade de computação feita por aplicativos em segundo plano para economizar bateria. Receber alguns pagamentos do LN é bom, mas se muitos forem recebidos em um curto período de tempo, eles começarão a expirar devido a restrições computacionais.
A longo prazo, os desenvolvedores do protocolo Lightning Network estão trabalhando na especificação Async Payments, que permitirá latências sem confiança arbitrariamente longas. Essencialmente, o pagamento é creditado a partir do nó do remetente, mas se o nó do destinatário ficar offline, o pagamento fica no LSP do remetente (Lightning Network/Liquidity Service Provider, geralmente executado pela própria carteira), até que o destinatário volte a ficar online. ** Espera-se que essa atualização aconteça no próximo ano, mas ainda não há data oficial de lançamento. **No entanto, isso requer que as carteiras participantes contenham LSP, o que pode impedir sua adoção como uma solução em toda a rede.
**Equívoco 3: Lightning Network exige que ambos os usuários invistam a mesma quantidade de BTC no canal para abrir o canal. **
Isso não é verdade. Na maioria dos clientes da Lightning Network, o canal é aberto unidirecional por padrão, portanto, apenas o remetente precisa investir fundos no canal e o beneficiário pode ser um novo endereço vazio. Esse mal-entendido decorre do white paper da Lightning Network, onde os exemplos se referem consistentemente a canais de financiamento bidirecionais.
Na verdade, é baseado em uma história de fundo interessante. O canal de pagamento mais antigo (Spilman) permitia apenas pagamentos unidirecionais. A inovação da Rede Lightning está na realização de fundos duplos e pagamento bidirecional, sendo que o canal não possui prazo de vencimento. Talvez seja por isso que o artigo da Lightning Network se concentra tanto nisso. Esta foi uma invenção significativa em relação aos designs de protocolo conhecidos na época.
**Mito 4: A Lightning Network exige que os usuários especifiquem faturas específicas e de finalidade única, o que é uma péssima experiência para o usuário. **
Isso foi realmente verdade no começo. Mas agora com o endereço Lightning Network, é basicamente o ENS da Lightning Network. Eles são ativados por lnurl-pay, que permite aos usuários enviar BTC para viktor@example.com por meio da Lightning Network, independentemente do valor e da duração.
**Equívoco 5: Os usuários precisam entender e escolher Bitcoin e Lightning Network ao enviar BTC. **
Deve ter sido assim antes. Mas é diferente agora. Agora, eles têm um código QR unificado que agrupa perfeitamente o endereço on-chain com a fatura da Lightning Network para que a carteira de envio possa escolher a rota correta. Abra o CashApp, vá para a guia Bitcoin. Observe que, embora o Cash App suporte a Lightning Network, não há opção para selecionar a Lightning Network. Isso ocorre porque eles estão usando o código QR unificado.
No entanto, isso não resolve o problema de um único saldo - o saldo BTC de um usuário ainda pode ser dividido na cadeia e na Lightning Network. Esse problema pode ser resolvido até certo ponto por Submarineswap e/ou Splicing, mas minha visão de longo prazo é que os usuários nem perceberão que isso é um problema, nem perceberão que a Lightning Network existe porque a carteira e outros fornecedores lidam com as complexidades subjacentes que ficarão ocultas sob uma experiência de usuário suave.
**Mito nº 6: A Lightning Network é ineficiente em termos de capital e, portanto, não é viável. **
Essa discussão é delicada e tentarei ser o mais neutro possível.
A Lightning Network usa um modelo hub-and-spoke. A porção hub-to-hub da rede é altamente eficiente em termos de capital devido à alta taxa de “alocação de capital por unidade” de grandes canais entre trocas, carteiras de custódia, LSPs e nós de roteamento otimizados.
No entanto, onde a ineficiência de capital da rede Lightning está nas bordas - usuários sem custódia. Para usuários de Lightning de custódia, as carteiras precisam apenas manter grandes canais com outros hubs e realizar contabilidade interna dos saldos do usuário. Para usuários sem custódia, a carteira deve manter um canal de financiamento aberto separado com cada usuário. O desafio é como manter a alocação e gestão contínuas de liquidez nesses canais.
Para dar um exemplo concreto: um usuário de carteira sem custódia deseja enviar 0,1 BTC para um amigo por meio da Lightning Network. Supondo que haja liquidez suficiente no canal entre eles e o provedor de carteira e todos os nós ao longo do caminho, o pagamento será bem-sucedido. Mas agora a carteira está com um problema - eles têm 0,1 BTC no canal do lado deles, se o usuário não receber nenhum pagamento (assim reequilibrando o canal), esse 0,1 BTC ficará ocioso ali, causando baixa ineficiência do provedor da carteira. Nesse ponto, os provedores de carteira devem decidir se preservam a liquidez ou retiram a liquidez fechando canais (o que cria uma experiência ruim para o usuário) ou unindo canais (que são invisíveis para os usuários).
Para usuários não custodiais, esse problema de ineficiência de capital marginal é um problema de otimização muito irritante, que é objetivamente pior do que o modelo baseado em conta, independentemente do tamanho da transação. No entanto, este não é um problema insolúvel. Desde que não seja impossível, deve ser bem-sucedido, que também é o lema da comunidade de desenvolvedores Bitcoin.
Além da dificuldade de otimização de capital, outro desafio advém dos custos associados ao gerenciamento de canal e liquidez, pois cada emenda, fechamento de canal, etc. requer uma transação na cadeia. O orçamento de segurança do Bitcoin depende de um grande aumento nas taxas de transação, mas se as taxas de transação aumentarem para US$ 30 a US$ 60, o gerenciamento de canal será proibitivamente caro em escala e a Lightning Network sem custódia pode não estar disponível para uma grande parte da população mundial. As carteiras Lightning hospedadas atualmente têm uma vantagem devido aos incentivos incorporados e provavelmente crescerão ainda mais à medida que as taxas on-chain aumentarem, pois seu modelo de conta omnibus torna o gerenciamento de canal muito menos frequente. A comunidade está trabalhando duro para corrigir isso e garantir que as carteiras Lightning sem custódia continuem sendo cidadãs de primeira classe na rede, mas ainda não há uma solução clara.
A Lightning Network ainda tem um longo caminho a percorrer para ser simples, perfeita e completamente abstrata. Ainda existem muitos casos extremos e os usuários não gerenciados ainda não aproveitaram a melhor experiência do usuário. No entanto, muitos problemas já foram resolvidos e muitos mais serão resolvidos nos próximos anos. Agora que o raio chegou, o trovão pode estar muito longe?