Interpretación del sistema Fiber: un experimento ambicioso que integra la Red Lightning en CKB

El 23 de agosto, CKB anunció el proyecto Fiber Network, basado en CKB y en la red Lighting Network. Esta noticia generó un gran debate en la comunidad y provocó un aumento del precio de CKB de casi el 30% en un solo día. El interés generado por esta noticia se debe principalmente al atractivo narrativo de Lighting Network y a las numerosas mejoras que Fiber Network ha realizado en este proyecto tradicional.

Por ejemplo, Fiber puede admitir nativamente varios tipos de activos, como CKB, BTC, monedas estables, etc., y la tarifa de CKB es mucho más baja que la de BTC, y la velocidad de respuesta es rápida. Fiber puede lograr avances en UX. En cuanto a la privacidad y la seguridad, Fiber también ha realizado muchas optimizaciones.

Además, Fiber y BTCLighting Network pueden conectarse entre sí para formar una red P2P más grande. En eventos anteriores fuera de línea, Incluso el equipo oficial de CKB mencionó que se establecerán 100,000 nodos físicos en Fiber y Lighting Network para promover la mejora y el progreso de la red de pago P2P. Sin duda, esta es una historia sin precedentes.

Si la visión oficial de CKB se realiza en el futuro, será una gran Información favorable tanto para la Red de Lighting como para el ecosistema de CKB y BTC. Según los datos de la mempool, actualmente hay más de 300 millones de dólares en fondos en la Red de Lighting de BTC, con aproximadamente 12,000 Nodos y cerca de 50,000 canales de pago entre ellos.

Y en spendmybtc.com, también podemos ver que cada vez más comerciantes están aceptando pagos a través de la red Lighting Network, siempre y cuando la aceptación de BTC sea cada vez más fuerte, el impulso del surgimiento de soluciones de pago off-chain como Lighting Network y Fiber sin duda aumentará día a día.

Con el propósito de realizar una interpretación sistemática de la solución técnica de Fiber, ‘Geek Web3’ escribió este informe de investigación sobre la solución integral de Fiber. Como una solución de implementación de Lighting Network basada en CKB, los principios de Fiber son en gran medida consistentes con Lighting Network de BTC, pero se han optimizado en muchos detalles.

La arquitectura general de Fiber incluye cuatro componentes principales: canales de pago, WatchTower, enrutamiento multi-hop, y pagos inter-dominio. A continuación, explicaremos en detalle el componente más importante, los ‘canales de pago’.

Lighting Network y Fiber: los fundamentos del canal de pago

**El canal de pago esencialmente mueve las transferencias/operaciones a un procesamiento fuera de la cadena, y luego después de un tiempo envía el estado final a la cadena para el “Asentamiento”. Debido a que las transacciones se completan instantáneamente fuera de la cadena, a menudo se pueden evitar las limitaciones de rendimiento de la cadena principal como BTC.

Suponiendo que Alice y Bob abren un canal juntos, primero construyen una cuenta multi-firma en on-chain y ponen algo de dinero, como 100 yuanes cada uno, como saldo en el canal off-chain. Luego, ambas partes pueden realizar múltiples transferencias dentro del canal y, al salir del canal, sincronizar el saldo final en on-chain, donde la cuenta multi-firma realiza el Asentamiento pagando a ambas partes.

Por ejemplo, al principio, ambas partes tienen 100 dólares cada una. Luego, Alice le transfiere 50 dólares a Bob, luego Alice le transfiere 10 dólares a Bob, y luego Bob le transfiere 30 dólares a Alice. Al final, los saldos de ambas partes son: Alice: -70 dólares, Bob: 130 dólares. Todos pueden ver fácilmente que la suma de los saldos de las dos personas no cambia. El ejemplo de la cuenta de cuentas de abalorios que se empujan y se tiran hacia atrás en la imagen de arriba puede explicar esto muy bien.

Si una de las partes sale del canal, se sincroniza el saldo actual de Alice: 70 / Bob: 130 en la cadena (on-chain) y se transfieren los 200 yuanes en la cuenta conjunta a cada uno de ellos según su saldo respectivo, completando el Asentamiento. El proceso anterior parece simple, pero en la práctica se deben considerar muchas situaciones complicadas.

En primer lugar, en realidad no sabes cuándo la otra parte quiere salir del canal. Tomando el ejemplo anterior, Bob puede salir después de la segunda transferencia, o incluso después de la primera, y el canal de pago no lo obligará a hacerlo, permitiendo que las partes participantes salgan libremente. Para lograr esto, se debe asumir que en cualquier momento alguien puede salir, y cualquiera de las partes puede enviar el saldo final a la cadena para realizar el Asentamiento.

Por lo tanto, hay una configuración de ‘transacción de compromiso’ que se utiliza para declarar el saldo más reciente de ambas partes dentro del canal, y se generará una ‘transacción de compromiso’ correspondiente cada vez que se realice una transferencia. Si desea salir del canal, puede enviar la transacción de compromiso más reciente a la cadena y retirar su dinero correspondiente de la cuenta multi-firma.

Podemos tomar nota de esta conclusión: las transacciones de compromiso se utilizan para liquidar los saldos de ambas partes en el canal en la cadena, y cualquiera de las partes puede enviar la transacción de compromiso más reciente a la cadena y luego salir del canal.

**Pero aquí hay un escenario importante de mala conducta: Bob puede enviar saldos vencidos y transacciones comprometidas a la cadena, por ejemplo, una vez que se genera Commit Tx3 en la imagen anterior, el saldo de Bob es 130, pero para beneficiarse, Bob envía el Commit Tx2 caducado a la cadena, declarando que su saldo es 160, y este estado de saldo no es en tiempo real, lo que es un típico “Doble gasto”.

Para evitar escenarios de doble gasto, debe haber medidas punitivas correspondientes, y el diseño de estas medidas punitivas es precisamente el núcleo de todo el canal de pago 1 a 1. Solo al comprender esta parte se puede entender verdaderamente el canal de pago. En el diseño del canal, si una de las partes envía un estado caducado y el Commit Tx a la cadena, no solo no tendrá éxito, sino que la otra parte podría llevarse todos los fondos.

Aquí se utilizan los conceptos de ‘transacción de compromiso asimétrica’ y ‘revocación Llave secreta’, que son muy importantes. Primero explicaremos la ‘transacción de compromiso asimétrica’. Tomemos como ejemplo la transacción de compromiso Tx3 anterior. La siguiente imagen es un diagrama conceptual de la transacción de compromiso:

Esta transacción de compromiso fue construida por Bob y luego enviada a Alice para que ella la maneje por sí misma. Como se muestra en la imagen, se trata de una transferencia de BTC que declara que 70 unidades monetarias se transfieren a la cuenta multi-firma de Alice y 130 unidades monetarias a la de Bob, pero las condiciones de desbloqueo del dinero son “asimétricas”, con restricciones más estrictas para Alice y más ventajosas para Bob.

Después de que Alice recibe la transacción de compromiso construida por Bob, puede adjuntar su firma para cumplir con el multisig 2/2, y luego Alice puede tomar la iniciativa de enviar la “transacción de compromiso” a la cadena, de modo que pueda salir del canal y, si no lo hace, puede continuar transfiriendo dinero en el canal.

Aquí debemos tener en cuenta: Esta transacción de promesa es iniciada por Bob, con condiciones desfavorables para Alice. Alice solo puede aceptar/rechazar. Debemos encontrar una manera de dejarle a Alice cierto grado de autonomía. En el diseño del canal de pago, solo Alice puede desencadenar la transacción de promesa ‘desfavorable para ella’ en on-chain, ya que la transacción de promesa debe cumplir con el requisito de multisig 2/2. Después de construir la transacción localmente, Bob solo tiene su firma, no la de Alice.

Alice, por otro lado, puede “solo recibir la firma de Bob, pero no enviarle su propia firma”, que es como un contrato que no es bueno para ti, necesitas firmar dos veces con otra persona, y la otra parte firma primero y luego te da el documento, no puedes dejar que la otra parte obtenga la firma. **Si quieres que el contrato entre en vigor, fírmalo y luego hazlo público, y si no quieres que surta efecto, no lo firmes ni lo publiques. Aparentemente, en el caso anterior, Alice tiene una manera de contener a Bob.

Entonces, llegamos al punto clave: Después de cada transferencia en el canal, aparecerá un par de transacciones de compromiso, con dos versiones similares en espejo, como se muestra a continuación. Alice y Bob pueden construir transacciones de compromiso favorables a sí mismos, declarando el saldo / cantidad que deben recibir al salir, y luego enviar el contenido de la transacción al otro para su procesamiento.

Curiosamente, el monto recibido al salir en estas dos transacciones de compromiso es el mismo, pero las condiciones de retiro son diferentes, lo que explica el origen de las ‘transacciones de compromiso asimétricas’ mencionadas anteriormente.

Como explicamos anteriormente, cada transacción de compromiso debe tener una firma múltiple 2/2 para ser efectiva. Las transacciones de compromiso que Bob construye localmente y que le favorecen no cumplen con la firma múltiple 2/2, mientras que las transacciones de compromiso que cumplen con la firma múltiple 2/2 están en manos de Alice y Bob no puede enviarlas. Solo Alice puede enviarlas, lo que crea un equilibrio. Lo mismo ocurre al revés.

De esta manera, Alice y Bob solo pueden presentar activamente transacciones de compromiso que no les sean favorables. Si una de las partes presenta la transacción de compromiso en la cadena y se activa, el canal se cerrará. Volviendo al escenario de ‘Doble gasto’ mencionado al principio, ¿qué sucede si alguien presenta una transacción de compromiso caducada en la cadena?

Aquí hay que mencionar algo llamado “撤销 Llave secreta”. Si Bob envía transacciones vencidas a la cadena, Alice puede retirar el dinero que Bob merece mediante la “撤销 Llave secreta”.

Echemos un vistazo a la siguiente imagen. Suponga que la transacción de compromiso más reciente es Commit Tx3. Commit Tx2 ha expirado. Si Bob envía Tx2 expirado a on-chain, Alice puede retirar el dinero de Bob mediante la anulación de la Llave secreta de Tx2 (Alice debe actuar dentro del rango de bloqueo de tiempo).

**Sin embargo, para el último Tx3, Alice no tiene su revocación 01928374656574839201, solo después de que aparezca Tx4 en el futuro, Alice podrá obtener la revocación 01928374656574839201 de Tx3. Esto está determinado por las características de la criptografía de clave pública-privada y UTXO, y debido a la longitud, este documento no entrará en detalles sobre la implementación del principio de revocación 01928374656574839201.

Podemos recordar la conclusión: Bob puede ser castigado si se atreve a enviar transacciones de compromiso caducadas a la cadena, Alice puede tomar el dinero de Bob usando la Llave secreta para castigarlo. Por otro lado, si Alice actúa mal, Bob también puede castigarla de la misma manera. De esta manera, los canales de pago 1 a 1 pueden evitar eficazmente el Doble gasto, siempre y cuando los participantes sean personas racionales y no se atrevan a actuar mal.

En cuanto al canal de pago, Fiber basado en CKB tiene una gran mejora en comparación con BTCLighting Network, ya que puede admitir nativamente la transferencia/comercio de múltiples tipos de activos, como CKB, BTC y RGB++ moneda estable, mientras que Lighting Network solo puede admitir nativamente BTC. Después de que Taproot Asset se lance, BTCLighting Network aún no podrá admitir nativamente activos que no sean BTC, solo indirectamente admitirá moneda estable.

(Fuente de la imagen: Dapangdun)

Además, debido a que la cadena principal Layer1 en la que Fiber depende es CKB, el costo de abrir y cerrar canales es mucho menor, no erosiona a los usuarios con tantas tarifas como lo hace la red Lighting Network de BTC, esta es una clara ventaja en términos de UX.

Seguridad completa: WatchTower

El problema con la Llave secreta de revocación mencionada anteriormente es el siguiente: Los participantes del canal deben vigilar constantemente a la otra parte para evitar que envíen transacciones de compromiso caducadas a la cadena de bloques de manera clandestina. Sin embargo, nadie puede garantizar estar en línea las 24 horas del día. ¿Qué sucede si la otra parte actúa maliciosamente mientras estás desconectado?

Tanto Fiber como BTCLighting Network tienen el diseño de WatchTower, que ayudará a los usuarios a monitorear las actividades on-chain las 24 horas del día. Si alguien en el canal presenta una transacción de compromiso vencida, WatchTower la manejará de manera oportuna para garantizar la seguridad del canal y los fondos.

La explicación específica es la siguiente: para cada transacción de compromiso vencida, Alice o Bob pueden preparar previamente la transacción de castigo correspondiente (revocando la Llave secreta para manejar la transacción de compromiso vencida, declarándose beneficiario) y luego enviar el Texto sin formato de la transacción de castigo a WatchTower. Una vez que WatchTower detecta que alguien ha enviado la transacción de compromiso vencida a la cadena, también enviará la transacción de castigo a la cadena para imponer una sanción específica.

Para proteger la privacidad de los participantes del canal, Fiber solo permite que los usuarios envíen el “hash de transacciones de compromiso caducadas + transacción de castigo Texto sin formato” a WatchTower. De esta manera, WatchTower no sabe al principio el Texto sin formato de la transacción de compromiso, solo su hash. A menos que alguien realmente envíe la transacción de compromiso caducada a la cadena, WatchTower no verá el Texto sin formato y luego enviará la transacción de castigo a la cadena. De esta manera, a menos que alguien esté haciendo algo malo, WatchTower no verá el registro de transacciones de los participantes del canal (incluso si lo ven, solo pueden ver una de ellas).

Aquí queremos mencionar la optimización de Fiber en comparación con BTCLighting Network. El mecanismo de penalización relacionado con la revocación de llave secreta anteriormente mencionado se denomina ‘LN-Penalty’, y el LN-Penalty de BTCLighting Network tiene una clara desventaja: WatchTower debe almacenar todos los hash de transacciones de compromiso caducadas y sus correspondientes revocaciones de llave secreta, lo que genera una considerable presión de almacenamiento.

En 2018, la comunidad BTC propuso una solución llamada “eltoo” para abordar el problema anterior, pero requiere el soporte de BTCfork para el código de operación SIGHASH_ANYPREVOUT. La idea es que una vez que la transacción de compromiso caduque en la cadena, la transacción de compromiso más reciente puede castigarla, de modo que el usuario solo necesita guardar la transacción de compromiso más reciente. Sin embargo, el código de operación SIGHASH_ANYPREVOUT aún no se ha activado, y esta solución no ha sido implementada hasta ahora.

Y Fiber implementa el protocolo Daric, modificando el diseño de la llave secreta para que una misma llave secreta se pueda aplicar a múltiples transacciones de compromiso vencidas. Esto permite reducir en gran medida la carga de almacenamiento en el WatchTower y en el cliente del usuario.

Sistemas de transporte en redes: enrutamiento de múltiples saltos y HTLC/PTLC

La canal de pago mencionado anteriormente solo es aplicable a escenarios de transacciones 1 a 1, mientras que la Red Lightning admite pagos de múltiples saltos, es decir, enrutamiento a través de Nodo intermedios, permitiendo transferencias entre partes que no tienen un canal directo, por ejemplo, Alice y Ken no tienen un canal, pero Ken tiene un canal con Bob, y Bob tiene un canal con Alice, Bob puede actuar como un Nodo intermedio entre Alice y Ken, permitiendo la transferencia entre ellos. Y el “enrutamiento de múltiples saltos” se refiere a la construcción de una ruta de transferencia a través de varios comisionistas.

El “enrutamiento multisalto” mejora la flexibilidad y la cobertura de la red. Sin embargo, el remitente debe conocer el estado de todos los nodos y canales públicos. En Fibra, todos los canales públicos, es decir, la estructura de la red, son totalmente públicos, y cualquier Nodo puede acceder a la información de la red que tienen otros Nodos. Dado que el estado de toda la red en la red de iluminación cambia constantemente, Fiber utilizará el algoritmo de ruta más corta de Dijkstra para encontrar la ruta de enrutamiento más corta, hacer que el número de comisionistas sea lo menor posible y luego configurar una ruta de transferencia entre las dos partes. **

Sin embargo, es necesario resolver el problema de crédito del intermediario Nodo: ¿cómo asegurarse de que es honesto? Por ejemplo, en el caso mencionado anteriormente entre Alice y Ken, donde comisionista Bob está involucrado, si Alice quiere transferir 100 yuanes a Ken, Bob podría retener el dinero en cualquier momento. Para prevenir que el comisionista haga algo malo, HTLC y PTLC se utilizan para resolver este tipo de problemas.

Supongamos que Alice quiere pagarle 100 dólares a Daniel, pero no tienen un canal establecido entre ellos. Sin embargo, Alice descubre que puede realizar el pago a través de dos intermediarios, Bob y Carol. Para esto, se utiliza un HTLC como canal de pago. En primer lugar, Alice envía una solicitud a Daniel, y luego Daniel le envía a Alice un hash r, aunque Alice no conoce el Texto sin formatoR correspondiente.

Después, en el canal entre Alice y Bob, se construyen los términos de pago mediante HTLC: Alice está dispuesta a pagar 102 monedas a Bob, pero Bob debe decir la clave R en 30 minutos, de lo contrario, Alice retirará el dinero. De manera similar, Bob crea un HTLC con Carol: Bob pagará 101 monedas a Carol, pero Carol debe decir la clave R en 25 minutos, de lo contrario, Bob retirará el dinero.

Carol sigue el mismo procedimiento para crear un HTLC en el canal con Daniel: Carol está dispuesta a pagar 100 unidades monetarias, pero Daniel debe proporcionarle el R en un plazo de 20 minutos; de lo contrario, Carol recuperará el dinero.

Daniel entendió que la clave R que Carol quería en realidad era lo que Alice quería, porque aparte de Alice, nadie se preocupa por el contenido de R. Entonces Daniel cooperará con Carol, le dirá el contenido de R y obtendrá 100 dólares de Carol, de esta manera Alice logra su objetivo: darle 100 dólares a Carol.

Después de eso, no es difícil imaginar lo que sucedió: Carol le dio la clave R a Bob y recibió 101 dólares; Bob luego le dio la clave R a Alice y recibió 102 dólares. Observando las ganancias y pérdidas de todas las personas, podemos ver que Alice perdió 102 dólares, Bob y Carol ganaron 1 dólar neto, y Daniel recibió 100 dólares. La ganancia de 1 dólar que Bob y Carol obtuvieron es la tarifa que cobraron de Alice.

Incluso si alguien en la cadena de pagos anterior se queda atascado, como Carol no le informa a Bob la clave R a continuación, Bob no sufrirá ninguna pérdida: después de un tiempo, Bob puede retirar el HTLC que construyó. Lo mismo ocurre con Alice.

Pero Lightning Network también tiene problemas: la ruta no debe ser demasiado larga, si la ruta es demasiado larga o hay demasiados comisionistas, puede Soltar la confiabilidad del pago: algunos comisionistas pueden estar desconectados o tener un saldo insuficiente para construir HTLC específicos (como en el caso anterior, cada comisionista debe tener al menos más de 100 yuanes). Por lo tanto, cada Nodo intermedio agregado en la ruta aumentará la posibilidad de error.

Además, **HTLC puede filtrar privacidad. Aunque la ruta de cebolla puede proteger la privacidad adecuadamente, **por ejemplo, encriptar la información de enrutamiento en cada salto, excepto Alice, el iniciador original, cada persona solo conoce a los vecinos de arriba y de abajo, no conoce la ruta completa, **pero de hecho, HTLC todavía es fácil de inferir la correlación. **Miramos desde la perspectiva de Dios la siguiente ruta

Supongamos que Bob y Daniel son dos Nodo controlados por la misma entidad, y reciben muchos HTLC de varias personas todos los días. Descubren que cada vez que Alice y Carol les envían un HTLC, la Llave secreta que quieren conocer siempre es la misma, y el receptor conectado a Daniel, Eve, siempre conoce el contenido de Llave secretaR. Por lo tanto, Daniel y Bob pueden intuir que existe una ruta de pago entre Alice y Eve, ya que siempre están involucrados con la misma Llave secreta, y deducir la relación entre Alice y Eve para ejercer vigilancia.

Para ello, Fiber utiliza PTLC, una mejora de privacidad sobre HTLC, en la que cada PTLC en la ruta de pago se desbloquea con una llave secreta diferente, lo que hace imposible determinar la relación entre ellas al observar simplemente las llaves secretas requeridas para cada PTLC. Al combinar PTLC con enrutamiento de cebolla, Fiber se convierte en la solución ideal para pagos privados.

Además, existe un escenario de ‘ataque de ciclo de transacciones de reemplazo’ en la tradicional Lighting Network, que puede resultar en el robo de activos del comisionista de la ruta de pago. Este descubrimiento incluso llevó a Antoine Riard, un desarrollador, a abandonar su trabajo en la Lighting Network. Hasta ahora, BTCLighting Network no ha encontrado una solución fundamental para este problema, lo que lo convierte en un punto doloroso.

Actualmente, el equipo de CKB ha mejorado el nivel del pool de transacciones para que Fiber pueda abordar los escenarios de ataque mencionados anteriormente. Dado que las alternativas de ataque de bucle de transacciones y sus soluciones son bastante complejas, este artículo no tiene la intención de extenderse en explicaciones; aquellos interesados pueden leer el siguiente artículo de BTCStudy y revisar la documentación oficial de CKB.

En general, Fiber ha mejorado significativamente tanto la privacidad como la seguridad en comparación con la red Lighting Network tradicional.

Pagos atómicos cruzados entre Fiber y BTCLighting Network

Usando HTLC y PTLC, Fiber puede lograr pagos intercadenas con BTCLighting Network, y puede garantizar la ‘atomicidad de la acción intercadenas’, es decir, que todos los pasos relacionados con las transferencias intercadenas sean exitosos o fallidos en su totalidad, sin posibilidad de parcialidad en el éxito o el fracaso.

Después de que la atomicidad interdominio esté garantizada, se puede garantizar que el interdominio en sí no cause pérdidas de propiedades, lo que permite que Fiber y BTCLighting Network se conecten entre sí, por ejemplo, se puede construir una ruta de pago en una red mixta compuesta por Fiber y Lighting Network, y transferir directamente a los usuarios de BTCLighting Network desde Fiber (el receptor solo admite BTC), y también se puede intercambiar activos de CKB y RGB ++ en Fiber por BTC equivalente en BTCLighting Network.

Vamos a explicar brevemente el principio: supongamos que Alice ejecuta un Nodo en la red Fiber, mientras que Bob ejecuta un Nodo en la red Lighting Network de BTC. Si Alice quiere transferirle dinero a Bob, puede lograrlo a través del intermediario interdominio Ingrid. Específicamente, Ingrid funcionará como un comisionista en la red Fiber y en la red Lighting Network de BTC, actuando como un nodo en la ruta de transferencia.

Si Bob quiere recibir 1 BTC, Alice puede negociar una tasa de cambio con Ingrid, como cambiar 1 CKB por 1 BTC. Alice puede enviar 1.1 CKB a Ingrid a través de Fiber, luego Ingrid puede enviar 1 BTC a Bob a través de BTCLighting Network, y dejará 0.1 CKB como tarifa de transacción.

Ingrid

Es importante tener en cuenta que las transacciones cruzadas en BTCLighting Network y Fiber son atómicas, lo que significa que o bien se desbloquean ambos HTLC y se realiza el pago cruzado sin problemas, o bien ninguno se desbloquea y el pago cruzado falla, sin que se dé la situación de que Alice pague y Bob no reciba el dinero.

(De hecho, comisionista Ingrid puede optar por no desbloquear el HTLC de Alice después de conocer la clave R, pero esto perjudicaría al comisionista Ingrid en lugar del usuario Alice, por lo que el diseño de Fiber es seguro para los usuarios)

Este método no requiere confiar en terceros para realizar transferencias entre diferentes redes P2P, y prácticamente no requiere ninguna modificación.

Ventajas de Fiber sobre la Red de Iluminación BTC y otras

Como se mencionó anteriormente, Fiber admite activos nativos de CKB y activos RGB++ (especialmente monedas estables), lo que lo hace tener un gran potencial en escenarios de pago instantáneo y es más adecuado para las necesidades de pago diarias de pequeñas cantidades.

Además, BTCLighting Network tiene un problema principal, que es la gestión de Liquidez. Es posible que recuerdes lo que mencionamos al principio, el saldo total en el canal de pago es fijo, si el saldo de una de las partes se agota, no se puede transferir dinero a la otra parte a menos que la otra parte transfiera dinero primero, en cuyo caso se debe reinyectar capital o abrir un nuevo canal.

Además, si es en una red de múltiples saltos complicada, es posible que algunos nodos intermedios no tengan suficiente saldo para realizar pagos salientes, lo que puede llevar al fracaso de toda la ruta de pago. Este es uno de los problemas de Lighting Network, y la solución obvia es proporcionar un plan de inyección de liquidez eficiente para garantizar que la mayoría de los nodos puedan inyectar fondos en cualquier momento.

Sin embargo, en BTCLighting Network, los pasos para inyectar liquidez, abrir o cerrar canales se llevan a cabo en la cadena BTC. Si las tarifas de la red BTC son extremadamente altas, esto tendría un impacto negativo en la experiencia de usuario del canal de pago. Supongamos que desea abrir un canal de $100 de capacidad, pero la operación de establecimiento del canal cuesta $10 en tarifas, este canal le habría desgastado el 10% de sus fondos al inicializarlo, lo cual es inaceptable para la mayoría de la gente; lo mismo ocurre con la inyección de liquidez, entre otros trabajos.

Fiber tiene ventajas muy significativas en esto. En primer lugar, el TPS de CKB es mucho más alto que el de BTC, y las tarifas pueden alcanzar niveles de centavos; en segundo lugar, para hacer frente a la falta de liquidez que impide las transferencias, Fiber planea colaborar con Mercury layer para lanzar una nueva solución que permita que el trabajo de inyección de liquidez se libere de operaciones on-chain, abordando los problemas de UX y costos.

Hasta aquí, hemos sistematizado la arquitectura técnica general de Fiber, y se resume la comparación aproximada con BTCLighting Network en el gráfico anterior. Debido a que Fiber y Lighting Network involucran demasiados y diversos puntos de conocimiento, un solo artículo puede no cubrir todos los aspectos. En el futuro, lanzaremos una serie de artículos sobre los temas de Lighting Network y Fiber, así que manténganse atentos.