Create ln-07.md
This commit is contained in:
Bitcoin Txoko
+166
@@ -0,0 +1,166 @@
|
||||
- Título: LN capítulo 7 - Operación normal de un canal LN pre-taproot
|
||||
- Resumen:
|
||||
|
||||
---
|
||||
|
||||
### Contenidos
|
||||
- [Visión general](#visión-general)
|
||||
- [Preliminares](#preliminares)
|
||||
- [Operación normal del canal](#operación-normal-del-canal)
|
||||
- [Configuración](#configuración)
|
||||
- [Añadiendo un HTLC](#añadiendo-un-htlc)
|
||||
- [Paso 1: Alice -> Bob: update_add_htlc(A1)](#paso-1)
|
||||
- [Paso 2: Alice -> Bob: update_add_htlc(A2)](#paso-2)
|
||||
- [Paso 3: Bob -> Alice: update_add_htlc(B1)](#paso-3)
|
||||
- [Comprometiéndose al estado actual](#comprometiéndose-al-estado-actual)
|
||||
- [Paso 4: Alice -> Bob: commitment_signed](#paso-4)
|
||||
- [Paso 5: Bob -> Alice: revoke_and_ack](#paso-5)
|
||||
- [Paso 6: Alice -> Bob: update_add_htlc(A3)](#paso-6)
|
||||
- [Paso 7: Bob -> Alice: commitment_signed](#paso-7)
|
||||
- [Paso 8: Alice -> Bob: revoke_and_ack](#paso-8)
|
||||
|
||||
### Visión general
|
||||
|
||||
En este capítulo cubriremos las operaciones normales de un canal. Esto implica entender cómo se añaden HTLCs a un canal y cómo los pares del canal se comprometen a un nuevo estado para incluir estos HTLCs. Luego cubriremos cómo se restablece el flujo normal de un canal después de una desconexión. Finalmente, cubriremos el flujo de cierre cooperativo del canal. Por cierto, todos estos temas están cubiertos en [BOLT2](https://github.com/lightning/bolts/blob/master/02-peer-protocol.md).
|
||||
|
||||
### Preliminares
|
||||
|
||||
Aquí hay algunos conceptos y flujos que hemos cubierto anteriormente en nuestra serie que podrían ser útiles para entender este capítulo. No dudes en volver a leerlos si necesitas un recordatorio.
|
||||
|
||||
- [Actualización de estado]: por qué los pares del canal tienen un estado asimétrico y cómo actualizan este estado de manera confiable.
|
||||
- [Profundización en HTLC]: cómo se ven las salidas de HTLC en una transacción de compromiso.
|
||||
- [Apertura y anuncio de un canal LN pre-taproot]: cómo dos nodos abren un canal.
|
||||
|
||||
### Operación normal del canal
|
||||
|
||||
#### Configuración
|
||||
|
||||
Alice y Bob han abierto su canal con éxito. Ambos han visto que la transacción de financiación está confirmada y han intercambiado el mensaje `channel_ready` entre ellos para indicar que están listos para usar el canal. El estado de sus transacciones de compromiso asimétricas actualmente se ve así:
|
||||
|
||||
|
||||
|
||||
Ambas transacciones de compromiso gastan la salida de la transacción de financiación multisig 2-de-2. Dado que es un multisig 2-de-2, gastar de esta salida requiere firmas de ambos pares. Las firmas están representadas por las dos cajas en la parte superior de las transacciones de compromiso. Puedes ver en el diagrama que la transacción de compromiso de Alice tiene una firma de Bob representada por la caja azul; Bob tiene una firma de Alice para su transacción de compromiso representada por la caja verde. Cada transacción de compromiso también tiene las salidas `to_local` y `to_remote` que pagan a las partes respectivas su saldo actual del canal. Tanto Alice como Bob pueden firmar sus propias transacciones de compromiso en cualquier momento y transmitirlas a la red de Bitcoin. Esto sería un **cierre forzado**.
|
||||
|
||||
Con el fin de hacer que los próximos diagramas sean más fáciles de seguir, ignoraremos las transacciones de financiación así como las salidas `to_local` y `to_remote` por un tiempo, ya que nuestro enfoque inicial estará en añadir y eliminar salidas de HTLC. Así que el diagrama anterior ahora se simplifica a esto:
|
||||
|
||||
|
||||
|
||||
- Una transacción de compromiso _roja_, mostrada a continuación, representa transacciones de compromiso pasadas y revocadas. Si Alice o Bob firmaran y transmitieran una de estas, entonces la otra parte podría barrer todos sus fondos. Así que estas transacciones revocadas pueden considerarse efectivamente inválidas.
|
||||
- Una transacción de compromiso _amarilla_ representa el último conjunto válido de transacciones de compromiso. Estas son las transacciones de compromiso que se transmitirían en un cierre forzado.
|
||||
- Finalmente, cada lado tiene lo que se puede considerar un "área de preparación" donde se pueden proponer cambios a la transacción de compromiso. Más adelante, cualquiera de los lados puede decidir cuándo quiere que su contraparte se comprometa a los cambios en su transacción de compromiso de preparación.
|
||||
|
||||
Sugerencia: si te gusta git, esto es muy parecido a un flujo de trabajo de git. Los commits pasados están desactualizados, pero cuentan una buena historia de lo que sucedió. Tus últimos cambios comprometidos representan el estado actual de tu proyecto. Cualquier cambio que aún no esté comprometido está en preparación.
|
||||
|
||||
|
||||
|
||||
#### Añadiendo un HTLC
|
||||
|
||||
Cuando Alice o Bob quieren enviar un pago, necesitarían proponer la inclusión del HTLC a su par de canal. Esto se hace con el mensaje `update_add_htlc`:
|
||||
|
||||
|
||||
|
||||
Aquí hay una tabla sobre lo que significa cada uno de los campos del mensaje:
|
||||
|
||||
| Campo | Descripción|
|
||||
|---|---|
|
||||
| channel_id | utilizado para comunicar en qué canal debe tener lugar este cambio. |
|
||||
| id | un identificador que siempre incrementa para este cambio propuesto del remitente. |
|
||||
| amount_msat | la cantidad que debe adjuntarse a la salida de HTLC. |
|
||||
| cltv_expiry | la altura del bloque en la que el HTLC debe expirar. |
|
||||
| onion_routing_packet y blinding_point | datos que el destinatario del HTLC utilizará para determinar a dónde enviar el pago a continuación. |
|
||||
|
||||
Hay un punto contraintuitivo a tener en cuenta aquí: el remitente de este mensaje aún no coloca esta actualización en su propia área de preparación. Esto se debe a que la actualización aún está "pendiente del receptor" porque el remitente aún no ha recibido ningún reconocimiento del receptor para la nueva actualización. Imagina este escenario: el remitente envía una actualización y luego recibe inmediatamente un mensaje `commitment_signed` (más detalles sobre esto más adelante). En este caso, no debería haber ambigüedad sobre qué actualizaciones están incluidas en la transacción que se está firmando. Esperemos que esto tenga más sentido a medida que trabajemos a través del ejemplo.
|
||||
|
||||
##### Paso 1: Alice -> Bob: update_add_htlc(A1)
|
||||
|
||||
Supongamos que Alice envía a Bob un `update_add_htlc`. Llamemos a este HTLC `A1` porque es el primero que Alice (A) está enviando a Bob. Si Bob está contento con todos los campos en el mensaje, entonces añade el HTLC a su transacción de compromiso en el área de preparación y Alice marca el HTLC como pendiente en el lado de Bob, pero aún no lo añade a su propia transacción de compromiso en preparación.
|
||||
|
||||
|
||||
|
||||
Ten en cuenta que ninguno de los lados ha comprometido realmente este HTLC aún, así que si Bob es un nodo de enrutamiento para este pago, no debería enviar aún `update_add_HTLC` al siguiente salto en la ruta hasta que `A1` haya sido _irrevocablemente_ comprometido. La adición o eliminación de un HTLC solo se considera irrevocablemente comprometida una vez que ambas partes en el canal se han comprometido a la transacción de compromiso con o sin él.
|
||||
|
||||
Esto no se muestra en el diagrama simplificado, pero en realidad la salida principal de Alice en la transacción de compromiso en preparación de Bob (es decir, la salida `to_remote`) ahora tendrá el valor del HTLC añadido restado (junto con las tarifas para cubrir la salida extra). Si el HTLC termina teniendo éxito, entonces esta cantidad se añadirá a la salida de Bob y si termina fallando, entonces se volverá a añadir a la salida de Alice.
|
||||
|
||||
##### Paso 2: Alice -> Bob: update_add_htlc(A2)
|
||||
|
||||
A pesar de que aún no se han comprometido al HTLC `A1`, esto no les impide añadir más cambios al área de preparación. Alice está más que bienvenida a proponer un nuevo HTLC, `A2`, a Bob:
|
||||
|
||||
|
||||
|
||||
##### Paso 3: Bob -> Alice: update_add_htlc(B1)
|
||||
|
||||
Del mismo modo, Bob puede sugerir un cambio, `B1`, a Alice:
|
||||
|
||||
|
||||
|
||||
#### Comprometiéndose al estado actual
|
||||
|
||||
En algún momento, uno de los pares querrá asegurarse de que el otro par se haya comprometido al último conjunto de cambios y revocar el estado válido anterior. Esto se hace enviando el mensaje `commitment_signed`:
|
||||
|
||||
|
||||
|
||||
|
||||
| Campo | Descripción|
|
||||
|---|---|
|
||||
| channel_id | utilizado para comunicar en qué canal debe tener lugar este cambio. |
|
||||
| signature | la firma del remitente para la transacción de compromiso del área de preparación de la parte remota. |
|
||||
| num_htlcs | el número de HTLCs que el remitente espera que estén en la transacción de compromiso remota. |
|
||||
| htlc_signatures | un array de firmas de num_htlcs que son las firmas del remitente para cada una de las transacciones de HTLC de segundo nivel que la parte remota necesitaría transmitir si alguna vez tuviera que cerrar el canal forzosamente. |
|
||||
|
||||
Sugerencia: si necesitas un recordatorio sobre las transacciones de HTLC de segundo nivel y por qué son necesarias, consulta este [capítulo].
|
||||
|
||||
##### Paso 4: Alice -> Bob: commitment_signed
|
||||
|
||||
Supongamos que Alice envía este mensaje a Bob. Bob ahora tendrá todas las firmas requeridas de Alice para transmitir su transacción de compromiso en el área de preparación:
|
||||
|
||||
|
||||
|
||||
Observa que Alice sabía que su firma necesitaría cubrir los HTLCs `A1` y `A2`. Esto está bien porque el [transporte subyacente](https://github.com/lightning/bolts/blob/master/08-transport.md) está garantizado para ser confiable y ordenado, lo que significa que si Bob recibiera el mensaje `commitment_signed` de Alice, entonces significa que definitivamente recibió sus mensajes `update_add_htlc` para `A1` y `A2`. Alice y Bob saben que la firma no debería cubrir el HTLC `B1` ya que Alice no ha enviado un reconocimiento para él aún.
|
||||
|
||||
Otra cosa a notar es que Bob ahora tiene en realidad dos transacciones de compromiso válidas ya que aún no ha revocado su estado anterior. Sin embargo, está incentivado a revocar su transacción de compromiso anterior ya que los HTLCs en el nuevo estado son uno de los siguientes:
|
||||
- Pagos a Bob mismo, lo que significa que se beneficia de comprometerse al nuevo estado. Si no se compromete al nuevo estado, entonces Alice tampoco lo hará y por lo tanto aún existiría una versión de una transacción de compromiso que no paga a Bob sus fondos entrantes.
|
||||
- De manera similar al punto anterior, si Bob está enrutando un pago, entonces también está incentivado a comprometer irrevocablemente el HTLC ya que ganaría tarifas de enrutamiento si el pago tiene éxito.
|
||||
- Finalmente, si Bob está haciendo el pago él mismo, entonces el primer estado sería de hecho más rentable para él ya que tiene menos fondos en el segundo estado. Sin embargo, el comerciante al que Bob está haciendo el pago no liberará los bienes que se están comprando a menos que primero se reciban los fondos, lo que no sucederá si Alice no pasa el HTLC, lo cual no hará a menos que se haya comprometido irrevocablemente. Así que nuevamente, Bob está incentivado a revocar su estado anterior.
|
||||
|
||||
##### Paso 5: Bob -> Alice: revoke_and_ack
|
||||
|
||||
En respuesta al `commitment_signed` de Alice, Bob envía el mensaje `revoke_and_ack`:
|
||||
|
||||
|
||||
|
||||
- El `per_commitment_secret` proporciona a Alice la información que necesita para poder gastar cualquier ruta de revocación en el estado previamente válido de Bob. Consulta el [capítulo de revocación] para más detalles sobre cómo funciona la revocación.
|
||||
- El `next_per_commitment_point` le da a Alice la información que necesita para derivar la clave pública de revocación que se utilizará en la próxima transacción de compromiso de Bob.
|
||||
|
||||
Una vez que Alice recibe este mensaje, la transacción de compromiso anterior de Bob ha sido revocada con éxito. Ten en cuenta que este mensaje reconoce explícitamente el mensaje `commitment_signed` enviado por Alice y, por extensión, dado que la entrega de mensajes es confiable y ordenada, también reconoce implícitamente los mensajes `update_add_htlc` que Alice envió para `A1` y `A2`. Por lo tanto, Alice puede finalmente añadir `A1` y `A2` a su transacción de compromiso en el área de preparación ya que ya no están pendientes en el lado de Bob:
|
||||
|
||||
|
||||
|
||||
Ahora podemos limpiar un poco el diagrama:
|
||||
|
||||
|
||||
|
||||
En el último diagrama, observa que las últimas transacciones de compromiso de Alice y Bob están en realidad desincronizadas. Esto está bien ya que ninguna de las actualizaciones se ha comprometido irrevocablemente aún. Eso podría parecer difícil de creer ya que las transacciones de compromiso se ven tan diferentes, así que vamos a repasar las consecuencias de que cualquiera de estas transacciones termine en la cadena desde la perspectiva de ambos lados.
|
||||
|
||||
- Desde la perspectiva de Alice:
|
||||
- si su transacción de compromiso se transmitiera, recuperaría su cantidad original `to_local`.
|
||||
- si la transacción de compromiso de Bob se transmitiera, entonces los HTLCs ofrecidos por Alice (como `A1` y `A2`) estarían en la cadena. Para los HTLCs ofrecidos, Alice está enviando sats _fuera_, lo que significa que su `to_local` sería menor. Pero, si Bob era un nodo de enrutamiento para estos HTLCs, entonces no los habría reenviado ya que aún no están comprometidos irrevocablemente, lo que significa que no recibiría las pre-imágenes requeridas para reclamar estos HTLCs y, por lo tanto, Alice podría recuperar sus fondos a través de la ruta de tiempo de espera. Si Bob era el destinatario de estos HTLCs, entonces podría producir la pre-imagen para reclamar los HTLCs, pero entonces Alice vería la pre-imagen en la cadena y podría reclamar los HTLCs entrantes de su canal entrante y así habría ganado tarifas de enrutamiento.
|
||||
|
||||
- Desde la perspectiva de Bob:
|
||||
- si la transacción de compromiso de Alice se transmite, Bob recupera sus fondos a través de la salida `to_remote`.
|
||||
- si Bob tuviera que cerrar forzosamente a través de su transacción de compromiso, entonces los HTLCs ofrecidos a él (como `A1` y `A2`) estarían en la cadena. Si Bob estaba enrutando estos HTLCs, entonces no los habría reenviado ya que aún no están comprometidos irrevocablemente. Así que no podría reclamar la ruta de éxito, pero eso está bien ya que los fondos para estos no salieron de su saldo. Si Bob era el destino final para estos, entonces podría reclamarlos a través de la ruta de éxito.
|
||||
|
||||
##### Paso 6: Alice -> Bob: update_add_htlc(A3)
|
||||
|
||||
Queremos ser muy claros sobre el punto de que las transacciones de compromiso pueden permanecer desincronizadas indefinidamente y que Bob no necesita enviar `commitment_signed` solo porque Alice lo hizo. Así que, para el sake de otro ejemplo, supongamos que Alice en este punto envía otro HTLC, `A3`, a Bob:
|
||||
|
||||
|
||||
|
||||
##### Paso 7: Bob -> Alice: commitment_signed
|
||||
|
||||
Bob quiere comprometer irrevocablemente algunos de los HTLCs para poder reenviarlos, así que finalmente envía a Alice un `commitment_signed` propio. Esto incluirá su firma para la transacción de compromiso del área de preparación de Alice junto con todas las firmas requeridas de él para las salidas de HTLC de segundo nivel.
|
||||
|
||||
|
||||
|
||||
##### Paso 8: Alice -> Bob: revoke_and_ack
|
||||
|
||||
Al igual que Bob hizo anteriormente, Alice responde al `commitment_signed` con un `revoke_and_ack` para revocar su estado anterior. Esto también sirve como un reconocimiento para Bob de que Alice ha recibido y se ha comprometido a `B1`, por lo que Bob ahora
|
||||
Reference in New Issue
Block a user