Estoy tratando de entender la tecnología detrás de LN y conceptos similares.
Según tengo entendido, LN es una red de canales bidireccionales, que se crean con una capacidad limitada, dentro de la cual el canal puede operar. Entonces, podemos hacer que Alice ponga 3 monedas en el canal y Bob ponga 20 monedas en el canal y esta proporción de 3:20 puede cambiar con el tiempo con cada pago fuera de la cadena, hasta que finalmente llegue al punto en el que Alice y Bob quieran cierre el canal en alguna relación de balance final, digamos 13:10.
Este concepto bidireccional tiene algunas características (o desventajas) de, por ejemplo, el requisito de equilibrar el canal (o crear uno nuevo) si los pagos en una dirección son más comunes. Además, cada uno de esos canales que conectan a dos partes necesita dos transacciones en cadena.
Preguntas: ¿Por qué usamos canales solo entre 2 partes? ¿No sería posible tener un canal formado, por ejemplo, por 4 partes, por ejemplo, Alicia con 3 monedas, Bob con 4 monedas, Cecil con 5 monedas y Daniel con 6 monedas? Debería permitirle a Alice enviar, por ejemplo, 2 monedas a Bob, modificando así el estado del canal de "A3:B4:C5:D6" a "A1:B6:C5:D6", etc.
Si esto fuera posible, podríamos tener 2 transacciones en cadena para interconectar 4 (o más) entidades, por lo que parece que sería más efectivo que el enfoque bidireccional. También me parece que mantener el canal equilibrado sería un poco más fácil que en el caso de un caso bidireccional.
Obviamente, se necesitaría más comunicación para cada transacción fuera de la cadena dentro del canal (probablemente todas las partes tendrían que estar involucradas).
Entonces, ¿hay algún problema fundamental con tener más de 2 entidades en un canal? ¿O es solo que los beneficios de tenerlos no superarían la complejidad adicional?
No hay una razón fundamental por la que no pueda usar un enlace no bidireccional. El protocolo de enrutamiento de cebolla de Lightning ignora el canal entre dos nodos. Hipotéticamente, si dos nodos de rayos estuvieran uno al lado del otro, los brazos robóticos podrían pasar centavos de un lado a otro en lugar de un canal de rayos.
Dicho esto, ¿funcionaría un canal lightning no bipartito o permitiría que un participante del canal defraudara a otro?
Lightning normal funciona así: antes de que Alice y Bob creen un canal, Alice firma la transacción de reembolso de Bob y Bob firma la transacción de reembolso de Alice. La transacción de reembolso de Alice dice:
Output 0: 1 BTC can be claimed by Alice, only after 48 hours, OR
can be claimed by Bob, if Bob knows P, where hash(P) = x
Output 1: 1 BTC can be claimed by Bob
Si Alice decide que quiere salir del canal, publica la transacción anterior, espera 48 horas y reclama su dinero. Ahora que tenemos una manera de finalizar el canal, Alice y Bob pagan conjuntamente en una transacción que se puede gastar en las transacciones de reembolso o en cualquier transacción que Alice y Bob firmen conjuntamente.
Eso es genial, pero ¿cómo mueves el dinero? Primero, Alice y Bob crean nuevas transacciones de reembolso para reflejar el nuevo estado del canal. Luego, Alice le dice a Bob P, el valor por encima de ese hash a x. Si Alice intentara enviar esa transacción a la red Bitcoin ahora, Bob respondería tomando todo el dinero en el canal.
Aquí es donde nos encontramos con nuestro primer obstáculo. Si hay tres partes con dinero en el canal y Alice hace trampa, obviamente es injusto para Charlie que Bob tome todo el dinero restante. ¿Cómo arreglamos esto?
Si Alice usa su transacción de reembolso, pasamos a una versión bipartita del protocolo Lightning. Hacemos esto ya sea que Alice haga trampa o no usando una transacción de reembolso anterior. El reembolso de Alice ahora se ve así:
Output 0: 0.33 BTC can be claimed by Alice, only after 48 hours, OR
can be claimed by Bob and Charlie, if they know P, where hash(P) = x
Output 1: 0.67 BTC can be claimed by Bob and Charlie
Sin embargo, no hemos terminado. Cuando Alice usa su transacción de reembolso, Charlie podría estar desconectado. (De hecho, esa podría ser la razón por la que Alice abandona el canal Lightning). Por lo tanto, tanto Bob como Charlie deben crear una transacción de subreembolso antes de financiar el canal. Bob firma la transacción de Charlie y viceversa. La transacción de Bob se ve así:
Output 0: 0.33 BTC can be claimed by Bob, only after 48 hours, OR
can be claimed by Charlie, if they know P, where hash(P) = x
Output 1: 0.34 BTC can be claimed by Charlie
El resultado es que si tiene n personas participando, necesita n transacciones de reembolso, n-1 transacciones de sub-reembolso y n-2 transacciones de sub-sub-reembolso. Esto crece factorialmente, por lo que si tienes 10 participantes, estimo que debes firmar y revocar alrededor de 3,6 millones de transacciones por cada actualización del canal. Esto cubrirá todos los posibles ordenamientos de los nodos que salen del canal.
Si está dispuesto a intercambiar algo de seguridad, podría hacer que 5 nodos Lightning creen una cuenta de firmas múltiples de 3 de 5 y solo permitan retiros de esa cuenta si 3 nodos acordaron que el retiro fue realizado por un nodo con suficiente saldo. Si está interesado en esto, le sugiero que consulte la vinculación federada.
muro