¿Las partes en un canal de Lightning Network deben estar en línea?

Estoy pensando en un escenario en el que los usuarios de dispositivos móviles que usan un cliente LN rara vez estarán en línea.

Digamos que Alice abre un canal con Bob y hacen 10 transacciones LN. Después de que Alice haya recibido el 10, se desconecta por más tiempo que el tiempo de vida del canal.

Entonces, si el canal se configuró para que dure 3 días, estará fuera de línea durante, por ejemplo, 5 días.

Mi pregunta es, cuando Alice vuelve a estar en línea, ¿cómo sabe si Bob se comprometió con la cadena de bloques el día 10 y no con una transacción anterior (que es a favor de Bob).

Entiendo que si Alice estuviera en línea, podría verificar este comportamiento por sí misma y comprometer fácilmente el 10 para obtener su dinero. Pero el punto clave aquí es que ella está fuera de línea más tiempo que el tiempo de vida del canal .

¿Hay una solución a esto en LN? Porque, francamente, la mayoría de los usuarios no tendrán un nodo que esté en línea las 24 horas del día, los 7 días de la semana. Y además, no quiero confiar en un tercero para realizar la décima transacción en el momento adecuado, ¿y si no lo hacen? ¿Quién puede decir que también actuarán con honestidad y no cometerán una transacción anterior desde el canal?

Respuestas (2)

La red lightning se compone de canales de pago bidireccionales entre dos nodos. Esto significa que cualquiera de esos nodos debería poder inicializar una transacción en cualquier momento. Estas transacciones requieren que ambas partes participen activamente en la actualización de los contratos inteligentes que mantienen vivo el canal. Si una de las partes no responde, esencialmente está violando el contrato inteligente y está perdiendo el derecho a reclamar cualquiera de los fondos en el canal.

Los clientes que no responden son una responsabilidad para cualquiera que abra un canal. Significa que su bitcoin puede estar inmovilizado en el canal hasta el período de tiempo de espera. Ese bitcoin generalmente se colocaba allí para realizar un pago (que ahora se retrasa) o para ganar tarifas de red por ser un centro de transacciones de otras personas. Un nodo que no responde significa que el canal está desperdiciado. Es similar a un ataque de denegación de servicio, excepto que está inmovilizando bitcoin en lugar de ancho de banda.

Para ilustrar cómo funciona esto, considere que Alice y Bob contribuyeron cada uno con 1 BTC a un canal compartido. Todo el canal ahora tiene un total de 2 BTC, pero tiene un límite en cada dirección. Debido a que Alice solo puso 1 BTC, lo máximo que fluirá de Alice a Bob es 1 BTC. Esto es lo mismo para las transacciones totales de Bob a Alice.

Digamos que ha fluido más dinero de Alice a Bob durante la vida útil del canal, de modo que si se cerrara en este momento, Alice obtendría 0.5 BTC y Bob obtendría 1.5 BTC (excluyendo las tarifas por simplicidad). Ahora digamos que Bob de repente se desconectó, dejando el canal inservible.

Debido a cómo funcionan los contratos inteligentes, Alice tendrá una transacción de bitcoin válida anterior, que fue firmada por Bob, y podría cerrar el canal, dejando a Alice con más de los 0.5 BTC que se le deben. Alice puede transmitir esta transacción a la red de Bitcoin y, después de un período de tiempo de espera, obtendrá el dinero que le corresponde a Bob. Lo único que evita esto es que Bob verá la transacción propagarse en la red y puede enviar la transacción final que tiene (ya firmada por Alice) para obtener su pago completo antes de que la transacción de Alice sea válida. Si Bob no presta atención, Alice puede robar lo que le pertenece por derecho.

La penalización de los nodos que no responden es una característica de Lightning Network, destinada a mantenerla funcional. Al dejar el canal desatendido, Bob le está haciendo un flaco favor a Alice. Hacer que ese comportamiento sea financieramente desastroso es lo que hace que el sistema funcione en primer lugar.

Gracias por la respuesta bien explicada. ¿Qué piensa sobre cómo los usuarios cotidianos utilizarán la red de LN? Como mencioné en la pregunta, imagino a los clientes de LN como aplicaciones móviles con conectividad esporádica. ¿Tendrían que depender de terceros para que se comprometan por ellos cuando están fuera de línea, y cuánto tendría que confiar en ellos? Estoy pensando que los usuarios al menos tendrían que confiar en ellos para realizar transacciones de manera oportuna para invalidar transacciones pasadas, ¿verdad? Esto me parece una gran cantidad de confianza depositada en terceros.
Supongo que los servicios en línea serán populares, aunque hay otras opciones. Los usuarios que solo quieren pagar, y nunca recibir un pago, pueden conectarse a un nodo de puente especial con un canal unidireccional. Este nodo sería un tercero que reenvía los pagos a la red Lightning real. Esto aún podría ser confiable, pero mucho más seguro cuando se trata de desconectarse. Además, los tiempos de espera y las brechas entre los tiempos de espera pueden afectar en gran medida la frecuencia con la que debe conectarse. Todos estos problemas tienen soluciones y mitigaciones.
Ok, pero mi principal preocupación es: ¿todavía tienes que confiar en estos terceros o hay alguna forma de mitigar eso? Y si es así, ¿cómo?
Con los servicios, siempre debe confiarles tanto dinero como el que administran en su nombre. Es como guardar dinero en un intercambio. Si elige tener la comodidad de desconectarse con canales abiertos, entonces el riesgo de terceros es el precio que paga. Esto es lo mismo que con cualquier billetera web. Estás intercambiando desconfianza por conveniencia.

Sí, debes estar en línea. La solución es que Alice tenga un servidor propio (sin necesidad de confiar en un tercero), ya sea en casa o en la nube (aws, azure), que llevaría un registro de todas las transacciones de su canal y monitorearía el btc red 24/7 en caso de que la otra parte cierre el canal. De esta manera, puede desconectarse y no preocuparse porque el servidor hará el seguimiento por ella. De ninguna manera puede hacer eso solo con su celular (en mi humilde opinión).

¿Las partes en un canal de Lightning Network deben estar en línea?
RespuestasAquíPolítica de privacidad1y, 0v