Canales de Pago (en profundidad)
Financiación, transacción de compromiso, revocación y cierre
-
Eric de Castro - Atualizado em
⚡ Lightning · Técnico
En la versión para principiantes hablamos del canal como una "cuenta". Aquí vamos a ver qué pasa al nivel de las transacciones Bitcoin: cómo el canal se ancla on-chain, cómo el saldo se representa y actualiza, y por qué hacer trampa no compensa.
La transacción de financiación (funding)
Abrir un canal es crear una salida multisig 2-de-2 en la blockchain — normalmente una P2WSH cuyo script es:
OP_2 <pubkey_alice> <pubkey_bob> OP_2 OP_CHECKMULTISIGEsa salida es la transacción de financiación. El valor depositado en ella es la capacidad del canal, y nadie puede mover ese dinero sin la firma de los dos. El par txid:índice_de_salida de esa salida identifica el canal para siempre — es el channel point.
Tradicionalmente solo un lado financia el canal (single-funded), pero también existe la financiación por ambos (dual funding). De cualquier forma, es una única transacción on-chain la que da origen al canal.
La transacción de compromiso (commitment)
El saldo actual del canal se representa mediante una transacción de compromiso: una transacción que gasta la salida de financiación y divide el dinero entre los dos. No se publica mientras el canal está abierto — es la carta bajo la manga de cada lado para cerrar el canal en cualquier momento en el estado actual.
El detalle crucial: cada lado guarda su propia versión, y son asimétricas. La versión de Alice tiene estas salidas:
to_remote→ paga a Bob inmediatamente (su saldo).to_local→ paga a Alice, pero con un retraso (to_self_delay, un timelock relativo vía OP_CHECKSEQUENCEVERIFY) y de una forma que puede ser revocada.- una salida para cada HTLC pendiente (veremos los HTLCs en la próxima página).
En la versión de Bob es el espejo: su to_local es el que queda retrasado y revocable. En otras palabras: quien publica la transacción de compromiso es quien espera — su propio dinero queda bloqueado por el to_self_delay, mientras el del otro lado sale al instante.
Prueba un estado de canal y ve las salidas que cada lado ve:
Transacción de Compromiso
Transacción de Compromiso
Revocación y penalidad
Cada vez que el saldo cambia, ambos crean una nueva transacción de compromiso y invalidan la anterior. Pero, ¿cómo se invalida una transacción que ya está firmada y sería válida en la blockchain?
La respuesta es la revocación. La salida to_local no puede gastarse solo por el dueño — tiene dos caminos:
- por el dueño, pero solo después del
to_self_delay; o - por quien tenga la clave de revocación de ese estado, de inmediato.
En cada actualización, cada lado entrega al otro el secreto de revocación del estado anterior. Con ese secreto, la clave de revocación del estado antiguo pasa a ser derivable por la contraparte. Resultado: si Alice intenta publicar un estado antiguo (revocado) — por ejemplo, uno en el que tenía más saldo — Bob tiene la ventana del to_self_delay para usar la clave de revocación y barrer todo el to_local de ella. Sumando el to_remote que ya es suyo, Bob se queda con todo el canal.
Por eso hacer trampa es irracional: la penalización es perder todo. Ese mecanismo es lo que permite que dos desconocidos mantengan un canal sin confiar el uno en el otro.
Cierre del canal
Hay tres formas de que un canal termine:
- Cierre cooperativo (mutual close). Ambos están de acuerdo y firman juntos una transacción de cierre simple, que paga a cada uno al instante — sin timelock y con comisión baja. Es el camino feliz.
- Cierre forzado (force close). Si el otro lado desapareció o no coopera, publicas la tu última transacción de compromiso. Funciona, pero tu dinero queda bloqueado por el
to_self_delay(y la comisión es mayor). - Ruptura de contrato (breach). Publicar un estado revocado activa la penalidad descrita arriba — pierdes todo.
Detalles que han evolucionado
El diseño de arriba es el "clásico". Vale la pena saber que el protocolo avanzó:
- Anchor outputs. Salidas extra pequeñas en la transacción de compromiso que permiten aumentar la comisión después (CPFP), algo importante cuando las tasas on-chain se disparan en un cierre forzado.
- Canales Taproot (simple taproot channels). Una evolución más reciente que usa Taproot y firmas MuSig2 para hacer los canales más privados y baratos on-chain (el multisig 2-de-2 se convierte en una sola clave, indistinguible de un gasto común).
A continuación: cómo el dinero realmente se mueve por un canal y a través de varios — los HTLCs y el encaminamiento de pagos.