¿Por qué los pagos de Lightning pueden ser más rápidos?
Descubre cómo los canales de pago de Bitcoin Lightning actualizan saldos fuera de la capa base, enrutan pagos y mantienen su liquidación final ligada a Bitcoin.
En esta página
Lectura rápida
Bitcoin puede liquidar la propiedad en su capa base, pero esperar un bloque para cada pago pequeño puede ser lento o costoso. Esta lección explica cómo los canales de pago de Lightning actualizan saldos fuera de la cadena, cómo los pagos pueden enrutarse a través de canales, y por qué siguen importando la liquidez disponible y la eventual liquidación en Bitcoin.
Lo que debes recordar
- Lightning traslada los pagos frecuentes a canales para que no compitan cada uno por el espacio de bloque de Bitcoin, que es de donde viene la velocidad.
- Los canales siguen ligados a Bitcoin: el financiamiento, el cierre y la ejecución forzosa son todos transacciones de Bitcoin, lo que hace que el arreglo sea exigible.
- No existe una coin de Lightning separada: los saldos que se mueven a través de los canales son BTC y se resuelven en Bitcoin.
- Los pagos enrutados dependen de la liquidez direccional en cada salto, así que un pago puede fallar incluso cuando tu propio saldo es suficiente.
¿Por qué un pago en Bitcoin puede necesitar otro camino?
La capa base de Bitcoin les da a los participantes un único historial compartido, pero ese historial no está diseñado para registrar de inmediato cada posible pago pequeño. Cuando un pago necesita ser frecuente o responder con rapidez, colocar cada actualización directamente en un bloque puede reintroducir la demora y la competencia por el espacio de bloque que se vieron en la lección anterior.
Lightning es una respuesta, a nivel de capa de pagos, a esa restricción. Permite que los participantes hagan muchas actualizaciones de saldo dentro de un canal, y luego usen la capa base de Bitcoin cuando necesitan abrir o liquidar ese canal.
¿Qué es un canal de pago de Lightning?
Un canal de pago comienza cuando los participantes comprometen BTC en un arreglo que Bitcoin puede reconocer. Dentro del canal, pueden acordar nuevos estados de saldo a medida que se pagan entre sí, sin difundir cada actualización como una transacción de Bitcoin separada. El canal no está desconectado de Bitcoin: su financiamiento y su camino de cierre o de ejecución forzosa siguen ligados a transacciones de Bitcoin.
Pasos
Financiar un canal
Los participantes crean el arreglo de financiamiento que ancla el canal a Bitcoin.
Actualizar los saldos
Intercambian nuevos estados del canal a medida que los pagos cambian quién puede reclamar qué monto.
Liquidar cuando sea necesario
Un canal puede cerrarse o usar su camino de compromiso para que el saldo resultante se resuelva en Bitcoin.
¿Cómo puede un pago llegar a alguien sin un canal directo?
Lightning puede reenviar un pago a través de una secuencia de canales. Cada nodo que reenvía pasa un pago condicional al siguiente salto, en lugar de tomar la custodia de un activo aparte. Por eso Lightning puede conectar a personas que no han abierto un canal directamente entre sí.
Esa ruta no está garantizada solo porque un diagrama muestre nodos conectados. Un pago necesita un monto utilizable en la dirección requerida en cada salto, y además debe cumplir los límites de comisión, tiempo y HTLC vigentes en cada salto. En este contexto, la liquidez significa si el pago necesario puede realmente viajar por esa ruta en este momento, y no simplemente cuánto valor existe en algún lugar de toda la red.
| Pregunta | Canal directo | Pago enrutado |
|---|---|---|
| ¿Quién actualiza el pago? | Los dos participantes del canal. | Cada par adyacente a lo largo de una ruta actualiza su propio canal. |
| ¿Qué debe ser utilizable? | Suficiente capacidad en la dirección del pago. | Suficiente capacidad utilizable y límites compatibles en cada salto. |
| ¿Qué puede bloquearlo? | Las restricciones del canal o un peer no disponible. | La disponibilidad, la comisión, el tiempo o la restricción de monto de cualquier salto. |
¿Qué compensaciones quedan después de trasladar los pagos a canales?
Lightning puede reducir la necesidad de competir por un bloque de Bitcoin en cada pago, pero no hace que las restricciones desaparezcan. Los fondos deben comprometerse en canales, la liquidez disponible puede variar según la dirección, y una ruta puede fallar si un salto no puede reenviar el monto. Los participantes de un canal también conservan una relación con Bitcoin para el financiamiento y la liquidación final de esos saldos.
Conclusión
Lightning es una respuesta puntual a una restricción específica: la capa base de Bitcoin no fue diseñada para registrar de inmediato cada pago pequeño y frecuente, y colocar cada uno en un bloque reintroduce la espera y la competencia por el espacio de bloque. Los canales permiten que los participantes comprometan BTC una vez, y luego acuerden entre sí nuevos estados de saldo a medida que se pagan mutuamente, sin difundir cada actualización como una transacción de Bitcoin separada.
La velocidad viene de trasladar las actualizaciones fuera de la capa base, no de escapar de ella. El financiamiento de un canal y su camino de cierre o de ejecución forzosa siguen siendo transacciones de Bitcoin, lo cual es lo que hace que el arreglo sea exigible. Por eso mismo Lightning no introduce un activo separado: los saldos que se actualizan son BTC, y se resuelven en Bitcoin cuando el canal se liquida.
La restricción que reemplaza al espacio de bloque es la liquidez, y esta es direccional. Un pago enrutado necesita capacidad utilizable en la dirección requerida en cada salto, junto con límites compatibles de comisión, tiempo y HTLC, así que una ruta puede fallar aunque un diagrama muestre los nodos conectados y aunque exista mucho valor en algún lugar de la red. Para un usuario, las expectativas prácticas son que los fondos deben comprometerse en canales antes de poder gastarse de esta forma, que un pago puede fallar por razones ajenas a tu propio saldo, y que la relación con la liquidación en Bitcoin nunca desaparece del todo.
Lightning es un ejemplo de una capa construida sobre Bitcoin para una tarea específica: los pagos frecuentes. Su velocidad viene de trasladar muchas actualizaciones a canales, no de eliminar las reglas de liquidación de Bitcoin. La próxima lección sigue un camino distinto en Ethereum, donde los rollups trasladan gran parte de la ejecución fuera de la capa base y envían de vuelta información agrupada en lotes.
Preguntas frecuentes
Una capa de pagos construida sobre Bitcoin para pagos frecuentes. Los participantes comprometen BTC en canales y luego actualizan saldos entre sí, usando la capa base de Bitcoin para abrir y liquidar esos canales, en lugar de para registrar cada pago individual. Existe para evitar competir por el espacio de bloque en cada transferencia pequeña.
Los participantes primero crean un arreglo de financiamiento que ancla el canal a Bitcoin. Dentro del canal, intercambian nuevos estados de saldo a medida que los pagos cambian quién puede reclamar qué monto, sin difundir cada actualización como una transacción de Bitcoin. Cuando necesitan terminar, el canal se cierra o usa su camino de compromiso para que el saldo resultante se resuelva en Bitcoin.
No. No existe una coin de Lightning separada. Lightning cambia la forma en que los pagos en BTC se actualizan y se enrutan; el valor que se mueve a través de los canales es BTC, y se liquida según las reglas de Bitcoin. Cualquier cosa que se presente como un token de Lightning distinto no forma parte de este diseño.
Porque la mayoría de los pagos nunca se convierten en transacciones individuales de Bitcoin. Actualizar el saldo de un canal no requiere esperar un bloque ni pujar por el espacio de bloque, así que evita la demora y la competencia por comisiones que implica la liquidación on-chain. La capa base se usa para abrir y liquidar canales, en lugar de para registrar cada pago.
Lo más común es que la ruta no pudo transportarlo. Un pago necesita un monto utilizable en la dirección requerida en cada salto, y también debe cumplir los límites de comisión, tiempo y monto de HTLC de cada salto. Basta con que un solo salto no esté disponible o esté demasiado restringido para impedir el pago, incluso cuando tu propio saldo es suficiente.
Si el pago específico que quieres hacer puede realmente viajar por una ruta en este momento. Es direccional: un canal que puede enviar en una dirección quizá no pueda enviar en la otra. Esto es distinto de cuánto valor total existe en toda la red, lo cual no dice nada sobre si una ruta en particular funcionará.
No. Lightning puede reenviar un pago a través de una secuencia de canales, y cada nodo que reenvía pasa un pago condicional al siguiente salto en lugar de tomar la custodia de un activo aparte. Ese enrutamiento es lo que permite que personas que nunca han abierto un canal entre sí puedan transactar, siempre que exista una ruta viable.
Es una capa construida sobre Bitcoin que depende de la capa base para la ejecución forzosa y la liquidación final, que es la forma general a la que la gente se refiere con Layer 2. Vale la pena señalar que resuelve un problema distinto al de los rollups de Ethereum: Lightning se enfoca en los pagos frecuentes, mientras que los rollups se enfocan en la ejecución general de transacciones.
Los saldos acordados dentro del canal se resuelven en Bitcoin. El canal se cierra de forma cooperativa o usa su camino de compromiso, y el resultado se convierte en una transacción de Bitcoin que refleja quién posee qué. Este es el punto en el que vuelven a aplicarse las comisiones y los tiempos de confirmación de la capa base.
Criptomonedas relacionadas
Sigue aprendiendo
Lecturas recomendadas a partir de esta lección.
- ¿Por qué existe Bitcoin?Parte del problema del doble gasto para entender por qué Bitcoin necesitaba un historial de transacciones compartido.
- Bitcoin: la primera Layer 1Descubre por qué Bitcoin es una red Layer 1, cómo sus propias reglas protegen a BTC, y por qué la liquidación implica compromisos.
- ¿Por qué Ethereum es programable?Descubre cómo Ethereum amplió la idea de Layer 1 con programas compartidos, el gas en ETH, y nuevos compromisos.
- ¿Por qué hay tantos tokens?Descubre cómo ERC-20 hizo que los tokens fueran reutilizables en las aplicaciones de Ethereum, y por qué un estándar compartido sigue dejando riesgos importantes.
