Por Canuto  

La nueva versión beta de lnd introduce una migración opcional del almacenamiento de pagos hacia SQL nativo y refuerza los mecanismos de verificación del software con firmas PGP, hashes SHA-256, OpenTimestamps y builds reproducibles, en una actualización centrada en seguridad operativa y confianza técnica.
***

  • lnd v0.21.0-beta incorpora una migración que mueve el almacenamiento de pagos del formato KV a SQL nativo.
  • La actualización añade nuevos pasos de verificación con firmas PGP, hashes SHA-256 y marcas de tiempo con OpenTimestamps.
  • Los binarios de la versión siguen un esquema reproducible y también pueden verificarse dentro de imágenes de Docker.

La versión lnd v0.21.0-beta ya está disponible con una serie de cambios orientados a la integridad del software y a la evolución de su arquitectura de almacenamiento. La actualización fue publicada por el equipo de desarrollo de Lightning Network y pone especial énfasis en procesos de verificación más robustos.

Para quienes siguen de cerca la infraestructura de Bitcoin, lnd es una de las implementaciones más usadas para operar nodos sobre Lightning Network. Por eso, incluso cambios que parecen internos, como una migración de base de datos o mejoras en la validación de binarios, pueden tener implicaciones importantes para operadores, desarrolladores y empresas.

La novedad más destacada en esta beta es una migración que traslada el almacenamiento de pagos desde un formato KV hacia SQL nativo. Según el anuncio oficial del lanzamiento, este procedimiento solo se ejecutará si el usuario activa la opción --db.use-native-sql junto con --db.backend configurado en sqlite o postgres.

El equipo también indicó que los usuarios que no quieran aplicar ese cambio pueden omitirlo mediante la opción --db.skip-native-sql-migration. Ese detalle es relevante porque muestra que la transición fue planteada de forma optativa, al menos en este punto del ciclo de desarrollo.

Más allá de la migración, la versión incorpora una capa adicional de confianza para quienes descargan e instalan el software. La publicación describe procesos concretos para verificar firmas, hashes, etiquetas del repositorio, marcas de tiempo y hasta los binarios incluidos dentro de imágenes de Docker.

Migración de pagos a SQL nativo y qué implica para operadores

La migración identificada como #9861 mueve el almacenamiento de pagos desde un esquema KV hacia SQL nativo. En términos prácticos, eso apunta a modernizar cómo lnd gestiona una parte crítica de la información transaccional dentro del nodo.

El cambio no se activa por defecto en cualquier entorno. Solo correrá cuando se use la bandera --db.use-native-sql y, además, cuando el backend de base de datos esté definido como sqlite o postgres mediante --db.backend.

Ese diseño sugiere una transición controlada. En lugar de forzar a todos los usuarios a un nuevo formato de almacenamiento, el equipo optó por condicionar la migración a una configuración explícita del operador.

También existe una vía de exclusión. Quienes decidan mantener su estado actual pueden evitar el proceso con --db.skip-native-sql-migration, una opción que puede resultar útil en despliegues sensibles o en ambientes de prueba donde se prefiera evaluar primero el impacto.

Aunque las notas compartidas no detallan beneficios de rendimiento o escalabilidad, el paso hacia SQL nativo encaja con una tendencia más amplia del software de infraestructura. En ese tipo de sistemas, adoptar motores como sqlite o postgres suele facilitar consultas estructuradas, mantenimiento y futuras extensiones.

Cómo verificar la autenticidad del lanzamiento

Uno de los bloques más extensos de la publicación está dedicado a la verificación de la versión. Para ello, los usuarios necesitan tener instalado gpg o gpg2 en su sistema, ya que la autenticidad del lanzamiento se comprueba mediante firmas PGP.

El primer paso consiste en importar la clave del firmante. La referencia oficial muestra el uso de la clave asociada a Olaoluwa Osuntokun, obtenida desde el repositorio del proyecto mediante el archivo roasbeef.asc.

Después, el usuario puede verificar la firma del manifiesto del lanzamiento, siempre que disponga de manifest-roasbeef-v0.21.0-beta.sig y manifest-v0.21.0-beta.txt en el directorio actual. Si todo sale bien, el sistema mostrará una firma válida asociada a la clave RSA 60A1FA7DA5BFF08BDCBBE7903BBD59E99B280306.

Ese paso confirma la integridad y autenticidad del archivo de manifiesto descargado localmente. Sin embargo, la verificación no termina allí, porque luego debe recalcularse el hash SHA-256 del binario con shasum -a 256 <nombre del archivo> y compararlo con el valor correspondiente del manifiesto.

La comparación debe coincidir exactamente. Ese nivel de rigor es esencial en software financiero y de infraestructura, donde un binario alterado, incluso con cambios mínimos, puede comprometer fondos, privacidad o la estabilidad completa de un nodo de Lightning.

OpenTimestamps, reproducibilidad y confianza a largo plazo

La versión también introduce un ajuste importante en materia de marcas temporales. A partir de esta beta, además de registrar el git tag con OpenTimestamps, el equipo ahora también timestampa el archivo de manifiesto junto con su firma.

Para ello se incluye un nuevo artefacto de lanzamiento identificado como manifest-roasbeef-v0.21.0-beta.txt.asc.ots. Con el cliente de OpenTimestamps instalado localmente, el usuario puede verificar la marca temporal con el comando ots verify manifest-roasbeef-v0.21.0-beta.sig.ots -f manifest-roasbeef-v0.21.0-beta.sig.

La guía también señala una alternativa para quienes no tengan acceso a una instancia local de bitcoind. En esos casos, el sitio web de OpenTimestamps puede utilizarse para validar las marcas de tiempo.

La lógica detrás de este mecanismo es simple pero poderosa. Incluso si en el futuro expira la clave que firmó la versión, la marca de tiempo anclada a Bitcoin puede seguir ofreciendo evidencia sobre la existencia e integridad del archivo en un momento determinado.

Junto a ello, el lanzamiento insiste en que sus binarios son completamente reproducibles. Eso significa que terceros pueden reconstruirlos y comprobar que el resultado coincide con los archivos distribuidos, sin depender ciegamente del responsable del release.

La documentación enlazada por el proyecto remite a su guía de builds reproducibles. Según la publicación, los binarios de esta versión fueron compilados con go1.26.3, una condición necesaria para que los verificadores obtengan exactamente los mismos resultados.

Además, los binarios incluyen las etiquetas de compilación autopilotrpc, signrpc, walletrpc, chainrpc, invoicesrpc, neutrinorpc, routerrpc, watchtowerrpc, monitoring, peersrpc, kvdb_postrgres, kvdb_etcd y kvdb_sqlite.

El texto aclara que esas etiquetas ya están integradas en el script de lanzamiento. Por esa razón, los verificadores no necesitan proporcionarlas manualmente al reconstruir la versión.

Verificación de la etiqueta, Docker y compilación local

La publicación explica que también puede verificarse la etiqueta del repositorio correspondiente a la versión. El comando git verify-tag v0.21.0-beta debe devolver una firma correcta asociada igualmente a Olaoluwa Osuntokun y a la misma clave RSA mencionada en la validación del manifiesto.

Esa capa adicional de comprobación es importante porque ayuda a asegurar que el punto exacto del código fuente coincide con el release anunciado. En proyectos abiertos y críticos, verificar la etiqueta añade trazabilidad entre el repositorio, el manifiesto y los binarios publicados.

Otro aspecto llamativo es la verificación de las imágenes de Docker. El equipo indica que existe un script dentro de la imagen que permite contrastar los binarios lnd y lncli con los binarios reproducibles y firmados del lanzamiento.

El procedimiento sugerido usa la imagen lightninglabs/lnd:v0.21.0-beta y ejecuta el script /verify-install.sh v0.21.0-beta antes de iniciar el contenedor. Si la verificación falla, el flujo propuesto aborta la ejecución y muestra un mensaje de error.

Para quienes prefieren construir el contenido del release por cuenta propia, la nota también describe un método sin descargar dependencias externas. El proceso parte de los archivos vendor.tar.gz y lnd-source-v0.21.0-beta.tar.gz, que deben estar presentes en el directorio actual.

Tras descomprimir el código fuente y mover el paquete de dependencias al directorio lnd-source, el usuario puede extraer vendor.tar.gz y compilar tanto ./cmd/lnd como ./cmd/lncli. En ambos casos se usa go install -v -mod=vendor -ldflags "-X github.com/lightningnetwork/lnd/build.Commit=v0.21.0-beta".

La bandera -mod=vendor indica a Go que no necesita descargar dependencias desde fuera, ya que estas están incluidas localmente en el directorio de proveedores. Ese detalle ayuda a preservar la repetibilidad del proceso y reduce variables externas durante la compilación.

Además, el proyecto destaca que ahora puede utilizarse el script integrado release.sh para empaquetar un lanzamiento para sistemas específicos. El ejemplo mostrado es make release sys="linux-arm64 darwin-amd64", pensado para quienes solo necesitan un conjunto determinado de plataformas.

Notas del lanzamiento y contribuyentes de la beta

Tras el bloque técnico, la publicación remite a las notas completas de la versión 0.21.0 dentro de la documentación del proyecto. Allí se concentra el resto de cambios no desarrollados en el anuncio resumido del release.

Ese punto es relevante porque el anuncio principal se enfoca en la seguridad de distribución, la verificabilidad y la migración de base de datos. Otros ajustes funcionales o correcciones pueden revisarse en el documento específico de notas de la versión.

El lanzamiento también reconoce a sus contribuyentes en orden alfabético. La lista incluye a Abdulkbk, AbelLykens, ajaysehwal, Andras Banki-Horvath, bitromortac, Boris Nagaev, Calvin Zachman, Dario Anongba, Elle Mouton, elnosh, Erick Cestari, Euler-B, ffranr, George Tsagkarelis, Gijs van Dam y hieblmi.

También aparecen Liongrass, Matt Morehouse, Matthew Zipkin, Mohamed Awnallah, Nishant Bansal, Olaoluwa Osuntokun, Oliver Gugger, Pins, Suheb, ViktorT-11, Yash Bhutwala, Yong Yu y Ziggie. En proyectos de infraestructura abierta, esa diversidad de autores refleja el peso del trabajo comunitario detrás de cada actualización.

En conjunto, lnd v0.21.0-beta no se presenta como una simple revisión incremental. Su foco en SQL nativo, firmas, hashes, timestamps y builds reproducibles apunta a un aspecto central para el ecosistema de Bitcoin: que el software crítico no solo funcione, sino que también pueda auditarse y verificarse de forma independiente.


ADVERTENCIA: DiarioBitcoin ofrece contenido informativo y educativo sobre diversos temas, incluyendo criptomonedas, IA, tecnología y regulaciones. No brindamos asesoramiento financiero. Las inversiones en criptoactivos son de alto riesgo y pueden no ser adecuadas para todos. Investigue, consulte a un experto y verifique la legislación aplicable antes de invertir. Podría perder todo su capital.

Suscríbete a nuestro boletín

Artículos Relacionados