Los límites de Lightning, Ark y las nuevas capas de pago

Curiosidad

1. ¿Por qué un canal de pago que contiene diez bitcoins sigue sin poder enviar nueve?
2. ¿Qué le sucede a un usuario que se desconecta durante dos días mientras su contraparte vigila la cadena?
3. ¿Puede una red con capacidad pública de unos pocos miles de bitcoins servir a miles de millones de usuarios potenciales?

Explorar

Parte ILos límites de Lightning

1. Un canal de pago es un búfer finito, no una tubería infinita. La capacidad total está fijada al momento de su creación; a medida que los fondos se transfieren de un lado a otro, el saldo de envío del remitente disminuye mientras que el saldo de recepción aumenta. Un usuario que gasta de forma agresiva agota su capacidad para seguir enviando hasta que recibe pagos o reequilibra sus recursos por otra vía. Las transferencias grandes que superan la capacidad restante de envío del canal fallan al instante, obligando a realizar intentos nuevamente o a recurrir a métodos más lentos.
2. Recibir liquidez es estructuralmente más difícil que enviarla para los nuevos participantes. Abrir un canal con fondos propios solo crea capacidad de envío; la contraparte posee todo el saldo de entrada. Para recibir pagos, un usuario debe primero gastar (transferir fondos), pedir a otra persona que abra un canal hacia él o adquirir liquidez de entrada a un proveedor de servicios. Esta asimetría genera una dependencia persistente de terceros o de un historial de transacciones previo para los nuevos nodos que ingresan a la red.
3. La seguridad no custodial requiere vigilancia constante. Si un nodo se desconecta mientras su contraparte transmite un estado de compromiso obsoleto, el usuario desconectado dispone de un plazo limitado para responder con una transacción punitiva utilizando secretos de revocación. Si no aprovecha ese plazo, el estafador puede quedarse con lo que le pagó el antiguo estado. Las torres de vigilancia pueden monitorear en nombre de los usuarios, aunque estos deben confiar en que la torre permanezca conectada y actúe; una torre no puede robar fondos. Para muchos usuarios, mantener un nodo conectado las 24 horas del día representa una carga práctica que los servicios custodiales absorben al gestionar la infraestructura internamente.
4. La topología de la red está distribuida de manera desigual. La eficiencia en el enrutamiento depende de nodos grandes y bien financiados que cuenten con una liquidez considerable a través de múltiples canales para facilitar transferencias de gran volumen. Los nodos más pequeños suelen carecer de la capacidad o conectividad necesarias para enrutar pagos significativos de forma independiente, lo que genera cuellos de botella. Los ataques de exploración pueden revelar los saldos de los canales al enviar pagos de prueba que fallan en etapas específicas, lo que permite a los observadores determinar dónde se encuentra la liquidez, lo cual debilita la privacidad de los pagos.
5. Los costos en la cadena permanecen como una limitación importante para su adopción. Cada apertura y cierre de canal requiere una transacción en Bitcoin, lo que genera tarifas que aumentan durante períodos de alta actividad en el mempool. Para los usuarios que abren y cierran canales con frecuencia, estas tarifas pueden erosionar los ahorros obtenidos mediante pagos fuera de la cadena. Diseños como las “fábricas de canales” y los acuerdos tienen como objetivo reducir este costo adicional al permitir que varios usuarios compartan un mismo resultado en la cadena o al aplicar scripts complejos sin que esto genere sobrecargas, pero su implementación generalizada aún está por realizarse.
6. La capacidad de la red pública sigue siendo modesta en relación con el suministro total de Bitcoin. Según observaciones recientes, la suma de todos los canales públicos se sitúa en los pocos miles de BTC, mientras que los canales privados, que no son visibles en el gráfico, representan una proporción significativa pero desconocida. Esta limitada visibilidad pública dificulta evaluar la verdadera salud de la red o su profundidad de liquidez. El ataque de ciclo de reemplazo revelado en 2023 demostró que un atacante podía explotar las reglas de reemplazo del mempool para evitar que la transacción de expiración (timeout) de un nodo de enrutamiento se confirmara hasta que pasara el plazo establecido aguas arriba, y luego apropiarse de los fondos; las medidas de mitigación reducen pero no eliminan el riesgo.

Parte IIArk y las nuevas capas de pago

7. Burak Keceli propuso Ark en mayo de 2023 como un protocolo de segunda capa que permite a muchos usuarios compartir UTXO coordinados por un operador. A diferencia de Lightning, que requiere canales entre dos partes con liquidez prefinanciada, Ark agrupa los saldos en salidas compartidas gestionadas por el operador. Esta estructura reduce significativamente la huella en la cadena por usuario, con el objetivo de lograr una adopción global de la autocustodia sin la complejidad de gestionar canales.
8. El mecanismo central se basa en que el operador coordina los pagos fuera de la cadena mientras mantiene un estado válido en Bitcoin. Los usuarios pueden salir unilateralmente a sus propias direcciones en cualquier momento antes de que venzan sus salidas compartidas, enviando una transacción en la cadena. Esta vía de salida es crucial: impide que el operador congele los fondos indefinidamente, lo que diferencia a Ark de los modelos de custodia en los que el emisor tiene el control exclusivo de las claves.
9. Ark Labs lanzó Arkade, que realizó sus primeros pagos en la red principal en agosto de 2025 y se abrió al público en octubre de 2025. Al mismo tiempo, Second desarrolló Bark, una implementación distinta que llegó a la red principal el 9 de junio de 2026. Los dos sistemas no son interoperables; los usuarios no pueden mover fondos directamente entre Arkade y Bark sin salir primero a la capa base, lo que fragmenta los pools de liquidez.
10. En comparación con Lightning, Ark elimina la necesidad de liquidez entrante para recibir pagos. En Lightning, un usuario debe abrir canales con otros nodos para aceptar pagos, lo que requiere una gestión cuidadosa de la liquidez. Ark lo simplifica al permitir que el operador gestione internamente estados similares a canales, y sus transacciones compartidas dan a los usuarios cierta privacidad similar a la de CoinJoin.
11. Las contrapartidas tienen que ver con la disponibilidad del operador y los costos de salida. Si un operador se desconecta, los usuarios aún pueden salir en la cadena, pero deben pagar comisiones de transacción y esperar la confirmación. Los timeouts determinan con qué rapidez un usuario puede forzar una salida si el operador no firma las transacciones cooperativas. Las salidas compartidas también caducan: en el diseño original, los usuarios deben conectarse para renovar sus saldos antes de que venza un plazo, a menudo de semanas, o el operador puede reclamar la salida.
12. Los sistemas de ecash ofrecen privacidad, pero son custodiales: Cashu depende de un único mint, Fedimint de una federación, y ambos custodian el bitcoin. Ark aspira a una autocustodia sin custodio con beneficios de privacidad similares. Sigue el debate sobre si esta complejidad está justificada frente al ecosistema maduro de Lightning, ya que ambos protocolos coexisten y podrían complementarse en futuras arquitecturas de pago.

Datos clave

Ejercicio nueve, seis, tres, uno

Verificación de hechos

Fechas, cifras y afirmaciones verificadas con las fuentes publicadas que se enumeran a continuación.

• A. M. Antonopoulos, O. Osuntokun & R. Pickhardt, Mastering the Lightning Network (2021)
• A. Riard, replacement cycling disclosure (bitcoin-dev mailing list, October 2023)
• Public network statistics from 1ML and mempool.space Lightning
• Ark protocol documentation (ark-protocol.org)
• Bitcoin Magazine, 'Bark Launches on Mainnet' (June 2026)
• Ark Labs announcements (August and October 2025)