El video (a las 28:25) del sitio web oficial de Lightning describe un pago de varios saltos. Entiendo qué es un contrato bloqueado por hash, pero todavía no entiendo por qué necesitamos un aspecto de bloqueo de tiempo aquí. Como puede ver en la diapositiva, en un pago de varios saltos A -> B -> C -> D, (A -> B) tiene un nLockTime de 3 días, (B -> C) tiene un nLockTime de 2 días, y (C -> D) tiene un nLockTime de 1 día. nLockTime de tiempo t significa que la transacción no se puede incluir en un bloque anterior a t. Entonces, a medida que pasa el tiempo, primero (C -> D) se vuelve válido, luego (B -> C) se vuelve válido, luego (A -> B) se vuelve válido.
Joseph Poon dice en 28:35 (énfasis mío):
"El canal de Dave y Carol [...] se cierra primero. Y Carol está contenta con esta configuración, porque sabe que su pago se cierra [...] antes de que se retire su dinero".
¿No es al revés: Dave saca dinero de Carol primero (entre el día 1 y el día 2), y luego Carol saca dinero de Bob?
De todos modos, ¿qué saldría mal si nos deshicieramos de los bloqueos de tiempo por completo? Digamos que Dave genera una R aleatoria, envía H(R) a Alice, Alice crea una transacción bloqueada por hash y se la transmite a Dave a través de Bob y Carol. Si Dave descubre R, todos pueden retirar sus fondos, si no lo hace, nadie puede. ¿Por qué necesitamos bloqueos de tiempo además de eso?
Uso el siguiente escenario para ambas preguntas: Alice quiere pagar 1 BTC a Dave a través de la ruta: Alice -> Bob -> Carol -> Dave
Supongamos que la ruta de pago acaba de establecerse. Significado: Cada salto en la ruta (A, B, C, D) tiene un HTLC con su(s) salto(s) vecino(s). Sin embargo, los HTLC no tendrían ningún límite de tiempo. Ahora Dave envía la R secreta a Carol, quien a su vez envía la R a Bob. Sin embargo, Bob no responde (por ejemplo, porque su nodo falló). Desafortunadamente, Alice no tiene idea de por qué Bob no le envía R. Así que tiene que esperar hasta que Bob vuelva a responder. Ahora eso podría llevar una hora, unos días, unas semanas o tal vez nunca vuelva a responder. El problema de Alice es que el HTLC entre ella y Bob es válido indefinidamente. Por lo tanto, sin un bloqueo de tiempo, el dinero comprometido con este HTLC puede quedarse atascado en un artículo muy largo y Alice no puede hacer nada al respecto.
Los bloqueos de tiempo decrecientes son útiles para saltos intermedios (todos los saltos excepto el primero y el último). En nuestro ejemplo la ruta es:
A -> B -> C -> D
Entonces B y C son los saltos intermedios. Ahora, de acuerdo con los HTLC, un salto intermedio puede reclamar dinero del salto anterior y tiene que pagar dinero al salto siguiente. Por ejemplo: Carol puede reclamar dinero a Bob y tiene que pagarle dinero a Dave.
En términos generales, eso significa: un salto "HOP" debe asegurarse de que después del próximo salto "NEXT" reclame el dinero de HOP, HOP podrá reclamar el dinero del salto anterior "PREV" antes del HTLC entre PREV y HOP está invalidado (se agotó el tiempo de espera). Y una manera fácil de hacerlo es asegurarse de que el bloqueo de tiempo HTLC entre HOP y NEXT sea (significativamente) más bajo que entre HOP y PREV.
Este es un ejemplo de lo que podría suceder si todos los HTLC tuvieran el mismo bloqueo de tiempo. Para este ejemplo asumimos que el bloqueo de tiempo es "T+10 bloques" (T = un número de bloque fijo). Entonces, cuando la altura del bloque está en T + 10 bloques o más tarde, todos los HTLC "agotan el tiempo de espera" y:
Ahora, después de que se haya establecido la ruta de pago, sucede lo siguiente:
Después de un retraso (en los bloques T+8), Dave envía la R secreta a Carol. Al hacer esto, le demostró a Carol que puede (legítimamente) reclamar el dinero de su HTLC. Como ambas partes no quieren cerrar su canal todavía, actualizan el estado del canal en consecuencia. Al hacer esto, Carol acaba de pagar irrevocablemente dinero a Dave.
Sin embargo, Carol aún no ha recibido dinero de Bob. Así que envía R a Bob. ¡Pero Bob no responde! ¡Esto es desafortunado para Alice ya que en 2 bloques (~ 20 minutos) Bob puede recuperar su dinero! Para evitar esto, Carol tiene que cerrar inmediatamente el canal con Bob transmitiendo la Transacción de compromiso que contiene el HTLC. Al mismo tiempo, también tiene que enviar otra "transacción de entrega" que (pretende) transferir el dinero del HTLC (entre ella y Bob) a ella misma. Sin embargo, lamentablemente no hay garantía de que ambas transacciones se incluyan realmente en el siguiente bloque (T+9). Pero si solo se incluye el HTLC en el bloque T+9, Bob puede transmitir su propia "transacción de entrega" que (intenta) transferir dinero desde el HTLC ahora confirmado (a través de la "ruta de tiempo de espera" de la salida) a sí mismo. Así que ahora hay dos "transacciones de entrega" en el mempool que usan la misma salida HTLC. Como sabemos, no se permite el doble gasto. Entonces, solo una de estas transacciones se incluirá en un bloque posterior. Y si se incluye la transacción de Bob, Alice perderá su dinero.
Habiendo dicho todo eso, creo que técnicamente también sería posible realizar pagos de múltiples saltos sin confianza sin disminuir los bloqueos de tiempo. Pero este concepto es probablemente mucho más fácil de implementar y mantener.
Sergei Tikhomirov