Un problema con la liquidez de la red Lightning de Bitcoin e ideas para solucionarlo
Para resolver realmente el problema de recibir fondos sin tener liquidez asegurada del nodo de otra persona, se requieren cambios a nivel de protocolo.
Este es un editorial de opinión de Shinobi, un educador autodidacta en el espacio de Bitcoin y presentador de podcasts de Bitcoin orientado a la tecnología.
Ignorar los problemas de Lightning Network y la pila de protocolos parece ser algo muy popular en estos días. Actualmente es la segunda capa más ampliamente adoptada y utilizada de la red Bitcoin, y la que se mueve más rápido en términos de desarrollo adicional. También tiene muchas deficiencias que son fáciles de ocultar y solucionar, dado que es muy pequeño y se encuentra en una etapa muy temprana de adopción. Pero eso no hace que esos problemas desaparezcan, ni cambia la realidad de que, a una escala mucho mayor y más adelante en la curva de adopción, esos problemas se vuelven muy reales que requieren soluciones escalables reales.
Uno de los problemas centrales de Lightning es el tema de recibir liquidez. No es posible recibir fondos a través de Lightning Network sin antes haber asegurado la recepción de liquidez del nodo de otra persona. Esta es una limitación fundamental e inevitable del uso de Lightning Network sin custodia. Obviamente, al usar cosas como Wallet of Satoshi o el LNDHub predeterminado de Bluewallet (que son de custodia), puede sortear este problema, pero eso es solo porque alguien más lo resolvió por usted y usted no tiene el control de sus fondos. Sin embargo, cuando se trata de cosas de auto-custodia, debe abordar el problema.
Cuando Lightning Network se lanzó por primera vez y comenzó a ver un uso real durante la era «#Reckless», este problema se abordó de manera muy informal. Se resolvió esencialmente a través de conexiones sociales; a través de solicitudes a personas conocidas o amigos cercanos; a través de acuerdos de apretón de manos «Oye amigo, ¿puedes enviarme algo de liquidez? Acabo de activar mi nodo». No había mercados, no había servicios para usar, eran literalmente solo amigos ayudándose unos a otros. Incluso hoy, a través de cosas como PLEBNETun gran porcentaje de la obtención de liquidez que se produce en la red tiene lugar en este tipo de arreglos sociales informales.
La red aún es muy pequeña y aún se limita a lo que en un gráfico social es un pequeño conjunto de actores que, incluso a través de grados indirectos de separación, no están tan separados entre sí. Diría que apenas estamos comenzando a entrar en una fase de crecimiento en la que el tamaño de la red y la cantidad de personas involucradas comienzan a llegar al punto en que este tipo de arreglo y dinámica ya no es sostenible.
La siguiente fase de crecimiento para resolver este problema ocurrió no mucho después de que la red se pusiera en marcha. Servicios como LNBIG comenzaron a configurar una página donde las personas podían solicitar liquidez entrante. Bitrefill comenzó a ofrecer canales con la recepción de liquidez como servicio (y en el proceso creó su especificación de «canal turbo» que le permite usar un canal incluso antes de que se confirme en la cadena). Coincharge, Voltage y muchas otras compañías también ofrecen servicios similares. Al pagar una tarifa, simplemente puede hacer que una empresa abra un canal con usted para proporcionar liquidez de recepción para que se le envíe dinero. Este paso en la evolución de las cosas ocurrió para resolver una especie de problema de escala, ya que no todos los nuevos usuarios que se incorporaban tenían esas conexiones sociales para obtener liquidez entrante. Incluso si lo hicieran, las personas solo tienen tanto dinero que pueden asignar a los canales para las personas que conocen. Tampoco puede esperar que la gente se quede sentada todo el día, en todo momento esté listo para abrir canales cuando la gente necesite liquidez. Entonces, una empresa tiene espacio para intervenir y resolver el problema por una tarifa.
También tiene la dinámica de los proveedores de servicios Lightning (LSP) como Breez interviniendo y ellos mismos proporcionando una cierta cantidad de liquidez de recepción para sus usuarios. Sin embargo, esto todavía se enfrenta a los mismos problemas generales que obtener cosas de personas que conoce: Breez solo tiene tanto dinero que puede asignar a sus usuarios para recibir fondos. Realizan tarifas de enrutamiento al ser el nodo al que está conectado, pero eventualmente se encontrarán con el problema de tener que administrar una cantidad finita de fondos en una base de usuarios en crecimiento. Esto no es sostenible a perpetuidad.
El siguiente tipo de solución para este problema central de Lightning fueron los mercados reales. No es un negocio que le vende sus propios fondos en forma de capacidad de recepción, sino un mercado donde cualquiera puede venir y ofrecer vender liquidez de recepción a cualquier persona que desee comprarla. Dos ejemplos de esta solución son la casa de subastas “Lightning Pool” de Lightning Lab y los mercados Magma de Amboss. Lightning Pool incluso impone un período mínimo de tiempo que los canales comprados deben permanecer abiertos en cadena a través de un bloqueo de tiempo CLTV. Ambas son formas sin custodia para que una parte central (Lightning Labs y Amboss) haga coincidir a las personas que desean vender con las que desean comprar liquidez entrante. El problema es que todavía dependen de un facilitador centralizado para que esto funcione. Lightning Lab’s y Amboss realmente cobran una tarifa para participar en sus subastas.
Una categoría final de soluciones a este problema está representada por Liquidity Ads de CLN, un mercado descentralizado para recibir liquidez construido sobre canales de doble financiación (donde ambos lados del canal proporcionan liquidez en la financiación en lugar de solo uno). Liquidity Ads utiliza el protocolo de chismes de Lightning Network que anuncia los canales públicos disponibles para enrutar los pagos a fin de publicar anuncios que usted está dispuesto a vender recibiendo liquidez. Al igual que Lightning Pool, también impone un «tiempo de arrendamiento» durante el cual el canal debe permanecer abierto con un bloqueo de tiempo CLTV en cadena.
Entonces, todas estas opciones diferentes dejan una pregunta en el aire: ¿cómo queremos realmente abordar la solución de este problema a largo plazo y a escala? es literalmente imposible para recibir fondos a través de Lightning Network sin obtener primero la liquidez de recepción. Esa es una limitación central del propio protocolo. ¿Queremos resolver este problema a nivel del propio protocolo, dado que ahí es donde está la limitación actual, o queremos apoyarnos en los servicios y mercados centralizados para hacerlo?
Cuando se trata de eso, se trata de una cuestión de efecto de red y un problema del huevo o la gallina. Los compradores quieren ir donde están los vendedores, pero los vendedores también van a querer ir donde están los compradores. Si nos apoyamos mucho en los mercados o servicios centralizados para resolver este problema, eventualmente ese efecto de red se agravará y será cada vez más difícil de superar con alternativas descentralizadas basadas en protocolos. Entonces, esta es una pregunta muy importante que los usuarios deben hacerse ahora. ¿Dejamos que esta deficiencia masiva de la pila de protocolos Lightning se resuelva por completo mediante servicios comerciales centralizados, o intentamos resolverla a nivel de protocolo?
Personalmente, mi opinión es que dada la necesidad absoluta de liquidez entrante para utilizar el protocolo de forma autocustodia, este problema debe abordarse a nivel de protocolo. Y como última nota, para resolver esto a nivel de protocolo de manera descentralizada aún permite que las empresas actuales y las soluciones centralizadas compitan abiertamente usando ese protocolo ellos mismos.
Esta es una publicación invitada de Shinobi. Las opiniones expresadas son totalmente propias y no reflejan necesariamente las de BTC Inc o Revista Bitcoin.
