-
La mensajería onion permite a los nodos de Lightning comunicarse entre sí de forma privada.
-
El sistema onion es necesario para implementar BOLT 12 y reemplazar las facturas de un solo uso.
El equipo de Lightning Labs lanzó la nueva versión de Lightning Network Daemon 0.21 (LND v0.21), el software de referencia para los operadores de nodos de la red Lightning Network (LN) de Bitcoin. Esta actualización incorpora por primera vez en el cliente LND soporte para mensajería onion (cebolla).
Asimismo, la implementación de este sistema de mensajería prepara el camino para la llegada de BOLT 12, el estándar de facturas reutilizables.
La mensajería onion es un sistema que permite a los nodos de Lightning enviarse información entre sí de forma privada, sin que ningún participante intermedio sepa quién inició el mensaje ni a quién va dirigido. El nombre ‘onion‘ viene de la imagen de una cebolla: el mensaje sale envuelto en múltiples capas de cifrado, y cada nodo en la ruta solo puede descifrar la capa que le corresponde, lo justo para saber a quién pasárselo. Nadie en el camino ve el contenido completo ni conoce el recorrido completo.
Eso no es nuevo en Lightning: los pagos ya funcionan así. Lo que LND v0.21 agrega es la posibilidad de enviar mensajes que no están atados a ningún pago. Hasta ahora, dos nodos que quisieran coordinarse necesitaban hacerlo fuera del protocolo o a través de una transacción. Con la mensajería onion pueden intercambiar información directamente dentro de la red, con la misma privacidad que un pago, sin mover fondos y sin dejar registro en la cadena de bloques de Bitcoin.
Quienes se benefician de esto en primera instancia son los operadores de nodos y los desarrolladores de wallets, porque el sistema les da un canal de comunicación privado dentro de Lightning.
No obstante, el impacto más amplio viene de lo que ese canal habilita: es el mecanismo que el estándar BOLT 12 necesita para funcionar. Sin mensajería onion, el flujo de solicitud y entrega de facturas reutilizables que define BOLT 12 no puede ejecutarse dentro del protocolo.
Lo que LND v0.21 no hace todavía es implementar BOLT 12 completo. Por ahora, los nodos con esta versión pueden transportar los mensajes que el estándar necesita, pero para que un usuario pueda pagar o cobrar con una oferta BOLT 12 en la práctica, hacen falta dos cosas más: que otras implementaciones de Lightning hagan lo mismo, y que las wallets incorporen el estándar. Lightning Labs no menciona el estado de adopción en ninguno de esos frentes.
El problema que BOLT 12 viene a resolver
BOLT 11 es el formato de factura predominante en Lightning hoy y tiene una limitación central, ya que cada factura es de un solo uso. Si un comerciante quiere recibir cinco pagos distintos, necesita generar cinco facturas distintas. Eso hace inviable, en la práctica, casos de uso como un QR estático para recibir donaciones, una suscripción recurrente o un botón de pago permanente en una página web.
Según la especificación BOLT 12, este estándar resuelve eso con un concepto llamado «oferta» (offer): una especie de plantilla de cobro reutilizable que el receptor publica de forma permanente, por ejemplo como código QR o enlace. Cuando alguien quiere pagar, su wallet envía un mensaje onion solicitando una factura única derivada de esa oferta. El receptor responde con esa factura, también por mensajería onion, y el pago se ejecuta. El ciclo puede repetirse tantas veces como sea necesario sin que el receptor intervenga manualmente.
El resultado práctico es que un bote de propinas con un QR impreso en una mesa, una donación recurrente a un creador de contenido o un cobro mensual automatizado se vuelven posibles en Lightning sin infraestructura adicional del lado del receptor.
El repositorio de BOLT 12 también detalla otras diferencias respecto de BOLT 11. En BOLT 11, la única prueba disponible al completar un pago es que alguien pagó esa factura, no quién lo hizo. BOLT 12 permite al pagador demostrar criptográficamente que fue él quien realizó la solicitud, lo que habilita disputas o comprobantes con mayor precisión. Además, las ofertas pueden denominarse en monedas fiat, como dólares, con conversión automática al equivalente en satoshis al momento de generar cada factura.
El resto de las novedades de LND 0.21
La versión v0.21 también pasa los canales Taproot simples a producción. Estos canales hacen que las transacciones de apertura y cierre de un canal Lightning sean indistinguibles en la cadena de bloques de Bitcoin de cualquier otra transacción Taproot, mejorando la privacidad de todos los usuarios de la red.
Por otro lado, la base de datos de pagos migra a SQL nativo, lo que acelera las consultas al historial de pagos en nodos con grandes volúmenes de actividad. Según Lightning Labs, el tiempo de respuesta en consultas de historial se redujo más de un 97% en bases de datos grandes tras la migración.
Los nodos Neutrino, que son nodos ligeros de Lightning que operan sin necesidad de un nodo Bitcoin completo, ahora pueden completar su sincronización inicial en minutos en lugar de horas, descargando las cabeceras de bloque desde un archivo local o una URL en lugar de solicitarlas una por una a sus peers. Las cabeceras importadas se validan igualmente contra la prueba de trabajo, según explican desde Lightning Labs.
Finalmente, el resto de las mejoras son de operación cotidiana: los cierres de canal ahora esperan entre 3 y 6 confirmaciones antes de darse por finalizados, protegiéndose ante reorganizaciones de la cadena; el grafo de canales carga de forma asíncrona al iniciar el nodo, reduciendo el tiempo hasta que el nodo está listo para responder consultas; y un nuevo comando permite a los operadores borrar el historial de pagos enrutados para terceros anteriores a una fecha determinada, reduciendo la información sensible almacenada en el nodo.
Así, con la llegada de la mensajería onion y la convergencia entre implementaciones de Lightning hacia BOLT 12 la red allana el camino para el arribo de las facturas reutilizables como el estándar de facto en la red.
