El costo de reiniciar un canal de rayos

Tengo algunas preguntas sobre el costo de mantener un canal de rayos entre dos personas. Para esta pregunta, supongamos que la tarifa de minería de blockchain es de $ 1 por transacción.

Pregunta 1 : Supongamos que Alice quiere enviar a Bob 1 mBTC por día, durante 100 días. Sin rayos, esto habría costado $100. Con un relámpago, tiene que abrir un canal a Bob y, después de 100 días, cerrar el canal. ¿Es cierto que abrir el canal y cerrar el canal cuesta cada uno $1, por lo que el costo total es de $2?

Pregunta 2 : Supongamos que Alice quiere enviar a Bob 1 mBTC por día, durante 200 días, pero ahora no tiene todos los 200 mBTC; solo tiene 100 mBTC (recibirá los 100 mBTC adicionales después de 100 días). Entonces, ella tiene que abrir un canal a Bob, después de 100 días cerrar el canal, abrir un nuevo canal y después de 100 días adicionales, cerrar el segundo canal. ¿Es cierto que el costo total ahora es de $4?

Pregunta 3 : Supongamos que Alice de la pregunta 2 quiere reducir el costo del reinicio del canal, por lo que le dice a Bob: "En lugar de cerrar y volver a abrir el canal, te enviaré 100 mBTC a través de la cadena de bloques y tú me enviarás 100 mBTC a través del canal Lightning, por lo que el reinicio solo nos costará $1 y el costo total será de solo $3". ¿Se puede hacer este truco de forma segura, de modo que ni Alice ni Bob puedan hacer trampa?

Respuestas (2)

Pregunta 1

¿Es cierto que abrir el canal y cerrar el canal cuesta cada uno $1, por lo que el costo total es de $2?

Sí. Aún necesitará transacciones de apertura y cierre para el canal, y deberá pagar la tarifa de red por cada transacción.

Pregunta 2

Entonces, ella tiene que abrir un canal a Bob, después de 100 días cerrar el canal, abrir un nuevo canal y después de 100 días adicionales, cerrar el segundo canal. ¿Es cierto que el costo total ahora es de $4?

Tal vez. Si estuviera hablando de un canal de pago de una sola dirección, la respuesta sería sí, pero los canales de rayos son bidireccionales. Un canal solo tiene tanto dinero para empezar. En sus situaciones, asumimos que Alice está aportando todo el dinero por adelantado para el canal, pero esto no tiene por qué ser así. Fácilmente podrían ser tanto Alice como Bob quienes dividan los fondos que están inmovilizados en su canal. Digamos que ambos ponen 100 mBTC para abrir el canal. Ahora, lo máximo que puede viajar en cualquier dirección es 100 mBTC, por lo que si el dinero solo fluye de Alice a Bob, entonces se tendrá que abrir un nuevo canal cuando se envíe todo el dinero inicial de Alice.

Lo que ha olvidado es que en Lightning Network, Alice y Bob no son solo nodos terminales... también son centros. Otras transacciones de otras partes se pueden enrutar a través de su canal. Así que digamos que durante este período de tiempo, Dave quiere pagarle a Charlie. Dave tiene un canal con Bob y Charlie tiene un canal con Alice. Ahora nuestra red se ve así:

Charlie <----> Alice <----> Bob <----> Dave

Debido a que los pagos de Dave a Charlie devolvieron dinero al lado del canal de Alice, Alice podría muy bien pagarle a Bob los 200 mBTC completos sin tener que cerrar y volver a abrir el canal. Esta es efectivamente la forma en que el sistema bancario tradicional liquida las transacciones utilizando la liquidación neta diferida .

También es importante tener en cuenta que si el canal se desequilibra, Alice y Bob pueden incentivar el enrutamiento en una dirección al reducir la tarifa que cobran por usar su canal. Como puede ver, a menudo incluso les conviene cobrar una tarifa negativa en lugar de incurrir en los costos de reabrir un canal.

Pregunta 3:

"En lugar de cerrar y volver a abrir el canal, te enviaré 100 mBTC a través de la cadena de bloques y tú me enviarás 100 mBTC a través del canal Lightning. Por lo tanto, reiniciar solo nos costará $ 1 y el costo total será de solo $ 3 ". ¿Se puede hacer este truco de forma segura, de modo que ni Alice ni Bob puedan hacer trampa?

Con suerte, podría evitar esta situación como se ilustra arriba. Si no, parece que Alice y Bob tendrán que 1) confiar el uno en el otro, o 2) tener algún otro tipo de contrato inteligente (lo que probablemente generaría aún más tarifas de transacción, no menos). No veo esto como una solución viable o rentable. Sería mejor incentivar a otros a usar el canal para restaurar fondos en el lado del canal de Alice.

¿Puede dar más detalles sobre la "tarifa negativa"?
@Richard, suena loco, pero significa que el canal le paga a alguien por su tráfico. Digamos que Dave quiere pagarle a Charlie 50 mBTC. El estado actual del canal Alice-Bob (si lo cerraran ahora) tiene 10 mBtc propiedad de Alice y 90 mBtc propiedad de Bob. Si Alice todavía tiene 30 mBTC que quiere pagar a Bob, pueden aceptar cubrir parte del pago de Dave, solo para que use su canal. Dave ahora paga 49 mBTC, Charlie recibe 50 mBTC y el canal ahora se divide Alice-60, Bob-40. La diferencia probablemente provino del canal de Alice con Charlie, y Alice ahora puede terminar de pagarle a Bob.

La respuesta de Jestin hace un gran trabajo al cubrir las preguntas 1 y 2, pero me gustaría agregar que puede usar un intercambio submarino para vincular un pago en Lightning Network (LN) a un pago en cadena. Los intercambios de submarinos utilizan un contrato inteligente en el pago en cadena que se vuelve válido junto con el secreto de una factura de LN. Este contrato inteligente es similar a los HTLC que se utilizan en los pagos de LN de varios saltos.