Las implementaciones de Lightning, y en qué difieren

Qué las hace interoperables

Cuatro bases de código en cuatro lenguajes rutean pagos Lightning entre sí todos los días, y la razón es estrecha: las especificaciones BOLT definen los bytes que van en el cable y no dicen nada sobre el programa que los emite. BOLT 1 fija el formato de los mensajes, BOLT 2 la máquina de estados del canal, BOLT 3 los formatos de transacción y de script, BOLT 4 la cebolla, BOLT 7 el gossip, BOLT 8 el transporte cifrado, BOLT 11 las facturas. Todo lo que está por encima de esa línea, la base de datos, la interfaz, la forma de elegir rutas, queda abierto.

Cada proyecto lo dice con sus propias palabras. LND "cumple plenamente con la especificación de la Red Lightning (BOLTs)". Core Lightning es "una implementación de la Red Lightning conforme a la especificación, en C". Eclair "sigue las Especificaciones de la Red Lightning (BOLTs)". LDK "implementa todas las especificaciones BOLT". El documento mismo es cuidadoso con su estado: BOLT 0 se abre llamando al conjunto "versión 0", todavía en redacción.

Así que la interoperabilidad es una propiedad del protocolo, no un favor que los proyectos se hacen entre ellos.

LND

Escrito en Go, y la licencia lleva el copyright de "Lightning Labs y Los Desarrolladores de la Red Lightning"; las imágenes Docker oficiales se publican bajo lightninglabs/lnd. Su propio README lo describe como "una implementación completa de un nodo de la Red Lightning", y todavía lo etiqueta como software beta.

Optimiza para que otros construyan encima. El README es explícito: "El daemon fue diseñado para ser lo más amigable posible con quien desarrolla, con el fin de facilitar el desarrollo de aplicaciones sobre lnd. Se exportan dos interfaces RPC principales: una API HTTP REST y un servicio gRPC." Esa elección aparece por todas partes aguas abajo: en los servicios de ruteo, en las integraciones de casas de cambio y en las billeteras de teléfono que manejan un nodo LND en lugar de implementar Lightning por su cuenta. También significa que el comportamiento de LND sostiene a mucho otro software, y por eso un cambio en cuánto puede hacerle acumular un solo par mereció cobertura como noticia.

También trae varios backends de cadena intercambiables en lugar de dar uno por sentado: bitcoind, el nodo completo en Go btcd, y Neutrino, que su propio README sigue llamando "un nuevo cliente ligero experimental".

Core Lightning

Escrito en C, "desarrollado y mantenido por Blockstream", en uso en producción en mainnet desde principios de 2018, con el lanzamiento de la Blockstream Store. El daemon es lightningd, el cliente lightning-cli, y la interfaz es "una interfaz JSON-RPC 2.0 sobre un socket de dominio Unix".

Optimiza para que lo extiendan, al punto de que el daemon es un núcleo pequeño y buena parte de lo que uno considera el nodo es un plugin. En el directorio plugins del repositorio no solo hay comodidades: están bcli, el backend de Bitcoin mismo, offers, keysend y askrene, el oráculo que busca rutas. El contrato de plugins es deliberadamente neutral en cuanto al lenguaje: "Un plugin puede escribirse en cualquier lenguaje, y se comunica con lightningd a través del stdin y el stdout del plugin. Se usa JSON-RPCv2 como protocolo sobre esos dos flujos." Los plugins registran sus propias opciones de línea de comandos y sus propios comandos JSON-RPC, se suscriben a flujos de eventos y usan hooks para alterar el comportamiento del daemon.

Eclair

Escrito en Scala, sobre la JVM, por ACINQ, y "eclair" es relámpago en francés. Apunta a Java 21 y exige un nodo Bitcoin Core sincronizado, compatible con segwit, con zeromq habilitado, con wallet habilitada, sin pruning y con índice de transacciones. No tiene wallet en cadena propia: "las transacciones de apertura de canal se fondean con su nodo Bitcoin Core, y las transacciones de cierre devuelven los fondos a su nodo Bitcoin Core."

Optimiza para operar un nodo de ruteo grande bajo carga. El documento de arquitectura explica la razón sin rodeos: se apoya en el modelo de actores, de modo que casi toda entidad es un actor aislado. Cada conexión con un par es uno, cada canal es uno, cada intento de pago es uno, y así el nodo aísla fallos y escala entre CPU. Va más lejos que las otras en esa dirección con un modo cluster que reparte un nodo lógico entre varios servidores: servidores frontales sin estado absorben el tráfico de gossip y de sincronización (BOLT 1 y BOLT 7), mientras un único backend maneja los canales (BOLT 2). La interfaz es una API HTTP JSON, deshabilitada por defecto y protegida con contraseña cuando se habilita, y los plugins son jars de la JVM que implementan una interfaz Plugin.

LDK, que no es un nodo

LDK es la excepción, y la razón por la que entra en esta lista es que mucho software que ya se usó lo lleva adentro. Es una biblioteca de Rust. Su README pone el límite por delante: "Nótese que LDK no es, en sí mismo, un nodo."

En la práctica eso significa que LDK a propósito no provee las cosas que un daemon decide por uno. El almacenamiento en disco, los datos de la cadena, la gestión de UTXO, la red y las claves privadas quedan en manos de la aplicación que lo incrusta, cada una detrás de una interfaz. El crate central, lightning, es agnóstico al runtime y soporta no_std. El encuadre del propio proyecto: "si quiere integrar Lightning con funciones a medida, como su propia sincronización con la cadena, gestión de claves, lógica de almacenamiento y respaldo, etc., LDK es probablemente su mejor opción."

Por eso LDK aparece dentro de billeteras y plataformas de pago y no como un proceso en un servidor. Su sitio menciona a Lightspark, Alby Hub, Cash App y Lexe como proyectos construidos sobre él. ACINQ hace algo parecido con una base de código aparte: Eclair es lo que le señala a quien opera un nodo de ruteo, mientras que Phoenix, su billetera de teléfono, está construida sobre lightning-kmp, una implementación en Kotlin para móviles.

Dónde difieren de verdad

Backends de base de datos. LND guarda el estado en una base bbolt embebida por defecto y puede configurarse sobre Postgres, SQLite o etcd, y la opción de etcd existe para sostener la elección de líder en un cluster donde solo una instancia puede escribir. Core Lightning toma un nombre de fuente de datos, sqlite3:// o postgres://. Eclair usa SQLite por defecto y soporta PostgreSQL 10.6 en adelante. LDK no opina, porque la persistencia es tarea de quien lo integra.

Watchtowers. LND trae uno como subsistema: un watchtower altruista privado, más un cliente que respalda transacciones de justicia cifradas en otras torres, con la advertencia de su propia documentación de que por ahora cubre las salidas to_local y to_remote de los compromisos revocados y no las salidas HTLC. Core Lightning lo resuelve por la interfaz de plugins, exponiendo un hook commitment_revocation que entrega las transacciones de penalización a un servicio de watchtower elegido por uno.

Heurísticas de ruteo. Acá es donde dos nodos con el mismo grafo no coinciden, porque el grafo nunca dice de qué lado del canal está el dinero. LND mantiene un subsistema llamado mission control, descrito en su código fuente como un estado que "actúa como memoria compartida durante los intentos de ruteo", que registra el momento del último fallo por nodo y por canal y lo convierte en una probabilidad de éxito que se realimenta en la búsqueda de rutas. Su semivida de penalización por defecto es de una hora: un canal que falló vuelve a una estimación del 50% pasado ese lapso. La búsqueda de rutas de Core Lightning vive en el plugin askrene, que combina lo que sabe en "capas" que se pueden incluir o excluir al preguntar. Las diferencias se ven como comisiones distintas y tasas de fallo distintas para el mismo pago.

Qué no significa nada de esto

No es un ranking de seguridad. Los BOLT atan a las cuatro a las mismas transacciones de compromiso y al mismo mecanismo de penalización, así que la garantía de la que uno depende es la del protocolo, no la de la base de código. La elección se hace por encaje operativo, por la interfaz contra la que hay que programar y por las notas de versión que uno esté dispuesto a leer.

Ninguna elimina el requisito de estar en línea. Un nodo que está fuera de línea cuando la contraparte transmite un estado revocado no puede responder dentro de la ventana, y por eso existen los watchtowers. Eso es una propiedad del protocolo, no de la implementación, y es la diferencia más marcada entre Lightning y operar un nodo de la capa base, que puede estar apagado un mes y ponerse al día.

La elección de implementación tampoco es invisible. Decide el procedimiento de backup y el camino de migración, y esas son las partes que cuestan dinero. El static channel backup de LND es un mecanismo de LND, no de la red, y su guía de seguridad dice que restaurar desde uno "no es una migración sino un procedimiento de emergencia". Los canales de un nodo no se mudan de casa porque uno cambió de opinión sobre el software. Cuál corre debajo de la billetera importa menos que haber comprobado que un pago y un backup funcionan.

Fuentes

• Las especificaciones BOLT, especificaciones en curso de la Red Lightning
• lnd, Lightning Labs y Los Desarrolladores de la Red Lightning
• Core Lightning, Blockstream, y su documentación de plugins
• Eclair, ACINQ, y sus documentos de arquitectura y cluster
• rust-lightning y lightningdevkit.org