Bitcoin 101: qué es la red Lightning

La respuesta corta

Lightning es una red de canales de pago entre dos partes. Dos personas colocan monedas en una sola salida de Bitcoin que necesita las dos firmas para gastarse, y a partir de ahí reescriben el reparto entre ellas tantas veces como quieran sin publicar nada. Solo la apertura y el cierre del canal tocan la cadena.

Pagarle a alguien con quien no hay un canal funciona retransmitiendo el pago a través de canales que otras personas ya tienen, bajo una condición que liquida el camino entero o lo deshace por completo.

Todo lo que sigue es cómo está construido eso en realidad, y cuánto cuesta.

Por qué la cadena es un mal lugar para un pago chico

Una comisión de Bitcoin es el tamaño de la transacción multiplicado por una tasa. Nada en ese cálculo se refiere al monto enviado, así que un pago de unos cientos de satoshis cuesta lo mismo que un pago de varios bitcoin, dada la misma forma de transacción. El mempool no es una cola tiene la contabilidad, y Bitcoin no tiene saldos, solo salidas no gastadas explica por qué lo que se paga es la cantidad de monedas que se gastan y no su valor.

Después está la espera, que llega según el calendario de la red y no el de quien compra.

Ninguna de las dos cosas es un defecto. Es lo que cuesta un registro global, ordenado y permanente, en el que cada nodo del planeta guarda una copia de un café ajeno. La premisa de Lightning es que la mayoría de los pagos no necesitan estar en ese registro. Solo hacen falta las posiciones de apertura y de cierre.

Un canal es una salida compartida y una pila de transacciones que nadie difunde

Abrir un canal empieza con una transacción on-chain común, la transacción de financiamiento. Su salida de canal es un multisig 2 de 2. La especificación es exacta sobre el script: "el script de la salida de financiamiento es un P2WSH a 2 <pubkey1> <pubkey2> 2 OP_CHECKMULTISIG" ("The funding output script is a P2WSH to"), con las dos claves ordenadas lexicográficamente (BOLT 3, Funding Transaction Output). Una vez que confirma, ninguna de las partes puede mover el dinero sola.

Lo que vuelve eso utilizable, en lugar de simplemente trabado, es la segunda mitad. Cada lado guarda una transacción de compromiso, firmada por ambos, que gasta la salida de financiamiento devolviéndola a los dos en la proporción actual. BOLT 5 dice qué es: "una transacción de compromiso firmada por ambas partes, que describe el estado actual del canal (básicamente, el saldo actual). Esta transacción de compromiso se actualiza cada vez que se hace un pago nuevo y es gastable en todo momento" (BOLT 5).

No se difunde. Queda en el disco de cada lado como el derecho permanente a terminar el canal en los términos de hoy sin la cooperación de nadie, y ese derecho sin ejercer es lo que vuelve seguro todo lo demás.

Las dos copias no son idénticas. En la copia que guarda cada parte, la salida propia queda gravada por un bloqueo temporal relativo OP_CHECKSEQUENCEVERIFY de to_self_delay bloques, mientras que la salida de la contraparte es gastable de inmediato. La especificación es directa sobre el motivo: "si el nodo local publica su transacción de compromiso, tendrá que esperar para reclamar sus propios fondos, mientras que el nodo remoto tendrá acceso inmediato a los suyos" (BOLT 5). Terminar el canal de forma unilateral es, deliberadamente, la opción más lenta para quien lo hace.

Mover saldo es un intercambio de firmas

Un pago dentro de un canal no es una transacción. Son tres mensajes: update_add_htlc propone el cambio, commitment_signed firma el estado nuevo y revoke_and_ack entrega el secreto que invalida el anterior (BOLT 2, Normal Operation). El saldo se movió, la cadena no se enteró, y el par puede repetirlo mil veces.

La revocación es la seguridad. Una vez revocado un estado, publicarlo le permite a la contraparte barrer el canal entero con una transacción de penalización (BOLT 5, Revoked Transaction Close Handling). Los estados viejos no quedan simplemente superados: quedan caros.

Un canal se parece a una cuenta de bar que las dos personas inicialan después de cada ronda, salvo que el papel es ejecutable por quien lo tenga y firmar uno nuevo destruye la posibilidad de presentar el viejo.

Llegar a alguien con quien no hay canal

Nadie abre un canal con cada comercio. En cambio el pago se retransmite, y lo que vuelve segura esa retransmisión es un contrato con bloqueo por tiempo y hash, o HTLC.

Quien recibe elige un número al azar, la preimagen, y entrega solamente su hash SHA-256. El pago recorre el camino como una cadena de promesas condicionales, una por salto, y cada una dice lo mismo: el salto siguiente cobra este monto si presenta un número cuyo hash sea este valor, y si no, el monto vuelve al salto anterior pasada cierta altura de bloque. Nadie en el camino puede robarlo, porque cobrar exige la preimagen, y revelar la preimagen para cobrarle a un vecino es exactamente lo que le permite a ese vecino cobrarle al suyo. La liquidación corre hacia atrás por el camino, salto por salto, en mensajes update_fulfill_htlc que llevan la preimagen (BOLT 2, Removing an HTLC). Si algún salto falla, las promesas vencen en orden y cada saldo queda donde estaba. Los plazos están escalonados a propósito, el vencimiento de cada salto más lejano que el del siguiente, para que un nodo que reenvía siempre tenga tiempo de cobrar su pago entrante después de haber pagado el saliente (BOLT 2, cltv_expiry_delta Selection).

Un HTLC se parece a un depósito en garantía con fecha límite, salvo que ningún tercero guarda nada y la fecha límite es una altura de bloque en lugar de un día del calendario.

Las instrucciones de ruteo van envueltas en capas de cifrado, de modo que cada nodo aprende solamente quién le entregó el paquete y a quién se lo tiene que entregar. La afirmación de la especificación es cuidadosa, y conviene leerla tal cual: los nodos intermedios "no pueden saber qué otros nodos, además de su predecesor o su sucesor, forman parte de la ruta del paquete; ni pueden saber la longitud de la ruta ni su posición dentro de ella" (BOLT 4).

El cierre, por las buenas y por las malas

BOLT 5 nombra tres finales, y los nombres son de la propia especificación.

Cierre mutuo, "la forma buena". Las dos partes acuerdan, firman una transacción de cierre que paga los saldos finales y la publican. Eso "les permite acceder a sus fondos de inmediato y puede negociarse con comisiones más bajas" (BOLT 2, Channel Close), porque no hay nada contra lo que protegerse.

Cierre unilateral, "la forma mala". Un lado desapareció o no quiere cooperar, así que el otro publica su última transacción de compromiso. El dinero está a salvo y el canal termina, pero la parte que lo forzó espera to_self_delay bloques antes de poder gastar su porción, y los pagos que quedaron en vuelo se tienen que resolver en la cadena y no en un mensaje.

Cierre revocado, "la forma fea". Alguien publica un estado viejo a propósito. La transacción de penalización se queda con el canal. Eso solo funciona si el otro lado, o algo que actúa en su nombre, lo nota dentro de la ventana de espera.

Lo que Lightning no hace

No es anónimo. El ruteo en capas oculta la ruta a los nodos que la reenvían, y esa es una propiedad real, pero la misma especificación dice que "no excluye la posibilidad de que un atacante asocie paquetes mediante análisis de tráfico" (BOLT 4). Los canales públicos se anuncian a todo el mundo por diseño, porque el ruteo necesita un mapa: los mensajes channel_announcement y node_announcement existen para que los nodos construyan "una visión local de la topología de la red" (BOLT 7). El primer salto sabe que alguien envió algo. El nodo de quien recibe sabe qué llegó. Una billetera Lightning custodiada sabe todo de las dos puntas.

Necesita a alguien conectado. Recibir un pago implica estar accesible para liberar la preimagen. Seguir a salvo implica que alguien vigile la cadena por un cierre revocado dentro de la ventana de espera. Con un nodo propio, ese alguien es quien lo opera, o una watchtower contratada. Con un custodio, es el custodio, junto con las llaves.

La liquidez entrante es una restricción real. Solo se puede recibir hasta el saldo que está del otro lado de los canales. Un canal financiado enteramente por una parte arranca sin nada del lado opuesto, así que un canal recién abierto puede enviar y no puede recibir hasta que algo de dinero haya cruzado. El protocolo además retiene una reserva de canal de cada lado, sugerida en "el 1% del total del canal", justamente para que cada parte "siempre tenga algo que perder" (BOLT 2, Channel Establishment v1). Esa reserva no es saldo gastable.

Los fondos en canal no son dinero on-chain hasta que el canal cierra. Un saldo dentro de un canal es un derecho ejecutable mediante una transacción que no se publicó. Volver a convertirlo en una moneda gastable en la cadena exige un cierre, una confirmación y una comisión, que es exactamente el costo que Lightning estaba evitando.

Adónde seguir

Lo primero que aparece en la práctica no es un canal sino una cadena de texto que empieza con lnbc. Qué es en realidad una factura Lightning la desarma: a qué se compromete, por qué vence y por qué no se puede usar dos veces.