En nuestro último artículo, Los principales desafíos que enfrenta la Red Lightning (1), discutimos la liquidez, uno de los factores clave que limita el desarrollo de la Red Lightning. El problema de liquidez se puede desglosar en dos aspectos: uno es la falta general de liquidez en la red, que requiere reducir las barreras para construir y mantener nodos de la Red Lightning e introducir mecanismos de incentivos adicionales; el otro es el problema de distribución de liquidez. Actualmente, se están implementando soluciones como Submarine Swap, channel stitching, pagos multipath, Lightning Pool, publicidad de liquidez y pagos en bucle para optimizar la liquidez en la Red Lightning.

Hoy, continuaremos abordando otros desafíos que enfrenta actualmente la Red Lightning y las soluciones innovadoras que la comunidad ha propuesto.

Soporte para Stablecoins

Con su alto rendimiento, baja latencia, bajo costo y características de privacidad, la Lightning Network se ha convertido en una opción ideal para los pagos con criptomonedas y sirve como una infraestructura de pago clave para construir una economía P2P. En 2021, tras la adopción de Bitcoin como moneda de curso legal por parte de El Salvador, el alcance de aplicación de la Lightning Network se expandió significativamente, con un aumento tanto en el número como en la cantidad de pagos, lo que llevó a más de 82,000 canales de pago en la red en un momento dado.

Origen: https://mempool.space/graphs/lightning/capacity

Sin embargo, en los últimos dos años, ha habido algunos cambios en la tendencia de desarrollo de la Red Lightning. Según los datos anteriores, podemos observar que la tasa de crecimiento de los fondos en la Red Lightning se ha desacelerado. Más notable aún, el número de canales incluso ha disminuido. Este fenómeno refleja que la Red Lightning está enfrentando nuevos desafíos después de una expansión rápida.

Actualmente, BTC es la moneda principal que circula dentro de la Red Lightning de Bitcoin. Sin embargo, uno de los mayores desafíos que enfrenta BTC como medio de intercambio es su alta volatilidad de precios. Esta inestabilidad ha sido durante mucho tiempo una barrera importante para la adopción generalizada de la Red Lightning. Para llevar verdaderamente la Red Lightning a los hogares y convertirla en un método preferido para pagos diarios pequeños y frecuentes, es especialmente esencial introducir el soporte de stablecoins. Después de todo, en la vida real, las personas están acostumbradas a usar monedas con un valor estable para transacciones diarias.

Para abordar esto, el 23 de julio de 2024, Lightning Labs lanzó la primera versión de la red principal de Lightning Network de activos múltiples, presentando oficialmente Taproot Assets a Lightning Network. Taproot Assets es un protocolo de emisión de activos en Bitcoin, que permite que los activos emitidos se depositen en los canales de pago de Lightning Network y se transfieran a través de la Lightning Network existente. El lanzamiento de la versión de la red principal de activos múltiples de Lightning Network marca el soporte formal de las stablecoins en la Lightning Network de Bitcoin, allanando el camino para aplicaciones como el comercio de divisas de liquidación instantánea global a través de Lightning Network y el uso de stablecoins para la compra de bienes.

Imagen: En la Red Lightning, Alice envía una stablecoin en USD, y Bob recibe una stablecoin en EUR.

Además, Nervos CKB ha lanzado la Fiber Network para la Lightning Network, que aprovecha la flexibilidad de la cadena de bloques CKB para admitir nativamente activos definidos por el usuario, incluidos los stablecoins nativos de Bitcoin acuñados por protocolos descentralizados como Stable++. En la versión de prueba completamente funcional lanzada en septiembre, los desarrolladores ya pueden probar el stablecoin nativo de Bitcoin RUSD utilizando la Fiber Network.

Creemos que la integración de la Lightning Network y las stablecoins desatará sinergias poderosas, inyectando nueva vitalidad en la Lightning Network y promoviendo la adopción generalizada de pagos criptográficos en la vida cotidiana.

Experiencia del usuario

A pesar de los avances tecnológicos significativos en la red Lightning, todavía hay margen de mejora en la experiencia del usuario, especialmente en comparación con las experiencias de pago tradicionales. Algunas brechas clave incluyen:

Requisito de permanencia en línea para los pagos

Los usuarios deben permanecer en línea al recibir o enviar pagos en la Red Lightning. Esto se debe a que los pagos de la Red Lightning implican cambiar el estado de los fondos en un canal compartido con otros, lo que significa que ambas partes deben estar en línea para alterar juntas el estado de los fondos. Una de las principales razones de los fallos en los pagos de la Red Lightning es que el destinatario está desconectado. Desde el punto de vista de la experiencia del usuario, esta es una falla significativa en el diseño. En contraste, los métodos de pago tradicionales (como las transferencias bancarias) y los pagos con blockchain (como las transferencias USDT en cadena) no requieren que el destinatario esté en línea; las transacciones se pueden completar simplemente con conocer la cuenta o dirección del destinatario.

La solución primaria actual es introducir Proveedores de Servicios de Lightning Network (LSP). Los LSP pueden recibir pagos en nombre de los usuarios sin conexión, eliminando el estricto requisito de "mantenerse en línea". Esta solución acerca la experiencia del usuario de la Lightning Network a la de los métodos de pago existentes, mejorando significativamente su practicidad y conveniencia.
Sin embargo, esta solución también introduce un nuevo desafío: suposiciones de confianza. Los usuarios necesitan depositar un cierto grado de confianza en el proveedor de servicios de la Red Lightning elegido. Esta dependencia de terceros contradice en cierta medida la intención original de descentralización y puede generar preocupaciones entre algunos usuarios.

Falta de un sistema para aceptar múltiples pagos de cualquier cantidad

Las facturas en la Red Lightning son la herramienta principal para solicitar pagos. Son generadas por el receptor del pago y proporcionan al iniciador toda la información necesaria para completar la transacción. Simplemente podemos comparar las facturas con los "códigos de pago" comúnmente encontrados en aplicaciones de pago.

Actualmente, la factura predeterminada en la Red Lightning es de un solo uso, y contiene un valor hash para un único pago junto con su cantidad. Una vez que el pago se ha realizado con éxito o la factura expira, se vuelve inválida. Este mecanismo resulta en un proceso engorroso: cada pago requiere generar, copiar, pegar y enviar una nueva factura al pagador. Este diseño impacta significativamente la experiencia del usuario en ciertos escenarios. Por ejemplo, un comerciante acostumbrado a mostrar un código QR de pago (como los de WeChat o Alipay) encontraría que el uso de la Red Lightning es engorroso. Especialmente durante las horas pico de negocio, la necesidad de generar y compartir frecuentemente facturas podría disminuir considerablemente la eficiencia e incluso afectar las operaciones normales.

Para abordar esto, la comunidad de Bitcoin ha propuesto varias soluciones:

Keysend

El node_id de los nodos de la Lightning Network permanece inalterado y se expone al pagador después de que se emite una factura, por lo que Keysend lo trata como un punto final estático. Este método tiene una ventaja significativa: depende completamente de la arquitectura de la Lightning Network sin necesitar soporte adicional del protocolo. Su inconveniente es que ofrece una protección de privacidad más débil, ya que datos sensibles como el nodo del destinatario, el canal y el UTXO del canal se exponen.
Sin embargo, la practicidad de Keysend ha sido ampliamente reconocida, y la mayoría de los clientes de la Red Lightning ya han implementado la funcionalidad de Keysend.

LNURL y Lightning Address

LNURL-pagar es un estándar que permite a los usuarios crear un código QR estático capaz de recibir múltiples pagos, mejorando significativamente la experiencia del usuario. El flujo de trabajo es el siguiente:

1. El usuario escanea el código QR (LNURL-pago) usando una billetera de Lightning Network.
2. La billetera decodifica el código QR, obtiene la URL y accede a ella a través de HTTPS.
3. Después de responder, el servidor solicita la cantidad de pago (que también puede ser una cantidad fija).
4. El usuario ingresa la cantidad y envía la información de vuelta al servidor.
5. El servidor devuelve una factura tradicional de la Red Lightning.
6. La billetera procesa el pago.

La dirección de Lightning optimiza aún más este proceso codificando el código QR del usuario (LNURL-pay) en una URL que se asemeja a una dirección de correo electrónico. Cuando otros usuarios acceden a esta URL, el sistema devuelve automáticamente una solicitud de pago LNURL-pay, simplificando todo el flujo de pago.

Vale la pena señalar que la mayoría de las billeteras que implementan la funcionalidad LNURL actualmente operan en un modo custodial. Estos servicios de billetera asignan a cada usuario una Dirección de Relámpago, lo que les permite recibir pagos fácilmente. Si bien este enfoque ofrece conveniencia, también introduce un grado de centralización, lo que requiere que los usuarios ponderen el equilibrio entre conveniencia y descentralización.

BOLT12

BOLT12 es una nueva propuesta para una especificación técnica de Lightning Network que tiene como objetivo lograr algunas de las funcionalidades ofrecidas por LNURL sin depender de un servidor web. Aunque BOLT12 aún no se ha fusionado en BOLT (la base técnica de Lightning Network), ha obtenido el apoyo de la mayoría de los desarrolladores. El punto destacado principal de BOLT12 en comparación con LNURL es que se puede implementar dentro del propio protocolo de Lightning Network, sin necesidad de depender de otros protocolos de red o métodos de comunicación.

Conclusión

Además de los problemas generales de liquidez y distribución de liquidez mencionados en el artículo anterior, y la falta de soporte de stablecoin discutido en este artículo, hay muchas áreas para mejorar la experiencia del usuario dentro de la Red Lightning. El camino de desarrollo de la Red Lightning también enfrenta numerosos desafíos. Por ejemplo, el mecanismo LN-Penalty utilizado en la Red Lightning de Bitcoin no solo agrega complejidad sino que también impone cargas de almacenamiento. La implementación de la mejora propuesta, eltoo, requiere una bifurcación suave de Bitcoin y la introducción de un nuevo tipo de hash de firma. De manera similar, las preocupaciones de privacidad con respecto a los HTLC pueden verse mejoradas a través de los PTLC, que podrían implementarse primero en las Redes Lightning de otras blockchains.

Aunque el camino por delante es desafiante, los avances tecnológicos continuos y los esfuerzos sostenidos de la comunidad finalmente superarán estos obstáculos. Tenemos todas las razones para creer que la Red Lightning está cada vez más cerca de su objetivo de adopción generalizada. No solo transformará los pagos con criptomonedas, sino que también tiene el potencial de convertirse en un impulsor clave de la innovación financiera global.

Descargo de responsabilidad:

1. Este artículo es reproducido de [RGB++ Fans]. Todos los derechos de autor pertenecen al autor original [Byte CKB]. Si hay objeciones a esta reimpresión, póngase en contacto con el Gate Learnequipo, y ellos lo manejarán rápidamente.
2. Descargo de responsabilidad: Las opiniones expresadas en este artículo son únicamente las del autor y no constituyen ningún consejo de inversión.
3. Las traducciones del artículo a otros idiomas son realizadas por el equipo de Gate Learn. A menos que se mencione lo contrario, está prohibido copiar, distribuir o plagiar los artículos traducidos.