Rede de iluminaçãoLiquidezManaging Solution Popularization

Autor: RGB++ Fans; Fonte: CKB

No artigo de divulgação anterior, já demos uma breve explicação dos conceitos básicos relacionados à Rede de iluminação, como canais de pagamento, roteamento de várias etapas e HTLC.

Mencionamos que, para fazer uma transferência na Rede de iluminação, muitas vezes é necessário passar por vários intermediários Nós e a quantidade de saldo transferível desses Nós intermediários costuma ser limitada, o que acaba afetando a taxa de sucesso dos pagamentos. Para garantir que os Nós na rota tenham fundos suficientes e melhorar a experiência do usuário, é necessário ajustar por meio de alguns esquemas de gestão de Liquidez. No entanto, para entender melhor o problema da gestão de Liquidez, devemos primeiro introduzir alguns conceitos básicos, como saldo local e saldo remoto (Local and Remote Balance), capacidade de entrada e capacidade de saída (Inbound and Outbound Capacity), entre outros.

No passado, mencionamos que a unidade básica da Rede de iluminação é o Nó e o canal, sendo este último uma instalação de transferência 1 para 1 fora da cadeia construída na rede BTC. Ao inicializar o canal, ambas as partes transferem uma certa quantia de dinheiro como saldo inicial. O saldo do seu lado é chamado de “saldo local”, enquanto o saldo do lado do seu oponente é chamado de “saldo remoto”. O saldo local determina a quantidade de dinheiro que você pode transferir para o outro lado, limitando sua capacidade de pagamento (ou seja, a “capacidade de pagamento”); o saldo remoto determina a quantidade de dinheiro que seu oponente pode transferir para você, limitando sua capacidade de recebimento (ou seja, a “capacidade de recebimento”).

Embora os saldos de ambas as partes envolvidas possam ser alterados com frequência antes do fecho do canal, a capacidade total do canal resultante não pode ser alterada, a menos que reinicie completamente o canal ou injete fundos através de uma “junção de canais”.

(Esta imagem mostra os saldos locais e remotos, com o seu saldo local a ser 5, o saldo remoto a ser 3 e a capacidade total do canal a ser 8)

Depois de entender os conceitos básicos acima, podemos ver o que a gestão de Liquidez na Rede de iluminação realmente pretende resolver. A figura abaixo mostra um diagrama simplificado de conexão de Nó. Não é difícil ver que você (canto inferior esquerdo) está conectado a apenas um Nó, o LNTop, e como seu saldo remoto é de 3, você pode receber no máximo US$ 3 em transferências. Se Sophie quiser transferir US$ 1 para você, ela falhará porque o Nó intermediário não tem saldo suficiente para LNTop (destacado em vermelho, a capacidade de saída desse Nó para LNTop é 0).

Pode-se dizer que a capacidade da Rede de iluminação é um dos problemas sérios enfrentados em fases iniciais. Se a Liquidez estiver distribuída de forma mais ampla em toda a rede, tais problemas serão efetivamente aliviados, e as soluções para isso são frequentemente referidas como ‘gestão de Liquidez’, como permitir que os clientes se conectem a vários Nó com alta Liquidez através do mercado de arrendamento (Lighting Pool), abrir/fechar novos canais conforme necessário, ou introduzir métodos como junção de canais e reequilíbrio (Channel Rebalancing) para controlar os saldos nos canais, tanto na cadeia como fora dela.

Atualmente, alguns clientes de carteiras ainda oferecem recursos de gerenciamento de canais automatizados, gerenciando os canais de forma inteligente com base no comportamento de pagamento do usuário e nas condições da rede, garantindo que haja Liquidez suficiente para transferências. Os novos usuários também podem adotar o modelo de “injeção unidirecional” ao entrar na Rede de iluminação, ou seja, permitindo apenas a injeção de fundos pela contraparte do canal, sem a injeção de fundos próprios durante a inicialização do canal, o que pode reduzir os custos econômicos para o usuário, mas o custo é a incapacidade de fazer pagamentos externos / capacidade de saída no início.

A seguir, faremos uma explicação mais detalhada sobre as técnicas comuns de gestão de Liquidez na Rede de iluminação. Primeiro, vamos entender o aluguel de canais, que visa principalmente resolver o problema de ‘capacidade de recebimento’ dos Nós, ou seja, quando outras pessoas desejam transferir dinheiro para você, você precisa garantir que eles possam estabelecer com sucesso uma rota de pagamento. Isso implica em requisitos para cada Nó na rota, como ter saldo disponível / capacidade de transferência suficiente. Como mencionamos anteriormente, a falha na rota ocorre quando há falta de Liquidez nos canais estabelecidos entre alguns Nós intermediários e outros Nós.

A construção de um canal tem um custo, já que os participantes muitas vezes têm que bloquear uma parte dos fundos, incorrendo em um custo de oportunidade. O chamado channel leasing, a primeira ideia é permitir que os operadores da Nó negociem diretamente através de meios orientados para o mercado, e que a Nó com fundos excedentários tome a iniciativa de construir canais para outros Nó através do sistema de “leasing”. **Por exemplo, se você é um comerciante que precisa receber dinheiro de outras pessoas a qualquer momento, você tem uma alta demanda pelo limite, e sua “capacidade de coleta” em um dia deve exceder 200 BTC.

Então, você estabeleceu um protocolo com 4 nós de grande porte através da Lighting Pool. Esses 4 nós criaram um canal com você por 24 horas, cada um bloqueando 50 BTC e fornecendo um saldo remoto de 50 BTC para você. Dessa forma, sua capacidade de recebimento alcançará 50 BTC em cada canal. Se alguém quiser transferir para você, pode escolher qualquer um dos 4 nós como intermediário para criar um caminho de pagamento.

(No 1ml.com, podemos ver vários operadores de Nó de iluminação Rede conhecidos, esses Nós têm fundos excedentes e estabeleceram vários canais com outros Nós, podem obter receitas através do aluguer de Liquidez)

Além da piscina de locação mencionada acima, há também Liquidez Advertisement (Anúncio de Liquidez), onde os provedores de liquidez podem usar a mensagem gossip da Lightning Nó para divulgar seus preços e duração do canal, e o Nó que aceita o preço pode abrir um canal com ele. Esses tipos de esquemas baseados em locação são combinados com o sistema de margem para evitar violações repentinas por uma das partes.

Atualmente, desenvolvedores como Lighting Labs e Rede de iluminação estão tentando otimizar cenários de locação de Liquidez com financiamento unidirecional, como o Fiber, que planeja introduzir o recurso de pagamento de Liquidez com base na funcionalidade de contrato inteligente CKB, onde um provedor de serviços LSP específico construirá canais com os usuários e fornecerá capacidade de entrada gratuita por um determinado período para atender às suas necessidades de recebimento de pagamentos. Quando os usuários receberem algum dinheiro, o contrato automaticamente recuperará os custos. O mecanismo de aposta de Liquidez relacionado a esse tipo de cenário também está sendo discutido.

Em geral, o aluguel de canais é frequentemente usado para resolver o problema de estabelecer conexões entre Nós e obter Liquidez contábil, enquanto o seguinte plano de junção de canais (Splicing) injetará ou retirará fundos na cadeia, alterando diretamente o saldo total de ambas as partes no canal. Normalmente, a abertura e o fechamento do canal exigem uma assinatura 2/2, que redistribui os ativos na cadeia possuídos em comum pelos participantes. No esquema anterior da Rede de iluminação, uma vez que o canal é aberto, o saldo total do canal não pode ser alterado a menos que o canal seja fechado antes de ser reiniciado.

E a junção do canal é uma nova solução proposta posteriormente, que pode não fechar o canal existente. Com a colaboração das partes envolvidas, o UTXO, que é comandado em conjunto pelas duas partes do canal, pode ser reorganizado e atualizado diretamente na cadeia, por exemplo, adicionando novos ativos com base nos ativos existentes para que as partes envolvidas possam controlar conjuntamente e, assim, alterar o saldo geral do canal. A figura abaixo resume brevemente essa ideia, onde o lado esquerdo é o ativo na cadeia correspondente ao canal antigo (UTXO1), controlado por Alice e Bob com assinatura múltipla. Em seguida, ambas as partes iniciam a junção do canal, adicionando outro ativo (UTXO2) para gerenciamento conjunto. No final, a quantidade de ativos (UTXO3) que ambas as partes do canal podem controlar em conjunto aumenta e a capacidade aumenta.

A junção de canais também pode ser usada para reduzir os fundos excedentes no canal, transferindo os ativos ociosos temporários para fora do canal e aumentando a eficiência do uso dos fundos. Comparado com o tradicional fechamento/reinício do canal, que requer duas interações na cadeia, a junção do canal só requer uma única operação na cadeia, o que pode reduzir significativamente os custos. Embora a junção do canal tenha vantagens óbvias, devido a razões históricas, essa solução ainda não está completamente madura e sua adoção em larga escala ainda levará tempo.

Depois de compreender a junção dos canais, vamos continuar a apresentar a ideia do rebalanceamento do canal (Channel Rebalancing), que é uma forma de ajustar o saldo fora da cadeia em canais diferentes sem fechar o canal ou alterar a capacidade total do canal (ignorando as taxas). **Suponha que você esteja executando um cliente da Rede de Iluminação, estabelecendo um total de três canais de pagamento com outros nós:

• Canal 1: Estabelecido com Nó X, capacidade total de 1 BTC
• Canal 2: estabelecido com Nó Y, capacidade total de 0,5 BTC
• Canal 3: estabelecido com Nó Z, capacidade total de 0,5 BTC

A distribuição de fundos de cada canal é a seguinte:

• Canal 1: saldo local: 0.9 BTC saldo remoto: 0.1 BTC
• Canal 2: Seu saldo local: 0.1 BTC Saldo remoto: 0.4 BTC
• Canal 3: Seu saldo local: 0.1 BTC Saldo remoto: 0.4 BTC

O problema agora é que, nos canais 2 e 3, a sua capacidade de saída é insuficiente, podendo transferir no máximo 0.1 BTC para a contraparte, o que não satisfaz as necessidades de transferência de grandes montantes. Entretanto, o canal 1 tem capacidade de saída em excesso, com 0.9 BTC, que você não precisará a curto prazo. Claramente, a melhor solução é transferir os fundos excedentes do canal 1 para os outros dois canais. Portanto, você pretende transferir 0.4 BTC do saldo local do canal 1 para o canal 2, e 0.4 BTC para o canal 3. Para realizar isso, você precisa concluir dois pagamentos circulares.

O método de operação específico é como mostrado na figura acima. Você pode transferir diretamente 0.8 BTC para Nó X, que então transfere 0.4 BTC para Y e Z, respectivamente. Em seguida, Y e Z transferem 0.4 BTC para você em canais 2 e 3, aumentando seu saldo local, para que você tenha fundos suficientes para futuras transferências de grande valor.

Ao observar o gráfico acima, não é difícil perceber que a essência do pagamento em loop é transferir fundos para si mesmo, movimentando os saldos em diferentes canais, e, por fim, alcançar a distribuição total de saldos de acordo com o resultado desejado. No entanto, apenas esse método não pode aumentar magicamente o saldo total de ambas as partes em qualquer canal. Além disso, sua implementação depende das seguintes suposições: X tem fundos suficientes para transferir para Y e Z, em outras palavras, os pagamentos em loop geralmente requerem que os Nós relevantes tenham reservas de Liquidez adequadas.

Pagamento de loop é uma implementação do pensamento de reequilíbrio do canal, e o plano de reequilíbrio pode ser combinado com outros métodos na prática, como trocas de submarino. Vamos apresentar as trocas de submarino (Submarine Swaps), cuja ideia central é trocar fundos on-chain e off-chain sem fechar o canal, usando métodos como HTLC.

O cenário mais simples de troca de submarinos é depósito na cadeia, supondo que Alice e Bob tenham estabelecido um canal 1 a 1, mas depois de um tempo, o saldo local de Alice está quase esgotado e não pode mais pagar externamente. Neste momento, Alice precisa injectar mais fundos e precisa fechar e reiniciar o canal, mas o canal é alugado, fechá-lo antecipadamente não é muito vantajoso, então o que fazer?

Se a troca for feita através de um submarino, o processo será mais fácil, mas requer HTLC. Primeiro, Alice pode gerar um número aleatório R, calcular o hash H® e, em seguida, enviar BTC para o endereço de Bob na cadeia, com a condição de desbloqueio limitada pelo HTLC. Para desbloquear esses BTC na cadeia, Bob deve conhecer o pré-imagem R correspondente a H®.

Bob está a realizar transações com Alice através de canais fora da cadeia, utilizando HTLC, mas com a direção invertida: Alice deve revelar R antes de desbloquear os fundos pagos por Bob. Assim que Alice revelar o valor de R, Bob pode utilizá-lo para desbloquear os BTC bloqueados por Alice na cadeia. Posteriormente, o saldo local de Alice no canal aumenta, enquanto o saldo de ativos na cadeia diminui de forma equivalente (desconsiderando as taxas), essencialmente numa troca de 1 para 1 (para facilitar a explicação do princípio, não seguimos rigorosamente a ordem operacional convencional do Atomic Swap. Na prática, na maioria das vezes, uma parte cria primeiro o HTLC fora da cadeia, e a outra parte cria um HTLC simétrico na cadeia).

As cenas acima são principalmente usadas para trocar ativos na cadeia por saldos fora da cadeia. Contanto que você ajuste as direções das operações de Alice e Bob, você pode trocar por operações de saque e transformar saldos fora da cadeia em ativos na cadeia. A troca submarina é segura por meio de combinações de recursos como HTLC e bloqueio de tempo, mesmo se a outra parte se recusar a cooperar com você no meio do caminho, o dinheiro bloqueado no HTLC ainda está seguro, porque a outra parte não sabe a Chave Secreta para desbloquear o HTLC. Após o vencimento do bloqueio de tempo, você pode recuperar seu principal.

Mas tenha em atenção que, embora o seu capital não seja roubado nos cenários acima, é necessário que uma das partes na cadeia crie um bloqueio HTLC para os fundos, o que inevitavelmente resultará em desgaste de taxas, e se a outra parte se desviar, certamente terá um certo impacto em si. Para resolver esses problemas, as trocas submarinas costumam ter alguns meios auxiliares de cooperação, como depósitos adiantados, sistemas de reputação e outros meios de punição.

Vamos resumir novamente, a ideia central da troca de submarinos é permitir a troca flexível de ativos na cadeia/fora da cadeia, e seguindo a ideia de reequilíbrio do canal, podem ser implementadas medidas de ajuste de liquidez mais otimizadas. Aqui vamos dar um exemplo simples:

No entanto, ao resumir os pontos acima, não é difícil perceber que as operações de troca submarina, junção de canais, locação de canais e outras operações de ajuste de Liquidez deixarão rastros de operações na cadeia, o que resultará em taxas. Se esse tipo de operação for realizado com frequência, certamente haverá pressão nos custos econômicos e na experiência do usuário. Como a Rede de iluminação depende da Rede principal do Bitcoin, a interação frequente na cadeia não é viável, mas o Fiber baseado em CKB enfrenta menos pressão desse tipo e oferece uma experiência mais fluida na gestão de Liquidez. No entanto, tanto a Rede de iluminação quanto o Fiber estão pesquisando soluções de Liquidez mais inovadoras e, no futuro, poderão encontrar um caminho mais adequado em colaboração ativa com equipes de projetos como a Mercury Layer.