Core Lightning: Como a reformulação da marca de implementação da Blockstream fala sobre sua visão de longo prazo para Bitcoin PlatoBlockchain Data Intelligence. Pesquisa vertical. Ai.

Core Lightning: como a mudança de marca da implementação da Blockstream fala com sua visão de longo prazo para o Bitcoin

Agora chamada de Core Lightning, a implementação da Lightning Network da Blockstream busca ser o padrão interoperável e focado em especificações do Bitcoin.

A empresa de infraestrutura Bitcoin Blockstream recentemente renomeou sua implementação da Lightning Network de c-lightning para Core Lightning (CLN) em uma tentativa de destacar o foco de longo prazo do projeto na interoperabilidade e no trabalho de especificação.

O nome inicial, que aludiu à linguagem de programação C na qual a implementação está integrada, não refletia a real intenção da empresa com o projeto. Agora, o Core Lightning busca refletir a proposta de valor da implementação do Blockstream.

“Esperamos que o nome atualizado comunique melhor o foco da CLN na interoperabilidade, no trabalho de especificação e no objetivo contínuo de fornecer uma implementação de referência com prioridade na correção e robustez”, disse a empresa em um comunicado. afirmação.

Por que existem diferentes implementações da Lightning Network?

A Lightning Network é um conceito abstrato do que são, na verdade, muitos canais Lightning diferentes conectados entre si. Os canais de pagamento relâmpago estabelecem a base da rede à medida que dois participantes bloqueiam uma quantidade de bitcoin na camada base da rede Bitcoin para fazer pagamentos fora da cadeia rápidos e baratos entre si. No entanto, ao abrir mais canais com diferentes participantes, os pagamentos podem então ser roteados nesta “rede mesh”, de um participante para outro até que um destinatário final de um pagamento Lightning seja encontrado.

Portanto, a abstração que é “a rede Lightning”exige que diferentes participantes se comuniquem entre si para que possam encaminhar os pagamentos uns dos outros e permitir uma interação sem atrito. Essa comunicação acontece entre nós que executam o software do protocolo Lightning e, portanto, são capazes de enviar e receber pagamentos, entre outras coisas.

Considerando que no Bitcoin existe atualmente um software de nó padrão de fato, Bitcoin Core, há mais de um tipo de software de nó do Lightning que é popular atualmente. Como resultado, há necessidade de um conjunto de documentos para ditar como esses diferentes tipos de nós do Lightning — também conhecidos como “implementações” — podem se comunicar entre si.

A Documentos de base da tecnologia Lightning (BOLT) definir o conjunto de especificações que todas as implementações de nós do Lightning devem aderir para serem um participante estável e compatível na Lightning Network. Existem atualmente 11 documentos BOLT que descrevem tudo, desde como estabelecer um canal de pagamento e financiá-lo com bitcoin até como solicitar um pagamento Lightning.

Naturalmente, o fato de existirem diferentes implementações do Lightning também significa que existem diferentes ofertas disponíveis para os usuários, e eles podem escolher qualquer software para executar com base em suas necessidades específicas. Em um nível superior, existem quatro implementações principais do Lightning, LND, Core Lightning, Eclair e LDK, cada uma voltada para casos de uso específicos.

Core Lightning: Construído a partir do BOLT

CLN, anteriormente c-lightning, está em uso de produção na rede principal do Bitcoin desde o início de 2018. Escrito na linguagem de programação C, que oferece aos desenvolvedores um alto grau de controle sobre o comportamento de seu código, mesmo em um nível baixo, o CLN tem como foco na eficiência, bem como em fornecer aos desenvolvedores e usuários uma solução modular, baseado em plugin implementação do protocolo de escalonamento da Camada 2 do Bitcoin.

“Nosso objetivo é ser uma implementação de alto desempenho, de nível empresarial e compatível com as especificações”, disse o desenvolvedor Lightning da Blockstream, Rusty Russel. Bitcoin Magazine. “Isso tradicionalmente significa que somos mais para usuários de ponta, empresas e desenvolvedores desenvolverem.”

CLN só funciona no Linux e MacOS e requer uma conexão local ou remota bitcoind versão 0.16 ou superior que está totalmente compatível com a rede em que o usuário está executando e da qual retransmite transações. A poda é parcialmente suportado.

Por ser uma implementação leve, o CLN permite um grande nível de personalização, pois permite ao usuário personalizá-lo e adicionar apenas os recursos que deseja ou precisa. Os desenvolvedores podem interagir com o daemon por meio de métodos JSON-RPC personalizados, permitindo-lhes personalizar com eficiência a funcionalidade de acordo com suas necessidades por meio de plug-ins que podem acessar detalhes de baixo nível diretamente.

A modularidade, a eficiência e a robustez do código do CLN também trazem suas desvantagens. Christian Decker, pesquisador da Blockstream focado em dimensionar soluções para Bitcoin, dito durante o encontro Londres Bitcoin Devs no mês passado que, ao aderir à filosofia UNIX de fazer uma coisa muito bem e não forçar decisões sobre o usuário, o CLN vem de uma forma “básica” e requer alguma dedicação do usuário para fazê-lo funcionar .

Notavelmente, a implementação da Blockstream se concentra fortemente no processo de especificação e gera grande parte de seu código diretamente a partir das especificações BOLT, de acordo com Russel. Embora isso garanta uma implementação totalmente compatível com as especificações, a equipe fica com menos tempo para comercializar seu trabalho e identifica isso como o motivo pelo qual vê menos envolvimento da comunidade e compartilhamento de nós do que outras implementações.

“Somos construídos a partir das especificações do Lightning BOLT, literalmente!” Russell disse Bitcoin Magazine. “Isso significa que nos preocupamos muito (e, como equipe, nos esforçamos muito) em coordenar a arquitetura de toda a Lightning Network por meio das especificações BOLT.”

A equipe geralmente propõe uma nova especificação para a comunidade de desenvolvimento mais ampla antes de adicioná-la ao CLN, na tentativa de garantir compatibilidade de longo prazo entre diferentes implementações, enquanto solicita mais atenção para revisar, testar e comentar seu código antes que ele seja eventualmente transformado em um novo BOLT e fica pronto para ser adotado por todas as implementações.

“Parte da razão pela qual fazemos o processo de especificação e revisão entre implementações é que ele ajuda a identificar melhores maneiras de fazer as coisas – encontrar bugs, identificar problemas futuros”, disse Lisa Neigut, engenheira de protocolo Lightning da Blockstream. Bitcoin Magazine.

Dada a sua eficiência e leveza, o CLN é provavelmente a implementação mais adequada para dispositivos de baixa especificação.

A equipe da Blockstream também desenvolveu um conjunto de novos recursos que ampliam a funcionalidade atual dos BOLTs, que muitas vezes são especificações preliminares ou propostas de especificações, incluindo aberturas de canais colaborativos, anúncios de liquidez e BOLT 12. A CLN oferece ao usuário a opção de experimentar essas especificações futuras.

“Nós isolamos partes preliminares da especificação Lightning sob opções experimentais”, disse Russel Bitcoin Magazine. “Mas se você for mais aventureiro, essas opções experimentais lhe darão uma

uma visão sobre o que está por vir para a Lightning Network!”

Aberturas de canais colaborativos, anteriormente chamadas de “canais de financiamento duplos”, permitem que os participantes abram colaborativamente um novo canal, financiando conjuntamente a transação de financiamento do canal. Atualmente, os canais são abertos com operação de financiamento unilateral por um participante. As aberturas de canais colaborativos também permitem CoinJoins distribuídos em um canal Lightning aberto.

“Você pode orquestrar seu próprio CoinJoin com vários outros nós Lightning”, disse Neigut Bitcoin Magazine. “Você faz isso de forma descentralizada, de modo que as únicas pessoas que sabem quem está envolvido nisso são as pessoas que realmente fazem parte da transação, de modo que não há um coordenador central que faça isso acontecer.”

Anúncios de liquidez também aproveitam a abertura de canais colaborativos. De acordo com um Blockstream no blog, “são uma forma leve de fornecer a capacidade de coordenar a distribuição de liquidez em toda a rede de uma forma descentralizada e acessível”.

O recurso tenta resolver um problema comum no Lightning: liquidez de entrada.

Os anúncios de liquidez permitem que você “veja todas as pessoas que estão anunciando que venderão liquidez de entrada se você abrir um canal para elas, o que é realmente interessante”, disse Neigut.

PARAFUSO 12 é outro rascunho de especificação para carteiras e nós Lightning com suporte experimental em CLN. O recurso proposto, denominado “ofertas”, melhoraria as faturas do BOLT 11, permitindo ofertas reutilizáveis, enquanto uma fatura do BOLT 11 só pode ser usada uma vez. Além disso, embora uma fatura seja exclusivamente uma solicitação de pagamento, você pode usar uma oferta para também enviar, e não apenas receber, dinheiro.

Os usuários do CLN agora também podem automatizar suas tarefas de gerenciamento de nós com CLBOSS, uma ferramenta de “inteligência artificial” lançada recentemente que pode decidir para quais nós abrir canais, abrir canais quando as taxas são baixas e há fundos na rede, ajustar taxas de roteamento para ser competitivo com outros nós, realizar swaps submarinos por meio do boltz API .exchange e reequilibra automaticamente os canais.

Embora diferentes implementações devam ser incentivadas a buscar soluções independentes para seus casos de uso específicos, respeitando as especificações atuais do BOLT 11, apresentar uma proposta de especificações para ajudar outras implementações a implantar o mesmo recurso - ou semelhante - geralmente é uma boa prática, como tal uma mudança supostamente atende aos interesses de longo prazo da ampla e crescente base de usuários do Lightning. Dito isto, o processo de especificação não é uma tarefa fácil de suportar.

“Como processo é árduo e leva muito tempo. Requer coordenação com outras pessoas com muitas perspectivas diferentes”, disse Neigut.

Como resultado, diferentes empresas dedicam diferentes quantidades de tempo e esforço a este processo de acordo com as suas prioridades individuais, que naturalmente diferem. Embora, de acordo com Russel, a equipe CLN tenha gasto a maior parte de seu “esforço na especificação e nos detalhes de implementação de baixo nível e quase nenhum esforço na divulgação ou marketing do desenvolvedor”, a Lightning Labs, a empresa por trás do LND, muitas vezes optou por se concentrar mais recursos de engenharia em novos recursos e na solução dos problemas dos clientes do que no árduo processo de especificação.

LND: Lacunas que a CLN pode preencher?

LND é uma implementação Lightning pioneira no desenvolvedor que se concentra em facilitar o desenvolvimento de aplicativos, colocando assim forte ênfase na interação do desenvolvedor, particularmente em uma abordagem padrão de comunicação por meio de APIs REST, que permitem o desenvolvimento mais fácil de aplicativos, além de fornecer documentação clara e uma experiência de configuração fácil.

“Queremos que os desenvolvedores possam pegá-lo facilmente, integrá-lo em seus produtos, criar aplicativos sobre ele e distribuí-lo como uma carteira ou um nó auto-hospedado”, disse Oliver Gugger, desenvolvedor do LND. dito no encontro Londres Bitcoin Devs. “Trazendo isso para a plebe.”

Como resultado, o LND se concentra em “ter uma ótima interface de desenvolvedor”, acrescentou Gugger, habilitando gRPC e REST.

“O LND tem uma ótima comunidade, configuração fácil e ótima documentação para desenvolvedores”, disse Russel quando questionado por que achava que o LND é a implementação mais popular do Lightning.

A LND tem visto o maior envolvimento da comunidade entre todas as implementações e atualmente administra a maioria de todos os nós da rede. Algumas estimativas coloque a participação do LND no total de nós públicos do Lightning entre 70% e 90%.

A LND também possui o que é indiscutivelmente a maior equipe de desenvolvimento em tempo integral. Como resultado, a equipe conseguiu construir uma infinidade de serviços de valor agregado em torno da LND, como Abertura e os serviços de liquidez Lightning laço e Piscina.

Loop usa swaps submarinos para conectar bitcoins dentro e fora da cadeia, facilitando a movimentação de bitcoins para dentro e para fora da Lightning Network. Ele realiza balanceamento automatizado de canais, swaps sem custódia com privacidade, lotes de transações oportunistas com economia de taxas e monitoramento do progresso de swaps em voo.

Pool é um mercado peer-to-peer para canais Lightning. Ele conecta usuários que precisam de acesso à liquidez de entrada àqueles que têm capital para implantar na Lightning Network, permitindo que um participante da Lightning Network sinalize a necessidade dela e incentivando outros a abrir canais com eles usando seu capital.

Com o foco do LND normalmente em novos recursos e suporte ao cliente, a equipe da CLN encontrou uma lacuna no mercado que espera preencher prestando mais atenção ao processo de especificação.

Especificar ou não especificar

“A equipe do Labs criou ótimas coisas”, disse Neigut. “Eles simplesmente, como organização, não têm sido incríveis ao escrever especificações para as coisas que acrescentam. Um bom exemplo disso é o KeySend.”

Enviar chave permite que um nó Lightning envie a alguém um pagamento Lightning tendo apenas o ID do nó receptor, o que significa que a ferramenta não exige faturas, que são as atuais padrão de fato no mecanismo de pagamento do Lightning.

“Eles lançaram, muita gente começou a usar, mas nunca o especificou totalmente”, acrescentou Neigut. “Então a CLN queria poder apoiá-lo. Um dos membros da nossa equipe teve que voltar e descobrir como fazê-lo funcionar apenas lendo seu código e fazendo engenharia reversa.”

Uma especificação acabou sendo escrita pela implementação do Lightning da Spiral, LDK, lembrou Neigut, depois que sua equipe fez a engenharia reversa do código do Lightning Labs.

“E as outras equipes só tiveram que acompanhar porque a LND tem uma base instalada muito grande”, disse ela. “Esse não é o processo mais colaborativo.”

“A equipe de pessoas que trabalham nas coisas do Lightning Labs é bastante sólida”, acrescentou Neigut. “Eu só acho que eles estão aproveitando seu domínio de rede para não ter que fazer todo esse trabalho extra, porque se não fizerem isso, outra pessoa o fará, porque a maioria dos nós da rede executa seu código.”

Neigut disse que já está acostumada com o LND sendo o centro das atenções e sendo a implementação “padrão do Lightning” — algo que ela confessa que gosta como desenvolvedora por causa das menos demandas de suporte ao cliente que recebe.

“Mas acho que teríamos uma dinâmica de rede mais saudável se não houvesse uma implementação majoritária”, acrescentou ela. “Acho que isso realmente mudaria o jogo em termos da quantidade de colaboração que todos precisam fazer para que seus produtos sejam enviados no Lightning. E isso seria saudável.”

A atenção cuidadosa às especificações é indiscutivelmente central para o desenvolvimento de código aberto em um ambiente de rede aberta. No Lightning, tais especificações formam a base do protocolo e garantem a interoperabilidade das diferentes versões participantes da rede.

No entanto, enquanto alguns argumentam que grandes mudanças e novas adições a uma implementação do Lightning deveriam ter uma especificação de acompanhamento, outros podem ver as especificações do BOLT como um mínimo sobre o qual cada implementação pode construir seus próprios novos recursos interessantes - o que não necessariamente precisaria ser ser portado de volta para o conjunto de especificações.

"Está difícil criando uma empresa de infraestrutura de código aberto, então não é surpresa que eu não concorde com todas as prioridades [do Lightning Labs]”, disse Russel. “Acredito genuinamente que eles encontrarão uma maneira de criar um fluxo de renda sustentável e de ser um parceiro confiável no desenvolvimento técnico da Lightning Network; Não creio que alguém queira ver a rede dividida em pedaços.”

Desconsiderar completamente o processo de especificações poderia levar ao surgimento de subecossistemas muito diferentes, o que poderia prejudicar o desenvolvimento e a adoção da Lightning Network como um todo se eles se tornassem não interoperáveis. Mas, como destacou Russel, não há indicação de que alguma implementação esteja fazendo isso hoje. Manter uma interação coesa e interoperável entre os nós é fundamental se quisermos manter os detalhes de implementação abstraídos do usuário e, assim, permitir uma boa experiência do usuário.

“Se [o Lightning Labs] fosse o líder e também liderasse as especificações, acho que haveria um pouco menos de atrito em torno da adição de novos recursos, porque não seria tão difícil acompanhar o que eles estão fazendo, ”Neigut disse. “Talvez eles estejam mais envolvidos no processo de especificação daqui para frente. Acho que eles definitivamente estão recebendo feedback de nós e do resto da comunidade de que o processo de especificação é importante.”

Parte da controvérsia e tensões no processo de especificação BOLT decorrem de um e-mail compartilhado no Twitter no final de fevereiro, no qual o chefe de liquidez do Lightning no Lightning Labs, Alex Bosworth, comentou sobre o BOLT 12 e o processo de especificação do BOLT.

Bosworth escreveu que o processo BOLT é um processo de padronização arbitrário que não requer o consentimento das pessoas e, portanto, representa “mais um conjunto opinativo de documentos controlados por um processo arbitrário do que um tratado entre implementações independentes”.

Laboratórios Lightning mais tarde clarificado que os comentários de Bosworth refletem apenas a sua opinião e não necessariamente a da empresa.

Core Lightning: Como a reformulação da marca de implementação da Blockstream fala sobre sua visão de longo prazo para Bitcoin PlatoBlockchain Data Intelligence. Pesquisa vertical. Ai.
Bosworth provavelmente sugeriu descartar a conformidade com o processo de especificação sempre que ele entrar em conflito com o que ele chama de “problemas atuais” no Lightning, já que tais padrões podem não ser usados ​​pela maioria da rede e, portanto, não deveriam justificar muito esforço de desenvolvimento, enquanto esses problemas poderia representar pontos problemáticos para a maioria dos usuários e, portanto, deveria ser priorizado. Fonte da imagem.

Decker compartilhou suas idéias sobre os comentários de Bosworth e sobre o processo de especificação do BOLT durante o encontro de desenvolvedores de Bitcoin em Londres.

“Acho que são declarações muito fortes de alguém que nunca participou de uma única reunião de especificações”, disse ele. “Há um pouco de controvérsia no processo de especificação, mas isso é intencional. Se uma implementação fosse capaz de ditar a aparência de toda a rede, teríamos uma visão muito míope do que a rede poderia ser e não seríamos capazes de atender a todos os diferentes casos de uso que atendemos.”

“E sim, às vezes o processo de especificação é frustrante, concordo totalmente com isso”, acrescentou. “Certamente temos opiniões diferentes sobre como a rede deveria ser. Mas através deste processo de tese, antítese e síntese chegamos a um sistema que é muito mais capaz de servir nossos usuários do que se uma implementação fizesse isso sozinha.”

“Eu pessoalmente não trabalho nas especificações, então não me sinto qualificado para dar uma resposta”, disse Gugger no encontro, comentando o e-mail de Bosworth. “Só queria acrescentar que não concordo necessariamente com todos os pontos que Alex mencionou. Eu definitivamente teria dito isso de uma maneira diferente também. Acho que a falta de recursos para trabalhar nas especificações às vezes é interpretada como um bloqueio de coisas que não é a intenção e nem o nosso objetivo, é claro. Queremos trabalhar mais nas especificações, então espero que melhoremos nisso. É interessante observar como essa frustração às vezes vem à tona. Obrigado [Decker e Bastien Teinturier, desenvolvedor do ACINQ] por todo o trabalho que vocês fazem nas especificações. Eu preciso atender também, então farei o meu melhor.”

Russel também comentou o e-mail de Bosworth em um Discussão no Twitter onde ele prometeu dedicar mais tempo ao aprimoramento e marketing do CLN, pois disse que o LND não implementou o Lightning primeiro e não o implementou da melhor maneira – embora sua comunidade seja ótima, acrescentou.

“Acontece que eles decidiram que podem aproveitar o domínio da rede no controle do protocolo, e o processo de especificação não é ‘real’”, escreveu ele no tópico. “O Lightning Labs reivindicou a propriedade da rede Lightning de várias maneiras: tenho relutado em denunciá-los em público. Mas a rede relâmpago e a comunidade merecem coisa melhor.”

Russel não respondeu às perguntas de Bitcoin Magazine referindo-se a este tópico. A Lightning Labs não quis comentar.

“Em 2016, viemos de três direções diferentes e decidimos juntar todas as coisas que aprendemos durante esta fase inicial de experimentação em uma única especificação para que pudéssemos colaborar e interoperar”, disse Decker no encontro. “Esta fase experimental deve ser sempre acompanhada de uma proposta que seja introspectiva por todos e que possa ser implementada por todos. Às vezes, falta essa proposta formal e isso impede que outras implementações façam sua própria revisão sobre esse recurso. Esta revisão é muito importante para garantir que funciona para todos e que é o melhor que podemos fazer.”

“Como o nome Lightning Network sugere, ela lucra muito com os efeitos de rede que obtemos por ser compatível, por ser capaz de interoperar e permitir que todas as implementações funcionem em condições equitativas”, acrescentou mais tarde.

As implementações se complementam, elas não competem

Além dessa controvérsia muito específica em relação ao processo de especificação, as implementações do Lightning trabalham principalmente separadamente e depois em conjunto para trazer os melhores e mais exigidos recursos para a rede, garantindo uma melhor experiência geral do usuário.

Como resultado, a decisão da Blockstream de promover o CLN como uma oferta modular, leve e em conformidade com as especificações surge como uma alternativa para aqueles interessados ​​em executar uma implementação de nó que se esforce para ser completamente interoperável com o resto da rede e forneça um conjunto único de benefícios para aqueles que o fazem.

À medida que diferentes implementações se esforçam para se tornarem sua melhor versão e atender a um caso de uso específico, explorando sua própria proposta de valor, o usuário é, em última análise, quem se beneficia à medida que surgem opções cada vez melhores.

Carimbo de hora:

Mais de Bitcoin Magazine