Interpretação do sistema de Fiber: Um grande experimento de enxerto da Rede de iluminação em CKB

Em 23 de agosto, a equipe oficial da CKB lançou o plano Fiber Network (rede de fibra) baseado na CKB. Esta notícia logo causou grande discussão na comunidade, levando a um aumento rápido do preço da CKB em quase 30% em um único dia. O motivo pelo qual esta notícia causou tanto impacto é principalmente devido ao forte apelo narrativo da Fiber Network, e o Fiber da CKB atualizou o tradicional Fiber Network, fazendo muitas melhorias nele.

Por exemplo, o Fiber pode suportar nativamente vários tipos de ativos, como CKB, BTC, stablecoins, etc., e a taxa de transação do CKB é muito menor do que a do BTC, com uma velocidade de resposta rápida. O Fiber pode obter uma vantagem nessa área de UX. Além disso, o Fiber também fez várias otimizações em termos de privacidade e segurança.

Além disso, Fiber e BTC podem interligar-se para formar uma rede P2P maior. Em eventos offline anteriores, a equipe oficial da CKB até mencionou a instalação de 100.000 nós físicos na Fiber e na Rede de iluminação para promover a melhoria e o avanço da rede de pagamento P2P. Sem dúvida, esta é uma história sem precedentes.

Se a visão oficial do CKB for realizada no futuro, será uma grande Informação favorável para a Rede de iluminação, CKB e até mesmo para o ecossistema BTC. Com base nos dados do mempool, atualmente há mais de US$ 300 milhões em fundos na Rede de iluminação BTC, com cerca de 12.000 nós e quase 50.000 canais de pagamento construídos entre eles.

E no spendmybtc.com, podemos ver cada vez mais comerciantes a aceitar pagamentos na Rede de iluminação, desde que o BTC seja cada vez mais reconhecido, o surgimento do impulso da Rede de iluminação e de soluções de pagamento fora da cadeia como o Fiber certamente aumentará dia a dia.

Com o objetivo de fornecer uma interpretação sistemática da solução técnica da Fiber, o relatório de pesquisa ‘Geek Web3’ escreveu este relatório sobre o esquema geral da Fiber. Como uma solução de implementação da Rede de iluminação baseada em CKB, a Fiber é semelhante ao BTCRede de iluminação em termos gerais, mas foi otimizada em muitos detalhes.

A arquitetura geral da Fiber inclui quatro componentes principais: canais de pagamento, WatchTower, roteamento multi-hop e pagamentos interdomínio. Vamos começar explicando o componente mais importante, os ‘canais de pagamento’.

Rede de iluminação和Fiber的基石：支付通道

A essência do canal de pagamento é transferir as transferências / transações para processamento fora da cadeia e, depois de um certo período de tempo, enviar o estado final para a ‘Liquidação’ na cadeia. Como as transações são concluídas instantaneamente fora da cadeia, muitas vezes é possível evitar as limitações de desempenho da cadeia principal, como BTC, etc.

Suponha que Alice e Bob tenham aberto um canal juntos, eles primeiro constroem uma conta multi-assinada na cadeia, depositam algum dinheiro nela, como Alice e Bob depositando cada um 100 dólares, como saldo individual deles no canal fora da cadeia. **A seguir, ambas as partes podem realizar várias transações no canal e, ao sair do canal, sincronizar o saldo final na cadeia, sendo pago pela conta multi-assinada a ambos, ou seja, “Liquidação”.

Por exemplo, ambas as partes começaram com 100 unidades. Depois disso, Alice transferiu 50 unidades para Bob, depois mais 10 unidades, e depois Bob transferiu 30 unidades de volta para Alice. No final, os saldos de ambas as partes mudaram para: Alice - 70, Bob - 130. Não é difícil perceber que a soma dos saldos de ambos não mudou. O exemplo das contas de ábaco nas imagens acima pode explicar bem este ponto.

Se uma das partes sair do canal, o saldo atual Alice: 70/Bob: 130 é sincronizado na cadeia, e os 200 yuans na conta de múltipla assinatura são transferidos de acordo com os respectivos saldos para ambos, concluindo a Liquidação. O processo acima parece simples, mas na prática há muitas situações complexas a serem consideradas.

Em primeiro lugar, você realmente não sabe quando a outra parte pretende sair do canal. Tomando o exemplo acima, Bob pode sair após a segunda transferência ser concluída ou mesmo após a primeira transferência, e o canal de pagamento não impõe isso, permitindo que as partes envolvidas saiam livremente. Para alcançar isso, é necessário assumir que alguém pode sair a qualquer momento, e qualquer uma das partes pode apresentar o saldo final à cadeia para liquidação.

Portanto, existe uma configuração de ‘transações de compromisso’, ‘transações de compromisso’ são usadas para declarar os saldos mais recentes das duas partes no canal, e cada transferência gerará uma ‘transação de compromisso’ correspondente. Se você quiser sair do canal, pode submeter a transação de compromisso mais recente na cadeia, retirando o dinheiro que lhe é devido da conta multi-assinada.

Podemos concluir o seguinte: as transações de compromisso são utilizadas para liquidar os saldos das duas partes no canal na cadeia, e qualquer parte pode colocar as transações de compromisso mais recentes na cadeia e sair do canal a qualquer momento.

**Mas há uma cena importante de má conduta aqui: Bob pode enviar saldos expirados e transações comprometidas para na cadeia, como o Commit Tx3 na figura acima, o saldo de Bob é 130, mas Bob, para lucrar, envia o Commit Tx2 expirado para na cadeia, declarando que seu saldo é 160, e esse estado de saldo não é em tempo real, este é um típico ‘Gasto duplo’.

Para evitar esse tipo de cenário de gasto duplo, deve haver medidas punitivas correspondentes, e o design das medidas punitivas é justamente o cerne de todo o canal de pagamento 1 a 1, e só entendendo esta parte é que se pode compreender verdadeiramente o canal de pagamento. No design do canal, se qualquer uma das partes enviar um estado expirado e um Commit Tx para a na cadeia, não só não terá sucesso, como a outra parte poderá retirar todos os fundos.

Aqui, são utilizados os conceitos de ‘transação de compromisso assimétrico’ e ‘reversão de Chave Secreta’, ambos muito importantes. Primeiro, vamos explicar a ‘transação de compromisso assimétrico’.** Tomemos como exemplo a transação de compromisso Tx3 anterior. O diagrama abaixo mostra a representação gráfica da transação de compromisso:

Esta transação de promessa foi construída por Bob e enviada para Alice para que ela possa lidar com isso sozinha. Como mostrado na figura, este é uma transferência de BTC, que declara que 70 dólares da conta multi-signature são para Alice, 130 dólares são para Bob, mas as condições de desbloqueio do dinheiro são ‘assimétricas’, com restrições mais rigorosas para Alice e mais vantajosas para Bob.

Depois de receber a transação de promessa construída por Bob, Alice pode adicionar sua própria assinatura para satisfazer o 2/2 multisig, e então ela pode ativamente submeter a “transação de promessa” para a cadeia, permitindo-a sair do canal. Se ela não fizer isso, ela pode continuar a fazer transações no canal.

Aqui devemos prestar atenção: Esta transação de promessa é construída ativamente por Bob, onde as condições são desfavoráveis para Alice. Alice só pode aceitar/recusar, devemos encontrar uma maneira de deixar Alice com algum poder de decisão. No design do canal de pagamento, apenas Alice pode colocar a transação de promessa ‘desfavorável para si mesma’ na na cadeia para disparar, porque a transação de promessa requer uma assinatura múltipla 2/2, e depois de Bob construir a transação localmente, ele só tem a sua própria assinatura, sem a assinatura de Alice.

E Alice pode “apenas receber a assinatura de Bob, mas não enviar a sua própria assinatura para ele”, **isso é como um contrato desfavorável a você, que exige dupla assinatura sua e da outra pessoa, e a outra pessoa assina primeiro e depois lhe dá o documento, mas você pode impedir que a outra pessoa obtenha a assinatura.**Se quiser que o contrato entre em vigor, assine e divulgue, se não quiser que entre em vigor, não assine ou não divulgue. Obviamente, no caso acima, Alice pode restringir Bob.

Então, o ponto crucial: Após cada transferência na canal, aparecerá um par de transações de compromisso, com duas versões semelhantes às imagens espelhadas abaixo. Alice e Bob podem cada um construir transações de compromisso favoráveis a si próprios, declarando o valor a ser recebido no balanço/saída, e enviar o conteúdo da transação ao outro para processamento.

Curiosamente, o valor recebido ao sair nessas duas declarações de transações de promessa é o mesmo, mas as condições de retirada são diferentes, o que explica a origem das ‘transações de promessa assimétricas’ mencionadas anteriormente.

Anteriormente, explicamos que cada transação de compromisso requer uma assinatura 2/2 para ser válida, as transações de compromisso construídas localmente por Bob que favorecem a si mesmos não atendem ao requisito de 2/2 assinaturas, e as transações de compromisso que atendem ao requisito de 2/2 assinaturas são retidas por Alice, Bob não pode submetê-las, apenas Alice pode, o que cria um equilíbrio. O mesmo princípio se aplica no sentido oposto.

Assim, Alice e Bob só podem submeter ativamente transações de compromisso desfavoráveis a si mesmos, desde que uma das partes submeta a Commit Tx à cadeia e seja efetiva, o canal será fechado. E voltando ao cenário de “Gasto duplo” mencionado no início, o que acontecerá se alguém enviar transações de compromisso expiradas para a cadeia?

Aqui, é necessário mencionar algo chamado “撤销Chave Secreta”. Se Bob enviar transações vencidas para a cadeia, Alice pode retirar o dinheiro que Bob merece através da “撤销Chave Secreta”.

Vamos dar uma olhada nesta imagem. Suponha que a transação de compromisso mais recente seja Commit Tx3 e a transação Commit Tx2 tenha expirado. Se Bob enviar a transação expirada Tx2 na cadeia, Alice pode pegar o dinheiro de Bob usando a Chave Secreta de reversão da Tx2 (Alice precisa agir dentro do intervalo de bloqueio de tempo).

E para o mais recente Tx3, Alice não tem a sua Chave Secreta revogada, só depois do aparecimento do Tx4 no futuro é que Alice poderá obter a Chave Secreta de revogação do Tx3. Isto é determinado pelas características da criptografia de chave pública/privada e UTXO, e devido ao espaço, este artigo não entrará em detalhes sobre a implementação da revogação da Chave Secreta.

Podemos lembrar a conclusão: Bob só precisa submeter a transação de compromisso expirada para a cadeia, então Alice pode pegar o dinheiro de Bob usando a revogação da Chave Secreta como punição. Da mesma forma, se Alice agir mal, Bob também pode puni-la dessa forma. Dessa forma, os canais de pagamento 1对1 podem evitar efetivamente o Gasto duplo, desde que os participantes sejam racionais e não se atrevam a agir mal.

Em relação a esta área de canais de pagamento, o Fiber baseado em CKB tem melhorias significativas em comparação com o Rede de iluminação do BTC, sendo capaz de suportar nativamente a transferência/comércio de vários tipos de ativos, como CKB, BTC e RGB++moeda estável, enquanto o Rede de iluminação só consegue suportar nativamente o BTC. Após a introdução do Ativo Taproot, o Rede de iluminação do BTC ainda não consegue suportar nativamente ativos não relacionados ao BTC, apenas oferecendo suporte indireto à moeda estável.

（Fonte da imagem: Dapangdun）

Além disso, devido ao fato de que a camada 1 da Fiber depende da cadeia principal CKB, as operações de abertura e fechamento de canais consomem muito menos taxas, ao contrário do que acontece na Rede de iluminação BTC, o que é uma clara vantagem em termos de UX para os usuários.

Segurança em tempo integral: Torre de Vigia WatchTower

O problema com a revogação de Chave Secreta mencionado no texto acima é o seguinte: Os participantes do canal devem monitorar constantemente um ao outro para evitar que eles submetam transações de compromisso expiradas à cadeia por trás das costas uns dos outros. No entanto, ninguém pode garantir estar online 24 horas por dia. O que você deve fazer se o outro lado agir mal enquanto você estiver offline?

Tanto a Fiber quanto a BTC possuem o design da Torre de Vigia do WatchTower, que ajuda os usuários a monitorar a atividade na cadeia 24 horas por dia. Uma vez que alguém na canal submeta uma transação de compromisso expirada, o WatchTower a processará imediatamente para garantir a segurança do canal e dos fundos.

A explicação específica é a seguinte: para cada transação de compromisso expirada, Alice ou Bob podem antecipadamente construir a transação de penalidade correspondente (usando a Chave Secreta para revogar a transação de compromisso expirada, com o beneficiário declarando-se a si mesmo) e enviar o texto em claro da transação de penalidade para a WatchTower. Assim que a WatchTower detectar que alguém enviou a transação de compromisso expirada para a cadeia, ela também enviará a transação de penalidade para a cadeia, aplicando uma punição direcionada.

Para proteger a privacidade dos participantes do canal, o Fiber só permite que os usuários enviem “hash de transações de compromisso expiradas + texto simples de transação de punição” para o WatchTower, para que o WatchTower inicialmente não saiba o texto simples da transação de compromisso, apenas o seu hash. A menos que alguém realmente envie a transação de compromisso expirada para a cadeia, o WatchTower verá o texto simples e, em seguida, submeterá a transação de punição à cadeia. Desta forma, a menos que alguém esteja realmente agindo de má fé, o WatchTower não verá o histórico de transações dos participantes do canal (mesmo que veja, só verá uma).

Aqui vamos mencionar a otimização do Fiber em comparação com o Bitcoin. O mecanismo de penalidade relacionado à revogação da chave secreta mencionado acima é chamado de “LN-Penalty”, e o LN-Penalty do Bitcoin tem uma desvantagem óbvia: o WatchTower precisa armazenar todos os hashes de transações de promessas expiradas e suas respectivas chaves secretas de revogação, o que causa uma pressão significativa de armazenamento.

Já em 2018, a comunidade BTC propôs uma solução chamada “eltoo” para resolver o problema acima mencionado, mas requer suporte para o código de operação SIGHASH_ANYPREVOUT do BTCforquilha. A ideia é que, quando uma transação prometida expirar e for registrada na cadeia, a transação prometida mais recente possa puni-la, permitindo que os usuários armazenem apenas a transação prometida mais recente. No entanto, o código de operação SIGHASH_ANYPREVOUT ainda não foi ativado, e essa solução ainda não foi implementada.

E Fiber implementou o protocolo Daric, modificando o design da Chave Secreta para permitir que a mesma Chave Secreta seja usada para várias transações de compromisso expiradas. Isso pode reduzir significativamente a pressão de armazenamento no WatchTower e nos clientes dos usuários.

Sistemas de transporte na rede: roteamento de várias etapas e HTLC/PTLC

Por exemplo, Alice e Ken não têm um canal, mas há um canal entre Ken e Bob, e Bob e Alice têm um canal, para que Bob possa atuar como um Nó intermediário entre Alice e Ken, para que possa haver transferência entre Alice e Ken. E ** “roteamento multi-hop” refere-se ao estabelecimento de caminhos de transferência através de múltiplos intermediários. **

A ‘rota de salto múltiplo’ pode aumentar a flexibilidade e a cobertura da rede. No entanto, o remetente precisa conhecer o estado de todos os Nós públicos e canais. No Fiber, todos os canais públicos, ou seja, a estrutura da rede, são totalmente públicos, qualquer Nó pode conhecer as informações de rede que os outros Nós possuem. Como o estado da rede inteira está em constante mudança na Rede de iluminação, o Fiber usa o algoritmo de caminho mais curto de Dijkstra para encontrar a rota mais curta, minimizando o número de intermediários e, em seguida, estabelecendo uma rota de transferência entre as duas partes.

No entanto, deve-se resolver o problema de crédito do intermediário Nó: como você pode garantir que ele é honesto? Por exemplo, mencionamos anteriormente que há um intermediário Bob entre Alice e Ken. Agora, Alice precisa transferir 100 yuans para Ken, e Bob pode segurar esse dinheiro a qualquer momento. Para evitar que o intermediário cometa fraude, são usados HTLC e PTLC para resolver esse tipo de problema.

Suponha que Alice queira pagar 100 unidades a Daniel, mas não tenha um canal direto com ele. No entanto, Alice descobre que pode fazer o pagamento a Daniel através de dois intermediários, Bob e Carol. Aqui, é necessário introduzir o HTLC como canal de pagamento. Inicialmente, Alice envia um pedido a Daniel, que por sua vez envia a Alice um hash r, mas Alice não conhece o PlaintextR correspondente a r.

Em seguida, Alice, no canal com Bob, constrói uma cláusula de pagamento usando HTLC: Alice concorda em pagar 102 unidades a Bob, mas Bob precisa revelar a chave R em 30 minutos, caso contrário Alice irá retirar o dinheiro. Da mesma forma, Bob cria um HTLC com Carol: Bob concorda em pagar 101 unidades a Carol, mas Carol precisa revelar a chave R em 25 minutos, caso contrário Bob irá retirar o dinheiro.

Carol, como de costume, cria um HTLC no canal com Daniel: Carol está disposta a pagar 100 unidades monetárias, mas Daniel deve informá-la o texto em claro de R em 20 minutos, caso contrário, Carol recuperará o dinheiro.

Daniel understands that the key R Carol is asking for is actually what Alice wants, because no one else cares about what R contains except Alice. So Daniel will cooperate with Carol, tell her the content of R, and get 100 yuan from Carol. In this way, Alice achieves her goal: to give Carol 100 yuan.

Depois disso, não é difícil imaginar o que aconteceu: Carol passou a chave R para Bob e ganhou 101 dólares; Bob passou a chave R para Alice e ganhou 102 dólares. Observando os ganhos e perdas de todos, podemos ver que Alice perdeu 102 dólares, Bob e Carol ganharam 1 dólar líquido, e Daniel recebeu 100 dólares. A parte que Bob e Carol ganharam foi a taxa que eles cobraram de Alice.

Mesmo que alguém no caminho de pagamento acima fique preso, por exemplo, se Carol não informar a chave R para o destinatário Bob, isso não causará perdas a Bob: após um tempo, Bob pode retirar o HTLC construído. O mesmo se aplica a Alice.

Mas a Rede de iluminação também tem problemas: o caminho não deve ser muito longo, se houver muitos intermediários, a confiabilidade do pagamento será comprometida: Alguns intermediários podem estar offline ou com saldo insuficiente para construir HTLCs específicos (por exemplo, cada intermediário no caso anterior precisa ter pelo menos mais de 100 dólares). Portanto, a adição de cada Nó intermediário no caminho aumentará a probabilidade de erro.

Além disso, HTLC pode potencialmente comprometer a privacidade. Embora o encaminhamento cebola possa proteger a privacidade adequadamente, como encriptação de informações de roteamento em cada salto, exceto pelo iniciador original Alice, cada pessoa só conhece os vizinhos imediatos, sem conhecer o caminho completo, mas na prática HTLC ainda é facilmente inferido quanto à correlação. Vamos dar uma olhada nesse caminho do ponto de vista divino

Suponha que Bob e Daniel são dois Nós controlados pela mesma entidade, e recebem muitos HTLCs enviados por várias pessoas todos os dias. Eles percebem que sempre que Alice e Carol enviam um HTLC, a Chave Secreta que precisam saber é sempre a mesma, e o destinatário seguinte, Eve, conectado a Daniel, sempre sabe o conteúdo da Chave Secreta. Portanto, Daniel e Bob podem deduzir que existe um caminho de pagamento entre Alice e Eve, porque eles sempre estão relacionados à mesma Chave Secreta, e assim inferir o relacionamento entre Alice e Eve e realizar monitoramento.

Nesse sentido, Fiber adota o PTLC, que melhora a privacidade com base no HTLC, usando chaves secretas diferentes para desbloquear cada PTLC no caminho de pagamento, de modo que a observação pura das chaves secretas exigidas pelo PTLC não pode determinar a correlação entre elas. Ao combinar o PTLC com roteamento cebola, o Fiber pode se tornar a solução ideal para pagamentos privados.

Além disso, a Rede de iluminação tradicional tem um cenário de ‘ataque de ciclagem de substituição’ em que os ativos intermediários de pagamento podem ser roubados. Essa descoberta levou até mesmo o desenvolvedor Antoine Riard a desistir do trabalho de desenvolvimento da Rede de iluminação. Até agora, o BTC Rede de iluminação ainda não tem medidas fundamentais para resolver esse problema, o que se tornou um ponto doloroso.

Atualmente, a equipe CKB melhorou o pool de transações para resolver os cenários de ataque mencionados acima. Como as soluções para ataques de substituição de transações em loop podem ser complicadas, este artigo não pretende explicar em detalhes. Se você estiver interessado, pode ler o artigo abaixo do BTCStudy e também conferir os materiais oficiais da CKB.

No geral, tanto em termos de privacidade quanto de segurança, o Fiber foi significativamente melhorado em comparação com a tradicional Rede de iluminação.

Pagamento atômico intercadeia entre Fiber e BTCRede de iluminação

Usando HTLC e PTLC, Fiber pode realizar pagamentos inter-domínios com BTC e Rede de iluminação, e garantir a ‘atomicidade das ações inter-domínios’, ou seja, todas as etapas relacionadas a pagamentos inter-domínios serão totalmente bem-sucedidas ou totalmente falharão, sem a possibilidade de sucesso parcial e falha parcial.

Depois de garantir a atomicidade da transferência interdomínios, pode-se garantir que a própria transferência interdomínios não cause perda de propriedade, o que permite que o Fiber e o BTCRede de iluminação se conectem. Por exemplo, é possível construir um caminho de pagamento em uma rede híbrida composta pelo Fiber e BTCRede de iluminação, transferindo diretamente fundos para os usuários da BTCRede de iluminação no Fiber (apenas para o destinatário BTC). Além disso, é possível trocar ativos CKB e RGB++ por BTC equivalente no BTCRede de iluminação através do Fiber.

Nós explicamos brevemente o princípio: suponha que Alice esteja executando um Nó na rede Fiber, enquanto Bob está executando um Nó na Rede de iluminação BTC, Alice quer transferir algum dinheiro para Bob, e ela pode fazer isso através do intermediário de transferência interdomínio Ingrid. Em termos concretos, Ingrid vai executar um Nó tanto na rede Fiber quanto na Rede de iluminação BTC, atuando como intermediário no caminho da transferência.

Se Bob quiser receber 1 BTC, Alice pode negociar uma taxa de câmbio com Ingrid, como trocar 1 CKB por 1 BTC. Alice pode enviar 1,1 CKB para Ingrid no Fiber e depois Ingrid envia 1 BTC para Bob na Rede de iluminação BTC, deixando 0,1 CKB como taxa.

Ingrid

É importante notar que as duas transações, uma na Rede de iluminação BTC e outra na Rede de iluminação de Fibra, são atômicas, o que significa que ou ambos os HTLCs são desbloqueados e o pagamento cruzado é executado com sucesso, ou nenhum deles é desbloqueado e o pagamento cruzado falha, evitando assim a situação em que Alice paga, mas Bob não recebe o dinheiro.

Na verdade, intermediário Ingrid pode não desbloquear o HTLC de Alice depois de conhecer a chave R, mas isso prejudicaria o intermediário Ingrid em vez do usuário Alice. Portanto, o design da Fiber é seguro para usuários. 01928374656574839201

Esta forma de transferência não requer a confiança de terceiros e pode ser realizada entre diferentes redes P2P com pouca ou nenhuma modificação necessária.

As vantagens do Fiber em comparação com outras vantagens da Rede de iluminação BTC

Anteriormente mencionamos que o **Fiber suporta ativos nativos CKB e ativos RGB++ (especialmente stablecoins), o que lhe confere um enorme potencial em cenários de pagamentos instantâneos, sendo mais adequado para as necessidades de pagamentos de pequeno valor do dia a dia.

Além disso, a Rede de iluminação Bitcoin tem um problema principal, que é a gestão de Liquidez. Talvez você se lembre do que mencionamos no início, o saldo total nos canais de pagamento é fixo. Se o saldo de uma das partes se esgotar, não será possível fazer transferências para a outra parte, a menos que a outra parte transfira dinheiro primeiro. Nesse caso, é necessário injetar fundos novamente ou abrir um novo canal.

Além disso, se estiver numa rede de vários Nós complexa, a falta de saldo em alguns Nós intermediários pode impedir as transferências para o exterior, o que pode levar à falha de todo o percurso de pagamento. Este é um dos pontos fracos da Rede de iluminação, e a solução para isto resume-se a fornecer um eficiente plano de injeção de Liquidez, garantindo que a maioria dos Nós possa injetar fundos a qualquer momento.

No entanto, na Rede de iluminação BTC, o processo de injetar Liquidez, abrir ou fechar canais é realizado na cadeia BTC. Se as taxas de transação da rede BTC forem extremamente altas, isso terá um impacto negativo na experiência do usuário do canal de pagamento. Digamos que você queira abrir um canal de capacidade de US $ 100, mas a operação de estabelecimento do canal custa US $ 10 em taxas. Então, este canal já perdeu 10% do seu fundo no momento da inicialização, o que é inaceitável para a maioria das pessoas; o mesmo vale para a injeção de Liquidez e outras tarefas.

Fiber has significant advantages in this regard. Firstly, CKB’s TPS is much higher than BTC’s, and the transaction fees can be as low as a few cents; secondly, to address the issue of insufficient liquidity leading to the inability to transfer, Fiber plans to cooperate with the Mercury layer to launch a new solution, allowing liquidity injection work to be done off-chain, thus solving UX and cost issues.

At this point, we have systematically sorted out the overall technical architecture of Fiber, and its comparison with BTCRede de iluminação is summarized in the above figure. Due to the complexity and diversity of the knowledge involved in Fiber and Rede de iluminação themselves, a single article may not cover all aspects. In the future, we will launch a series of articles on the topics of Rede de iluminação and Fiber, so stay tuned.