Proveedor de servicios Lightning
Un proveedor de servicios Lightning (LSP, por sus siglas en inglés) es un operador que proporciona liquidez de canal y conectividad a los usuarios de la Red Lightning. Normalmente, un LSP gestiona uno o más nodos Lightning y abre o administra canales de pago para clientes que no realizan por sí mismos todos los pasos operativos. El término describe una función de servicio, no el protocolo Lightning ni una implementación concreta de nodo.[1]
Los LSP suelen estar integrados en carteras, pero el LSP y la cartera no tienen por qué ser la misma entidad. Una cartera de autocustodia puede utilizar un LSP mientras el usuario conserva el control de las claves correspondientes a su lado del canal. Una cartera con custodia o un procesador de pagos también puede ofrecer acceso a Lightning, pero en ese modelo el proveedor controla los saldos de los clientes. Por tanto, la denominación LSP no determina por sí sola si un producto es custodial.[2]
Función en la Red Lightning
Los canales Lightning tienen liquidez direccional. Un usuario solo puede enviar desde el saldo de su lado del canal y solo puede recibir cuando existe saldo suficiente en el lado remoto. Por ello, una cartera nueva puede contener bitcoins y carecer de la liquidez entrante necesaria para recibir un pago Lightning.
Un LSP puede resolverlo asignando capital propio a un canal con el cliente. El proveedor pasa a ser el par Lightning directo del cliente y aporta capacidad entrante; los pagos siguen dependiendo de rutas utilizables entre el proveedor y el resto de la red. El proveedor puede recuperar los costes de financiación en cadena, el coste del capital comprometido y los gastos operativos mediante tarifas de apertura de canal, de servicio o de enrutamiento. Un LSP no elimina las limitaciones generales de liquidez y enrutamiento de la Red Lightning.
Los LSP deben distinguirse de las implementaciones de Lightning. LND, Core Lightning, Eclair y Lightning Development Kit son programas utilizados para operar nodos Lightning o crear carteras. Una organización puede emplear una de estas implementaciones para prestar un servicio LSP, pero el programa no es necesariamente un proveedor de servicios.
Modelos de servicio
Canales adquiridos
Un cliente puede comprar un canal antes de recibir un pago. La especificación activa LSPS1, publicada como bLIP 51, define una API mediante la cual una cartera obtiene una oferta, crea y paga un pedido y solicita al LSP que abra un canal. La especificación señala expresamente que la compra no es atómica: el cliente debe confiar en que el proveedor entregue el canal prometido o reembolse un pedido fallido.[3]
Canales justo a tiempo
Un canal justo a tiempo (JIT) se abre en respuesta a un pago entrante. En LSPS2, publicado como bLIP 52, el pago se dirige al LSP, que abre un canal hacia el destinatario y reenvía el pago después de deducir la comisión de apertura acordada. Así, un cliente sin canal existente puede empezar a recibir mediante Lightning sin comprar capacidad entrante por adelantado.[4][5]
Los canales JIT pueden utilizar técnicas de canal sin confirmación, por lo que el primer pago podría entregarse antes de que la transacción de financiación se confirme. Esto agiliza la incorporación, pero introduce riesgos adicionales de confianza y de transacción de financiación que dependen del modelo acordado. La oferta LSPS2 incluye límites de comisión, periodos de validez y una vida útil mínima prometida para el canal.
Intercambios y gestión de liquidez
Algunos proveedores intercambian bitcoins en cadena y fuera de cadena mediante intercambios submarinos. Un intercambio puede añadir liquidez saliente, liberar liquidez entrante o mover fondos entre Lightning y la cadena de bloques de Bitcoin sin cerrar todos los canales afectados. Estos servicios resuelven un problema diferente al de comprar un canal nuevo y pueden ofrecerse sin una relación LSP.
Las funciones de servidor de cartera, como copias de seguridad cifradas, notificaciones de pago, identificadores de pago reutilizables, administración de nodos alojados y supervisión mediante watchtower, también son servicios relacionados. No convierten por sí solas a un operador en LSP, aunque un mismo proveedor puede combinar varias funciones.[6]
Interoperabilidad
Las primeras integraciones LSP solían utilizar APIs específicas de cada proveedor. Las especificaciones de proveedores de servicios Lightning se desarrollaron para que carteras y proveedores pudieran implementar formatos comunes de solicitud y respuesta. En enero de 2025, el desarrollo pasó del repositorio original de especificaciones LSP al proceso de propuestas de mejora de Bitcoin Lightning.[7]
Las especificaciones activas incluyen:
- LSPS0 / bLIP 50, una capa de transporte y descubrimiento que transmite mensajes JSON-RPC mediante el transporte entre pares de Lightning;[8]
- LSPS1 / bLIP 51, para comprar directamente un canal; y
- LSPS2 / bLIP 52, para negociar un canal JIT cuando llega un pago entrante.
La compatibilidad con una especificación no implica compatibilidad con todos los servicios LSP. Las carteras y los proveedores también pueden usar APIs propietarias u otros mecanismos de liquidez.
Confianza, privacidad y aspectos operativos
En un acuerdo sin custodia, el cliente controla las claves necesarias para gastar su saldo del canal, mientras que el LSP controla su propio lado. Esto difiere de depositar bitcoins en un custodio. No obstante, el cliente puede depender de que el proveedor abra un canal del tamaño correcto, respete las condiciones ofrecidas, permanezca disponible, reenvíe pagos y no cierre el canal antes de lo previsto. Las obligaciones concretas varían entre protocolos de servicio e implementaciones.
El LSP también es el par inmediato del cliente en la red. Puede observar la conexión del nodo del cliente e información sobre los pagos que reenvía, aunque el enrutamiento cebolla de Lightning normalmente impide que un nodo intermedio conozca una ruta completa de varios saltos. Estudios sobre la privacidad de Lightning han demostrado que la información pública de la red y el comportamiento de enrutamiento pueden revelar datos que se pretendía mantener privados; por ello, ni Lightning ni un LSP garantizan el anonimato.[9]
El uso de un servicio puede simplificar la gestión de canales, pero también concentrar conectividad o liquidez en un número reducido de operadores. Las carteras que permiten cambiar de proveedor, utilizar varios o gestionar canales directamente reducen la dependencia de un único servicio.[6]
Las tarifas y la fiabilidad dependen del proveedor y de las condiciones actuales de la red. Puede cobrarse una tarifa de servicio además de las tarifas de enrutamiento de Lightning y el coste en cadena de abrir o cerrar un canal. Un canal suministrado por un LSP no garantiza una ruta completa hasta todos los destinatarios ni disponibilidad permanente.
Véase también
- Contratos con hash y bloqueo temporal
- Transacciones fuera de la cadena
- Transacciones de Bitcoin
Enlaces externos
- Bitcoin Lightning Improvement Proposals
- Archived Lightning Service Provider Specifications repository
Referencias
- ↑ Lightning Service Provider, Lightning Labs Builder's Guide, accessed 3 September 2026.
- ↑ Lightning services, Bitcoin Design Guide, accessed 3 September 2026.
- ↑ bLIP 51: LSPS1 Channel Requests, Lightning specifications repository, accessed 3 September 2026.
- ↑ bLIP 52: LSPS2 JIT Channel Negotiation, Lightning specifications repository, accessed 3 September 2026.
- ↑ Just-In-Time channels, Bitcoin Optech, accessed 3 September 2026.
- ↑ 6,0 6,1 Lightning services, Bitcoin Design Guide, accessed 3 September 2026.
- ↑ Lightning Service Provider Spec repository, archived 10 January 2025; accessed 3 September 2026.
- ↑ bLIP 50: LSPS0 LSP Spec Transport Layer, Lightning specifications repository, accessed 3 September 2026.
- ↑ An Empirical Analysis of Privacy in the Lightning Network, H. Yousaf et al., Financial Cryptography and Data Security, 2021.