Lighting Network Liquidez管理方案科普

Autor: RGB++ Fans; Fuente: ByteCoin CKB

En el artículo divulgativo anterior, ya hemos hecho una breve divulgación sobre conceptos fundamentales relacionados con la red Lightning, como canales de pago, enrutamiento multihop, HTLC, etc.

Mencionamos que para realizar transferencias en la red Lighting Network, generalmente se requiere pasar por varias rutas construidas por múltiples nodos comisionistas, y la disponibilidad de saldo transferible en el nodo intermediario es a menudo limitada, lo que finalmente afecta la tasa de éxito del pago. Para asegurar que los nodos en la ruta tengan suficientes fondos y mejorar la experiencia del usuario, es necesario ajustar a través de algunos esquemas de gestión de liquidez. Sin embargo, para comprender a fondo el problema de la gestión de liquidez, primero debemos introducir algunos conceptos básicos, como el saldo local y remoto, la capacidad de entrada y salida, entre otros.

Como mencionamos en el pasado, las unidades básicas de la Red de Iluminación son Nodo y canales, que son facilidades de transferencia 1 a 1 fuera de la cadena basadas en la red BTC. En el momento de la inicialización del canal, ambas partes transferirán algo de dinero como saldo inicial, el saldo de su lado, llamado “saldo local”, y el saldo del lado de su contraparte, llamado “saldo remoto”. **El saldo local determina la cantidad de dinero que puede transferir a la contraparte, lo que limita su capacidad de pago, es decir, la “capacidad de salida”, y el saldo remoto determina la cantidad de dinero que la contraparte puede transferirle a usted, lo que limita su “capacidad de entrada”, es decir, la capacidad de cobrar.

Aunque los saldos respectivos de ambas partes pueden cambiar con frecuencia antes de que se cierre el canal, la capacidad total del canal después de sumar ambos lados no se puede cambiar, a menos que reinicies todo el canal o inyectes fondos a través de ‘unión de canales’.

(Esta imagen muestra los saldos respectivos tuyos y de Robert, tu saldo local es 5, el saldo remoto es 3, y la capacidad total del canal es 8)

Una vez que hayamos comprendido los conceptos básicos anteriores, veamos qué problema busca resolver la gestión de Liquidez en la Red Lightning. En el siguiente diagrama simplificado de conexiones de Nodo, podemos ver que solo estás conectado a un Nodo, LNTop (esquina inferior izquierda). Debido a que tu saldo remoto es de 3, solo puedes recibir transferencias de hasta 3 dólares. Sin embargo, si Sophie intenta transferirte 1 dólar, la transacción fallará debido a la falta de capacidad de salida del Nodo intermedio hacia LNTop (cuadro rojo, capacidad de salida del Nodo hacia LNTop es de 0).

Se puede decir que la capacidad del canal es uno de los graves problemas que encontró Lighting Network en las primeras etapas. Tales problemas se mitigarían si Liquidez se distribuyera más completamente a través de la red, y la solución a este problema a menudo se conoce colectivamente como “administración de Liquidez”, como permitir que los clientes se conecten a múltiples nodos ricos en Liquidez a través del Lighting Pool, abrir/cerrar nuevos canales según sea necesario o introducir la unión de canales, el reequilibrio de canales, etc. El equilibrio en el canal se regula dentro o fuera de la cadena.

Algunos clientes de billetera todavía ofrecen funciones de gestión de canales automatizados, gestionando los canales de forma inteligente según el comportamiento de pago del usuario y las condiciones de la red, asegurando suficiente Liquidez para las transferencias. Los nuevos usuarios también pueden utilizar el modo de “financiación unidireccional” cuando se conectan por primera vez a la red Lighting, lo que significa que solo el otro lado del canal proporciona financiación y el usuario no financia el canal al iniciarse, lo que reduce el costo económico para el usuario, pero el costo es que al principio no hay capacidad de pago externa/volumen de salida.

A continuación, vamos a proporcionar una explicación más detallada de las técnicas comunes de gestión de Liquidez en la Red Lightning. En primer lugar, vamos a entender el alquiler de canales, que aborda principalmente el problema de “capacidad de entrada” de los Nodos, es decir, cuando otras personas quieren transferirte dinero, debes asegurarte de que puedan establecer con éxito una ruta de pago. Para ello, se deben establecer requisitos para cada Nodo incluido en la ruta, como tener un saldo suficiente/disponibilidad de salida. Como mencionamos anteriormente, el escenario de fallo de la ruta se debe a la falta de Liquidez en los canales establecidos entre ciertos Nodos intermedios y otros Nodos.

Construir canales tiene un costo, ya que las partes involucradas a menudo deben bloquear una parte de sus fondos, lo que genera un costo de oportunidad. Y el llamado arrendamiento de canales implica la idea de que, a través de medios de mercado, los operadores de nodos realizan transacciones directas, y a través del mecanismo de ‘arrendamiento’, los nodos con excedente de fondos construyen activamente canales para otros nodos. Por ejemplo, si eres un comerciante que necesita recibir dinero de otras personas en cualquier momento y tienes altos requisitos de límite, tu ‘capacidad de recibir pagos’ en un día debe superar las 200 BTC.

Entonces, a través de Lighting Pool, llegaste a un protocolo con 4 grandes nodos, cada uno de los cuales estableció un canal contigo durante 24 horas, bloqueando 50 BTC y proporcionándote un saldo remoto de 50 BTC. De esta manera, tu capacidad de recibir pagos en cada canal alcanzaría los 50 BTC. Si alguien te transfiere dinero, puedes utilizar cualquiera de estos 4 nodos como intermediario para construir una ruta de pago.

(En 1ml.com, podemos ver varios operadores de nodos de Lighting Network conocidos que tienen fondos excedentes y han establecido múltiples canales con otros nodos, lo que les permite obtener ganancias mediante el alquiler de liquidez)

Además de la piscina de arrendamiento mencionada anteriormente, también hay Liquidez Advertisement (Anuncio de Liquidez), los proveedores de Liquidez pueden anunciar su precio y duración del canal utilizando mensajes de gossip de los Nodos de rayos, y los Nodos que acepten el precio pueden abrir un canal con ellos. Estos tipos de esquemas basados en alquiler también se combinarán con el sistema de Margen para evitar incumplimientos repentinos de una de las partes.

**Actualmente, desarrolladores como Lighting Labs y Fiber están intentando optimizar los escenarios de arrendamiento de Liquidez con inyección unidireccional de fondos, como por ejemplo, Fiber planea introducir una función de Contratos Inteligentes CKB basada en el pago de Liquidez, donde un proveedor de servicios LSP Nodo establecerá un canal con el usuario y proporcionará capacidad de entrada de forma gratuita durante un período de tiempo para satisfacer sus necesidades de recepción de pagos. Una vez que el usuario reciba cierta cantidad de dinero, el contrato automáticamente recuperará los costos. También se está discutiendo un mecanismo de apuesta de Liquidez relacionado con este tipo de escenario.

En general, el arrendamiento de canales se utiliza a menudo para resolver problemas de conexión entre nodos y obtener liquidez de entrada, mientras que el siguiente esquema de concatenación de canales (Splicing) realizará la financiación/aprobación a través de operaciones on-chain, lo que cambiará directamente el saldo total de ambas partes en el canal. Normalmente, la apertura y cierre del canal requerirán una firma 2/2, que redistribuirá los activos on-chain que ambas partes poseen en común. Sin embargo, en el esquema anterior de Lighting Network, una vez que se abre un canal, no se puede cambiar el saldo total del canal a menos que se cierre y se vuelva a abrir.

La concatenación de canales es una nueva solución propuesta posteriormente que permite no cerrar los canales existentes. Con la colaboración de las partes involucradas, se realiza una reestructuración y actualización directamente en on-chain de la UTXO que ambos lados del canal controlan conjuntamente. Por ejemplo, se pueden agregar nuevos activos sobre la base de los activos existentes para que las partes involucradas los controlen conjuntamente, lo que cambia el saldo total del canal. El siguiente diagrama resume brevemente esta idea. A la izquierda se encuentran los activos on-chain correspondientes al antiguo canal (UTXO1), controlados por la firma múltiple de Alice y Bob. A continuación, ambas partes inician la concatenación del canal y también incluyen otro activo (UTXO2) para administrarlo conjuntamente. Al final, el monto de los activos (UTXO3) que ambas partes del canal pueden controlar conjuntamente aumenta y la capacidad se incrementa.

La concatenación de canales también se puede utilizar para reducir los fondos excedentes en el canal, transferir los activos inactivos temporalmente fuera del canal y mejorar la eficiencia en la utilización de los fondos. En comparación con la interacción tradicional de cierre/reinicio de canal que requiere dos interacciones on-chain, la concatenación de canales solo requiere una operación on-chain, lo que puede Soltar significativamente los costos. A pesar de las claras ventajas de la concatenación de canales, debido a razones históricas, este enfoque no ha madurado completamente y su adopción generalizada todavía llevará tiempo.

Después de entender la unión de canales, continuamos presentando la idea de rebalance de canales (Channel Rebalancing), que es también un medio para ajustar los saldos off-chain en diferentes canales sin cerrar o cambiar la capacidad total del canal (ignorando las tarifas) . Supongamos que estás ejecutando un cliente de Lighting Network y has establecido un total de tres canales de pago con otros Nodo:

• Canal 1: Establecido con Nodo X, con una capacidad total de 1 BTC
• Canal 2: Establecido con Nodo Y, con una capacidad total de 0.5 BTC
• Canal 3: Establecido con Nodo Z, con una capacidad total de 0.5 BTC

La distribución de fondos de cada canal es la siguiente:

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

El problema ahora es que no tienes suficiente capacidad de emisión en los canales 2 y 3, y solo puedes transferir un máximo de 0.1 BTC al contraparte, lo cual no cumple con los requisitos de transferencias de gran cantidad. Al mismo tiempo, tienes un exceso de capacidad de emisión en el canal 1, con un total de 0.9 BTC, pero no necesitarás tanto en el corto plazo. Obviamente, la mejor solución es transferir los fondos excedentes del canal 1 a los otros dos canales. Por lo tanto, planeas transferir 0.4 BTC del saldo local del canal 1 al canal 2, y 0.4 BTC al canal 3. Para lograr esto, necesitarás completar dos pagos circulares.

El método de operación específico es como se muestra en la imagen. Puedes transferir directamente 0.8 BTC a Nodo X, que luego transferirá 0.4 BTC a Y y Z respectivamente, luego Y y Z te transferirán 0.4 BTC cada uno a través del canal 2 y el canal 3, aumentando tu saldo local. De esta manera, tendrás suficientes fondos transferibles para satisfacer futuras transferencias de grandes cantidades.

Al observar el diagrama, es fácil darse cuenta de que la naturaleza del pago circular es transferir dinero a ti mismo, mover tus saldos en diferentes canales y, finalmente, lograr la distribución global de saldos para alcanzar tus resultados deseados, pero este método por sí solo no puede aumentar arbitrariamente el saldo total de ninguna de las partes en el canal. Además, su implementación depende de supuestos como X tiene suficientes fondos transferibles a Y y Z, en otras palabras, los pagos circulares a menudo requieren que los Nodo relevantes tengan reservas de Liquidez.

Los pagos del canal son una forma de implementar el concepto de reequilibrio del canal, y en la práctica, el plan de reequilibrio puede combinarse con otros métodos, como intercambios de submarinos. A continuación, presentamos los intercambios de submarinos (Submarine Swaps), cuyo concepto central es intercambiar fondos on-chain y off-chain sin cerrar el canal, utilizando métodos como HTLC.

El escenario más simple de intercambio de submarinos es depositar en la cadena on-chain, suponiendo que Alice ya ha establecido un canal 1 a 1 con Bob, pero después de un tiempo, el saldo local de Alice se agota y no puede realizar más pagos. En este momento, Alice necesita inyectar más fondos, tiene que cerrar y reiniciar el canal, pero este canal es alquilado, por lo que no sería rentable cerrarlo prematuramente. ¿Entonces, qué se debe hacer?

Si se intercambia a través de un submarino, el proceso será más fácil, pero se necesitará la ayuda de HTLC. En primer lugar, Alice puede generar un número aleatorio R y calcular su hash H®. Después, Alice puede enviar BTC a la DIRECCIÓN de Bob en la cadena, con la condición de desbloqueo limitada por HTLC. Bob debe conocer el preimagen R correspondiente a H® para desbloquear estos BTC en la cadena.

Bob realiza transacciones con Alice a través de un canal fuera de la cadena utilizando HTLC, pero en la dirección inversa: Alice debe proporcionar R para desbloquear el dinero que Bob pagó. Tan pronto como Alice proporcione el valor de R, Bob puede usarlo para desbloquear los BTC bloqueados de Alice en la cadena. Después de eso, el saldo local de Alice en el canal aumenta y el saldo de activos en la cadena disminuye de manera equivalente (ignorando las tarifas), esencialmente un intercambio de 1 a 1 (en la explicación anterior, para facilitar la explicación del principio, no se siguió estrictamente el orden de operaciones convencional de submarinos sumergidos para intercambios simétricos entre fuera de la cadena y en la cadena. En realidad, la mayoría de las veces, una parte crea HTLC fuera de la cadena y la otra crea HTLC simétrico en la cadena).

El escenario anterior se utiliza principalmente para reemplazar el saldo fuera de la cadena de los activos dentro de la cadena, siempre que se ajuste la dirección de la operación de Alice y Bob, se pueda cambiar a una operación de retiro y el saldo fuera de la cadena se pueda convertir en activos dentro de la cadena. ** El intercambio de submarinos está garantizado por la combinación de HTLC y bloqueo de tiempo y otras funciones, ** Incluso si la otra parte se niega a cooperar con usted a la mitad de la paloma, el dinero que bloquea en HTLC también está seguro, porque la otra parte no conoce la Llave secreta que desbloquea HTLC, y después de que expire el bloqueo de tiempo, puede recuperar el capital.

Pero tenga en cuenta que, aunque su capital no será robado en los escenarios anteriores, una de las partes necesita bloquear los fondos on-chain utilizando HTLC, lo que inevitablemente generará desgaste de tarifas. Si la otra parte se echa para atrás, seguramente tendrá un cierto impacto en usted. Para resolver estos problemas, los intercambios submarinos a menudo tienen algunos medios auxiliares de cooperación, como depósitos previos, sistemas de reputación, etc., como medidas de castigo.

Para resumir, la idea central del intercambio de submarinos es permitir el intercambio flexible de activos on-chain/off-chain. Siguiendo esta idea de reequilibrio de canal, se pueden implementar medidas de ajuste de liquidez más óptimas. Aquí vamos a dar un ejemplo simple:

Sin embargo, al resumir los puntos de conocimiento anteriores, no es difícil darse cuenta de que las operaciones de ajuste de Liquidez, como el intercambio de submarinos, la concatenación de canales, el alquiler de canales, dejarán rastros de operaciones on-chain, lo que generará tarifas. Si se realizan este tipo de operaciones con frecuencia, inevitablemente ejercerán presión sobre el costo económico y la experiencia del usuario. Debido a que la Red Lightning de BTC depende de BTC Mainnet, las interacciones on-chain frecuentes no son realistas, mientras que Fiber basado en CKB enfrenta una presión relativamente menor en la gestión de Liquidez, lo que resulta en una experiencia más fluida. Sin embargo, tanto la Red Lightning como Fiber están investigando a fondo soluciones innovadoras de Liquidez, y pueden encontrar un camino más adecuado en el futuro en colaboración activa con equipos de proyectos como Mercury Layer.