En Strike, innovamos constantemente para ampliar los límites de bitcoin y de la red Lightning (LN), y mejorar la experiencia de nuestros clientes. Hoy nos complace anunciar la compatibilidad con BOLT 12 Offers, una tecnología revolucionaria que permite enviar y recibir sats a través de la red Lightning de bitcoin de una forma más privada, versátil y fácil de usar.

En esta publicación del blog profundizamos en nuestro recorrido para integrar BOLT 12 en Strike. Se trata de un análisis técnico dirigido tanto a los entusiastas de bitcoin como a nuestros valiosos clientes.

¿Qué es BOLT 12?

Presentada en septiembre de 2020 por Rusty Russell, la especificación BOLT 12 ofrece una versión mejorada del estándar BOLT 11 actual para pagos mediante LN. Si conoces LNURL, que Strike también admite, - entonces BOLT 12 debería resultarte familiar a primera vista. Permite funciones que mejoran considerablemente la experiencia con LN:

  • Códigos QR reutilizables: A diferencia de las facturas BOLT 11, que generalmente son de un solo uso, las ofertas BOLT 12 se pueden escanear y pagar varias veces. Esto las hace ideales para mostrarlas de forma estática en sitios web, folletos o carteles publicitarios, ya que elimina la necesidad de generar y distribuir nuevas facturas constantemente.
  • Mayor seguridad para los usuarios: BOLT 12 utiliza mensajes onion, una técnica criptográfica que oculta la ruta que siguen los pagos dentro de LN. Esto mejora la seguridad personal de los pagos mediante LN gracias a una mayor privacidad.
  • Funcionalidad avanzada: BOLT 12 abre la puerta a nuevas funciones nativas, como reembolsos o retiradas similares a las de los cajeros automáticos, que antes eran imposibles en Lightning Network sin utilizar capas adicionales como LNURL.

Nuestro proceso de implementación de BOLT 12

Nuestra exploración de BOLT 12 comenzó con un documento de investigación interno que redactamos en septiembre de 2021. Nos intrigaban las posibles ventajas que BOLT 12 podía ofrecer para mejorar la experiencia de los pagos mediante LN.

Diseñamos planes para integrar la funcionalidad de BOLT 12 en Strike, pero la fase inicial en la que se encontraba la propuesta en aquel momento, el hecho de que aún faltara mucho para que se implementara en LND, junto con otros factores, nos obligó a centrar de nuevo nuestros esfuerzos en otras funciones esenciales y adoptar una actitud de espera para dar tiempo a que el proyecto siguiera evolucionando.

Entre 2021 y 2022, miembros de la comunidad de bitcoin siguieron iterando sobre las propuestas de BOLT 12, desarrollando implementaciones e impulsando la tecnología. Aunque algunas implementaciones de nodos de Lightning se apresuraron a integrarlo, LND, la principal implementación de nodos que utilizamos en Strike, adoptó un enfoque más prudente y deliberado, centrado en la estabilidad del sistema central. El equipo de Lightning Labs desarrolló una completa hoja de ruta por fases para implementar BOLT 12, integrando poco a poco algunos de los componentes fundamentales durante un periodo más prolongado. A día de hoy, LND aún no admite BOLT 12, aunque ahora sí admite muchos de sus componentes esenciales y está avanzando firmemente hacia la compatibilidad nativa completa con BOLT 12.

Con la llegada de LNDK en marzo de 2023, una herramienta liderada por Carla Kirk-Cohen y desarrollada en colaboración con el equipo de Spiral, nuestro interés por BOLT 12 se reavivó. Descrita como “Un intento experimental de utilizar LDK para implementar funciones de BOLT 12 en LND”, básicamente se conecta a las API existentes de LND, lo que permite utilizar la compatibilidad integrada de LDK con BOLT 12 junto con LND.

Análisis técnico en profundidad

La integración implicó varios componentes clave:

  • LND: La API gRPC expuesta por el nodo LND de destino, compilado con los subservidores RPC adecuados.
  • LDK: Importado como dependencia en nuestra capa de aplicación para proporcionar la codificación y decodificación de ofertas BOLT 12.
  • LNDK: Aunque la descripción general de la arquitectura de LNDK se refiere a él jocosamente como “el monstruo de Frankenstein”, en realidad es una solución muy ingeniosa. LNDK actúa como un shim, aprovechando la biblioteca modular de Lightning de LDK y conectándola a la API gRPC de LND. Esto nos permitió reutilizar la implementación existente de BOLT 12 en LDK.

LNDK de un vistazo

LNDK, el ingenioso puente que permite a Strike aprovechar la funcionalidad de BOLT 12 dentro de nuestra infraestructura LND existente, merece una mirada más detallada. A continuación presentamos una visión general de su arquitectura y de algunas funciones clave que lo convirtieron en la herramienta elegida para nuestra integración.

Diseño modular para una mayor flexibilidad

Como hemos mencionado antes, LNDK actúa como un shim que conecta la API gRPC de LND con la biblioteca modular de Lightning de LDK. Este diseño ofrece varias ventajas:

  • Reutilización de componentes: Al aprovechar la implementación existente de BOLT 12 de LDK, LNDK evita tener que reinventar la rueda. Esto agiliza el desarrollo y garantiza la compatibilidad con el ecosistema más amplio de Lightning Network.
  • Separación clara de responsabilidades: La separación entre la funcionalidad central de LND y la compatibilidad de LDK con BOLT 12 proporciona una implementación relativamente limpia que simplifica algunos aspectos del mantenimiento.

Mensajería onion y pagos mediante ofertas

Una de las funciones principales de BOLT 12 es el uso de mensajes onion. Estos mensajes criptográficos permiten que dos nodos de la red Lightning se comuniquen de forma segura y privada.

El siguiente diagrama muestra, a grandes rasgos, cómo interactúan los distintos componentes:

A continuación se explica de forma simplificada cómo Strike utiliza LND, LDK y LNDK para facilitar el enrutamiento de mensajes onion y el protocolo BOLT 12:

  1. Solicitud de pago: El usuario de Strike inicia un pago escaneando un código QR de una oferta BOLT 12 o introduciendo una dirección DNS legible para humanos desde la que se puede obtener una oferta BOLT 12 mediante BIP 353.

  2. Análisis de la oferta por parte de LDK: LDK se utiliza para analizar la oferta BOLT 12 y extraer los detalles del pago.

  3. Construcción del mensaje onion: LNDK utiliza las bibliotecas de LDK y las API gRPC de LND para construir mensajes onion que contienen los detalles de la solicitud de factura.

  4. Retransmisión del mensaje onion: LND retransmite el mensaje onion construido a través de Lightning Network, atravesando varios nodos hasta llegar al nodo de destino especificado en la oferta. Allí, el mensaje onion se desempaqueta y revela la solicitud incluida en él.

  5. Recuperación de una ruta cegada: el nodo de destino utiliza mensajería onion para devolver una factura que incluye una ruta cegada con información detallada sobre cómo se puede pagar.

  6. Envío del pago: LNDK interactúa con la API gRPC de LND para iniciar el proceso de pago.

El siguiente diagrama muestra el flujo de pago a alto nivel:

Plan de implementación por fases (3 fases):

Dada la cantidad de elementos implicados, comenzamos definiendo un enfoque en tres fases para implementar la funcionalidad de BOLT 12 en Strike. En términos generales, el plan era el siguiente:

  1. Pruebas e implementación de LNDK
    Establecer la infraestructura y la funcionalidad principales de BOLT 12 para las pruebas y la observación internas.
  2. Integración de la plataforma y la API de LNDK
    Ampliar la plataforma y las API de Strike para exponer la funcionalidad de BOLT 12 en todo nuestro entorno.
  3. Integración con las aplicaciones de Strike
    Integrar las funciones de pago de BOLT 12 en los productos de Strike.

Al seguir este enfoque por fases, combinado con los conocimientos obtenidos en nuestras investigaciones anteriores, consideramos que podríamos garantizar una integración controlada y eficiente de la funcionalidad de BOLT 12 en Strike.

Implementación de la prueba de concepto

El primer paso consistió en pasar del concepto a la prueba de concepto, y por el camino tuvimos que superar varios obstáculos técnicos.

Entorno de pruebas de BOLT 12
Establecimos un entorno de desarrollo para probar pagos de BOLT 12 utilizando diversas combinaciones de nodos (LND, CLN, Eclair y LDK-Node) y canales (directos, de un solo salto, de múltiples saltos y entre implementaciones). Decidimos publicar como código abierto nuestro nuevo entorno de pruebas de BOLT 12 para ponerlo a disposición de una comunidad de desarrollo más amplia. Este entorno de pruebas resultó invaluable para agilizar el proceso de pruebas y facilitar la colaboración.

Integración de la API
Trabajamos estrechamente con el equipo de Spiral y los colaboradores de LNDK para mejorar LNDK con un servidor gRPC y una implementación de TLS que proporcionaran una interfaz bien definida y segura para que nuestra aplicación interactuara con la funcionalidad subyacente de BOLT 12 expuesta por LNDK.

Decodificación nativa de BOLT 12
Aprovechamos los enlaces C# generados de LDK para habilitar la decodificación de Offers e Invoices de BOLT 12 directamente en nuestro código base de .NET, lo que nos permitió limitar nuestras interacciones con el demonio LNDK y utilizar rutas de código nativas siempre que fuera posible.

Y seguimos avanzando...
En pocos días, teníamos una prueba de concepto funcional que demostraba la capacidad de pagar Offers de BOLT 12 directamente desde los sistemas backend de Strike. Con este éxito, nos sentimos preparados para avanzar hacia la puesta en producción de la solución.

De la prueba de concepto a producción

El siguiente desafío —y, sin duda, el que más tiempo llevó— consistió en transformar la prueba de concepto en un sistema sólido y seguro, listo para su uso en el mundo real dentro del entorno de producción de Strike. A continuación, compartimos algunos detalles de ese trabajo:

Preparación de LNDK para producción
Participamos activamente en el desarrollo de muchas funciones de LNDK para asegurarnos de que cumpliera nuestros requisitos y tuviera la flexibilidad necesaria para utilizarse en nuestro entorno de producción. Esto implicó varias iteraciones del diseño, que finalmente dieron como resultado una interfaz gRPC protegida mediante TLS y que utilizaba un macaron de LND con permisos estrictamente delimitados para la autenticación. También añadimos endpoints más específicos para cada fase del flujo de BOLT 12.

Desafíos y soluciones alternativas
Al trabajar estrechamente con los desarrolladores de LDK y LNDK, pudimos resolver los problemas que encontramos por el camino, lo que ayudó a llevar estas bibliotecas a un estado estable. Durante el proceso se publicaron varias versiones nuevas de LNDK, LDK y los enlaces C# de LDK, hasta que toda la funcionalidad necesaria funcionó como necesitábamos.

Implementación de la infraestructura
Para cada nodo LND que ejecutamos, implementamos un sidecar de LNDK, asegurándonos de que cada instancia de LND tuviera un LNDK correspondiente y dedicado para gestionar BOLT 12.

Compatibilidad con la mensajería onion en LND
Nuestros nodos LND utilizaban la versión 0.17, que no incluía compatibilidad integrada con la mensajería onion, un componente fundamental de la funcionalidad de BOLT 12 de LNDK. Como en ese momento aún no estábamos preparados para actualizar a LND v0.18, optamos por trasladar los cambios pertinentes de la versión v0.18 a la v0.17. Esto garantizó la compatibilidad con BOLT 12 y mantuvo la estabilidad de nuestra infraestructura existente. Durante el proceso, contribuimos a dar forma a la versión LND 0.18, que en ese momento se encontraba en su fase final de RC, asegurándonos de que se publicara con todo lo necesario para admitir mensajes onion de forma nativa, lo que simplificaría el proceso para otros operadores de nodos en el futuro.

Código de aplicación listo para producción
Nuestro código de prueba de concepto experimentó una transformación significativa. El código base se dividió en componentes más pequeños y específicos. Esto mejoró la capacidad de mantenimiento y facilitó una integración más fluida con la arquitectura existente de Strike. A alto nivel, esto incluyó:

  • Añadir bibliotecas de apoyo, como un analizador de BOLT 12, una implementación de DNSSEC para realizar búsquedas DNS seguras y una fachada gRPC para interactuar con el servidor gRPC de LNDK.
  • Integrarnos con nuestro grupo de nodos LND existente para gestionar las conexiones con los nodos LND y distribuir la carga entre nuestros sistemas.
  • Por último, integrar toda la solución con nuestros sistemas principales, API y productos empresariales y de consumo para habilitar pagos de BOLT 12 desde Strike.

El futuro de BOLT 12 en Strike

Aunque hemos logrado nuestro objetivo de habilitar pagos de BOLT 12 desde Strike, nuestra integración inicial solo admite un flujo básico de pago de Offer. Sin embargo, allana el camino para incorporar con el tiempo funciones de BOLT 12 más avanzadas e interesantes.

Nos comprometemos a seguir a la vanguardia de la innovación en bitcoin y Lightning Network. Seguiremos trabajando con la comunidad en general para ampliar los límites y ofrecerte la mejor experiencia posible.

Esperamos que esta publicación del blog ofrezca una perspectiva interesante del trabajo entre bastidores de nuestro proceso de integración de BOLT 12. Como puedes ver, en nuestro caso la implementación requirió bastante trabajo, ya que fuimos pioneros y, al mismo tiempo, ayudamos a desarrollar LNDK. Sin embargo, ahora que gran parte de este trabajo preliminar ya está terminado y disponible en el universo del código abierto, hemos demostrado que hoy existe una vía viable para ofrecer una experiencia de BOLT 12 con LND.

Si te gustaría probarlo, puedes donar a la Human Rights Foundation mediante su BOLT 12 Offer, escaneando el código QR que aparece a continuación o realizando un pago a su dirección Lightning de BOLT 12: [email protected]

Nos entusiasma ver la evolución continua de BOLT 12 a medida que más servicios y operadores de nodos se actualicen durante los próximos meses y años.

Si tienes alguna pregunta, no dudes en ponerte en contacto con nosotros.