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
| LND | Core Lightning | Eclair | LDK | |
|---|---|---|---|---|
| Lenguaje | Go | C | Scala | Rust |
| Mantenedor | Lightning Labs | Blockstream | ACINQ | desarrolladores de LDK |
| Forma | daemon | daemon | daemon | biblioteca |
| Interfaz | gRPC y REST | JSON-RPC sobre socket Unix | API HTTP JSON | API de Rust, más bindings |
| Extensión | subservidores RPC | plugins en cualquier lenguaje | plugins JVM | código propio |
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