Las transacciones de Bitcoin no pueden confirmarse de forma definitiva en unos pocos milisegundos. Compiten por un espacio de bloque limitado, y solo se mina un nuevo bloque aproximadamente cada diez minutos en promedio. Entonces, ¿cómo puede un pago de Lightning llegar a una tienda al otro lado del mundo casi al instante y por una comisión muy baja?
La respuesta no es una blockchain más rápida. De hecho, los pagos de Lightning no se registran en absoluto en la blockchain de Bitcoin; al menos, no la gran mayoría de ellos.
En su lugar, los usuarios de Lightning bloquean bitcoin en los llamados canales de pago e intercambian actualizaciones firmadas que modifican quién puede reclamar esas monedas. Estos canales forman una red, lo que permite que un pago viaje a través de varios participantes, incluso cuando el emisor y el receptor no tienen una conexión directa.
Muchos ya han utilizado la red Lightning, pero pocos entienden cómo funciona realmente. Vamos a desarmarla pieza por pieza.
¿Por qué necesitamos Lightning?
Cada transacción regular de Bitcoin debe distribuirse por toda la red, ser verificada por los nodos, incluirse en un bloque y almacenarse en la blockchain para siempre. Esto hace que Bitcoin sea verificable de forma independiente: cualquiera puede ejecutar un nodo y verificar el historial completo sin pedir permiso a un banco o procesador de pagos.
Esa propiedad conlleva una restricción deliberada. El espacio de los bloques es limitado, lo que significa que no cada persona en el mundo puede comprar su café de la mañana con una transacción regular de Bitcoin. Simplemente no hay suficiente espacio. Aumentar el tamaño del bloque sin límites elevaría los requisitos de ancho de banda, computación y almacenamiento para ejecutar un nodo, haciendo que la verificación independiente sea cada vez más difícil.
Por lo tanto, Lightning adopta un enfoque diferente. Las transacciones de Bitcoin se mantienen como la capa de liquidación, mientras que los pagos repetidos ocurren en una segunda capa. En lugar de pedirle a toda la red de Bitcoin que registre cada compra de café, dos participantes pueden liquidar muchos pagos entre ellos y publicar solo el resultado cuando sea necesario.
Un aspecto importante a tener en cuenta es: Lightning es Bitcoin. Sigue estando profundamente ligado a la red de Bitcoin y no es “una moneda nueva”. Los pagos de Lightning son pagos de Bitcoin, solo que utilizan el espacio de bloque limitado disponible de manera más eficiente y con menos frecuencia.
Un canal de pago comienza en Bitcoin
Imagina que Alice quiere usar 0.001 BTC o 100,000 satoshis para pagos de Lightning. Ella abre un canal con Bob creando una transacción de Bitcoin que bloquea esas monedas en una billetera controlada por ambos participantes del canal. Puedes pensar en ella como una billetera multisig especial de 2 de 2, donde tanto Alice como Bob tienen una clave y solo pueden gastar fondos juntos.
Como descubriremos más adelante, hay algunas propiedades importantes que esta billetera multisig debe cumplir para que el canal de pago funcione de forma segura y sin necesidad de confianza. Pero por ahora, estos detalles no son importantes.
La transacción de fondeo se registra en la blockchain de Bitcoin. Una vez que tiene suficientes confirmaciones, el canal se puede utilizar para pagos.
Al principio, el canal podría verse así, con todo el saldo del lado de Alice, ya que ella envió la transacción de apertura:
- Alice: 100,000 sats
- Bob: 0 sats
- Capacidad total: 100,000 sats
Remember the bitcoin have not left the blockchain. They are just sitting in a different wallet now. What changes during the life of the channel is the valid agreement about how that money can be spent. Let’s explore an example…
Recuerda que los bitcoin no han salido de la blockchain. Simplemente están en una billetera diferente ahora. Lo que cambia durante la vida del canal es el acuerdo válido sobre cómo se puede gastar ese dinero. Exploremos un ejemplo…
Los pagos son acuerdos
Imagina un contrato de alquiler para un apartamento donde tienes que pagar un depósito de seguridad de 1000 USD al propietario. Cuando el contrato se cancela, el arrendador está obligado a devolver esos 1000 USD. Pero supongamos que quieres pagarle al arrendador por un mueble suyo que dañaste. Podrías simplemente enviarle una transacción bancaria regular o entregarle efectivo. Sin embargo, en su lugar, ambos podrían simplemente actualizar el contrato de alquiler a un depósito de seguridad más bajo, por ejemplo, a 900 USD. De esa manera, efectivamente le pagaste 100 USD al propietario, sin mover dinero, solo actualizando un contrato.
Esto es (más o menos) exactamente cómo funciona un canal de Lightning. Los 1000 USD en este ejemplo serían la capacidad del canal, y tú y el arrendador podrían "enviarse" dinero mutuamente actualizando el contrato tantas veces como quieran. Y una vez que el contrato termina, simplemente liquidan la cantidad que esté establecida actualmente como depósito de seguridad.
El contrato en Bitcoin
In Bitcoin, we’re not talking about rental contracts, of course, but transactions. The two concepts are not far apart though, as signing a Bitcoin transaction is conceptually almost the same as signing a contract.
En Bitcoin, no estamos hablando de contratos de alquiler, por supuesto, sino de transacciones. Sin embargo, los dos conceptos no están muy alejados, ya que firmar una transacción de Bitcoin es conceptualmente casi lo mismo que firmar un contrato.
Volvamos a nuestro canal de pago: Supongamos que Alice le paga a Bob 20,000 sats. Ellos no crean ni transmiten una transacción regular de Bitcoin. En su lugar, sus nodos de Lightning construyen y firman un nuevo par de transacciones de liquidación que reflejan el saldo actualizado:
- Alice: 80,000 sats
- Bob: 20,000 sats
Estas se denominan transacciones de compromiso (commitment transactions). Cada participante posee una transacción válida que podría publicar para cerrar el canal y liquidar el último saldo acordado en cualquier momento. Las dos versiones difieren en sus detalles porque cada una está diseñada para ser publicada por una parte en particular, pero ambas representan el mismo estado del canal.
Si Bob más tarde le paga 5,000 sats de vuelta a Alice, los nodos crean otro estado y otro conjunto de transacciones no publicadas:
- Alice: 85,000 sats
- Bob: 15,000 sats
Nuevamente, nada se ha transmitido a la red de Bitcoin. Alice y Bob simplemente han reemplazado su acuerdo de liquidación anterior por uno más nuevo. Pueden repetir este proceso muchas veces sin esperar a un bloque ni pagar comisiones de transacción. Al igual que con el depósito de seguridad actualizado en el contrato de alquiler.
Esta es la primera idea importante sobre Lightning: un saldo fuera de la cadena (off-chain) en un canal de Lightning no es una entrada en un libro contable global como las transacciones regulares. Es el conjunto más reciente de transacciones de Bitcoin que los participantes del canal han firmado.
Robando el saldo del canal
Ahora, podrías plantearte la pregunta de por qué Alice, por ejemplo, no transmitiría simplemente un acuerdo de liquidación antiguo a la red de Bitcoin. Después de todo, las transacciones de Bitcoin firmadas siguen siendo válidas y, al hacerlo, ella podría revertir efectivamente los pagos que le hizo a Bob, o en otras palabras, robar las monedas.
En nuestro ejemplo anterior del contrato de alquiler, el sistema judicial, es decir, un juez en un tribunal, sería capaz de resolver una disputa entre el arrendador y el inquilino, respetando el contrato firmado más reciente entre ambos. En Bitcoin, ese proceso es más complicado. Necesitamos un mecanismo puramente técnico, ya que no hay un tercero de confianza en el que podamos confiar.
Cada vez que un canal pasa a un nuevo estado, ambas partes intercambian información que revoca el anterior. Esto se hace criptográficamente al revelar una determinada clave, que la otra parte puede usar en caso de que intentes hacer trampa. Si Alice intenta transmitir una transacción de compromiso ya revocada, es decir, intenta hacer trampa, su propio pago se retrasa. Durante este retraso, Bob puede usar la información de revocación para demostrar que Alice publicó un estado antiguo y reclamar todos los fondos que ella intentó llevarse.
Cada vez que un canal pasa a un nuevo estado, ambas partes intercambian información que revoca el anterior. Esto se hace criptográficamente al revelar una determinada clave, que la otra parte puede usar en caso de que intentes hacer trampa. Si Alice intenta transmitir una transacción de compromiso ya revocada, es decir, intenta hacer trampa, su propio pago se retrasa. Durante este retraso, Bob puede usar la información de revocación para demostrar que Alice publicó un estado antiguo y reclamar todos los fondos que ella intentó llevarse.
Los scripts exactos utilizados en estas transacciones son más complejos, pero el incentivo es simple: intentar liquidar un saldo desactualizado puede costarle a la parte deshonesta todos los fondos de su canal. No solo eso, sino que también pierden la confianza económica dentro de la red, lo que desincentiva a otros a abrir nuevos canales con ellos.
Este mecanismo de penalización también explica por qué un nodo de Lightning no puede ignorar la blockchain para siempre. Bob debe detectar el cierre de un canal desactualizado y reaccionar dentro de la ventana de disputa. El nodo no necesita estar en línea cada segundo, pero debe verificar con la frecuencia suficiente, o delegar este monitoreo a alguien más, que es lo que se llamaría una torre de vigilancia (watchtower). Este es uno de los mayores compromisos de seguridad de Lightning: necesitas vigilar tu dinero.
Los canales forman una red
Tal vez lo hayas adivinado: el concepto de un solo canal de pago, que permite un número arbitrario de pagos entre dos participantes, ahora puede extenderse a una red de canales de pago interconectados, lo que permite un número arbitrario de pagos entre muchos más participantes.
Un canal entre Alice y Bob es útil, pero abrir un canal separado con cada persona o tienda anularía gran parte del propósito. En su lugar, Bob puede tener otro canal abierto con Carol, quien a su vez tiene un canal abierto con David.
Esto ahora le permite a Alice crear un pago para David, enrutando el pago a través de diferentes canales:
Aunque Alice no tiene un canal directo con David, podemos actualizar los tres canales de tal manera que el valor se mueva de Alice a David:
- Alice envía 1000 sats a Bob.
- Bob envía 1000 sats a Carol.
- Carol envía 1000 sats a David.
- David recibió efectivamente 1000 sats de Alice.
Bob and Carol forward the payment using bitcoin they already have available on the correct side of their own channels. They may charge a small routing fee for providing this service, i.e. liquidity and keeping their nodes online. This is why Lightning payments still come with a small transaction fee.
Bob y Carol reenvían el pago utilizando bitcoin que ya tienen disponibles en el lado correcto de sus propios canales. Pueden cobrar una pequeña comisión de enrutamiento por proporcionar este servicio, es decir, liquidez y mantener sus nodos en línea. Por esto es que los pagos de Lightning todavía conllevan una pequeña comisión de transacción.
Desafortunadamente, ese no es el final de la historia, porque acabamos de crear un nuevo problema: Alice no debería pagarle a Bob a menos que pueda estar segura de que David recibirá el pago. Bob no debería pagarle a Carol a menos que el pago entrante de Alice esté garantizado. Y Carol no debería poder tomar el dinero de Bob sin completar el pago a David.
Lightning resuelve esto con pagos condicionales.
El secreto que vincula cada salto
Cuando David crea una factura típica de Lightning, su billetera genera un secreto aleatorio. El secreto en sí se llama una preimagen (preimage), un término sofisticado de la criptografía para referirse a "lo que existía al principio". Luego, la billetera coloca una huella digital de esta preimagen, es decir, un valor hash, en la factura de Lightning.
Alice utiliza ese hash de pago para configurar una cadena de los llamados Contratos de bloqueo de tiempo hasheado (Hashed Timelock Contracts), generalmente abreviados como HTLCs. Cada contrato dice, en términos simplificados:
Puedes reclamar este pago si revelas el secreto que coincide con este hash antes de la fecha límite. De lo contrario, el emisor recupera el dinero.
Alice le ofrece dicho pago condicional a Bob. Bob le ofrece uno correspondiente a Carol, y Carol le ofrece uno a David. Los plazos se vuelven más cortos hacia el receptor, de modo que cada nodo de reenvío tenga tiempo de recuperar su pago entrante si un salto posterior debe resolverse en la cadena.
David conoce el secreto, así que puede revelarlo y reclamar el pago final. Una vez que Carol conoce el secreto, puede reclamar el dinero de Bob. Bob finalmente puede reclamar el de Alice. La misma prueba desbloquea el pago hacia atrás a lo largo de toda la ruta.
Si la ruta se rompe o David nunca revela el secreto, el HTLC vence y los cambios pendientes se cancelan o se reembolsan. Esto hace que el pago sea atómico: o bien se completa a lo largo de toda la ruta, o bien falla sin dejar a nadie colgado, habiéndole pagado al siguiente sin recibir nada a cambio.
En el funcionamiento normal, todo esto ocurre a través de mensajes entre nodos de Lightning. Las transacciones HTLC importan porque cada participante podría hacer cumplir el resultado en Bitcoin si la cooperación se rompe. En otras palabras: todos estos contratos sofisticados, con criptografía que garantiza que nadie pueda hacer trampa, son una vez más simplemente transacciones de Bitcoin firmadas. Si algo sale mal, la transacción se puede publicar en la blockchain de Bitcoin y las monedas vuelven a donde pertenecen.
Cómo se cierra un canal
Al igual que cualquier contrato de alquiler, un canal de Lightning no permanecerá abierto para siempre, y existen dos formas principales de cerrarlo.
- En un cierre cooperativo, ambos participantes se ponen de acuerdo sobre el saldo final y firman una transacción de cierre. Este suele ser el resultado más económico y sencillo. Una vez que esa transacción se confirma, cada participante vuelve a controlar su parte directamente en la cadena. Siguiendo con nuestra analogía, el inquilino y el arrendador simplemente se han puesto de acuerdo sobre el monto del depósito final que se va a liquidar.
- En un cierre unilateral, un participante publica su última transacción de compromiso sin la cooperación del otro participante. A esto a veces se le llama un cierre forzado (force close). Es una característica de seguridad esencial: ninguna de las partes puede mantener como rehén el bitcoin de la otra al desconectarse o negarse a firmar.
Un cierre unilateral es más lento y puede ser más costoso. Los bloqueos de tiempo (timelocks) deben vencer, y los HTLC no resueltos pueden requerir transacciones adicionales en la cadena. Pero mientras el usuario tenga el último estado válido del canal y monitoree la blockchain cuando sea necesario, el protocolo proporciona una salida unilateral ejecutada en la blockchain de Bitcoin.
Esta es la base del modelo de seguridad de Lightning. Los participantes cooperan para obtener velocidad, pero no tienen que confiar el uno en el otro para la custodia. La red de Bitcoin actúa como el juez final cuando no están de acuerdo, al igual que en el ejemplo del contrato de alquiler.
¡Eso es todo! Hemos desglosado las partes clave de un pago en la red Lightning. Por supuesto, a partir de aquí habría muchas oportunidades para profundizar más: ¿Cómo encuentra un nodo una ruta a través de la red? ¿Existen diferentes mecanismos de penalización y cómo se comparan? ¿Cómo se pueden eludir las restricciones de liquidez? Pero por ahora, dejémoslo en los componentes principales.
Dónde encaja una billetera de hardware
Una billetera de hardware y una billetera de Lightning resuelven problemas completamente diferentes.
La BitBox está diseñada para mantener seguras tus claves privadas para fondos a largo plazo y las transacciones deben confirmarse y verificarse manualmente en su pantalla segura. Esto es excelente para la seguridad, pero poco práctico para Lightning: cada vez que se envía o recibe un pago, es necesario firmar nuevos estados del canal en interacción con otros nodos de Lightning. A menos que acampes frente a tu billetera de hardware las 24 horas del día, listo para confirmar un pago entrante.
Por lo tanto, para muchos usuarios, la configuración práctica es similar a una cuenta de ahorros y una billetera física: mantener cantidades más grandes en almacenamiento en frío en una billetera de hardware, y mover solo un saldo menor para gastos a una billetera de Lightning de autocustodia. Esto limita la cantidad expuesta si el teléfono, la computadora o la billetera de Lightning se ven comprometidos, mientras se preserva la conveniencia de los pagos instantáneos.
La autocustodia sigue importando en Lightning. Antes de elegir una billetera, verifica si tú mismo controlas las claves, cómo funciona la recuperación, quién administra los canales y qué sucede si el proveedor de la billetera desaparece. El término "Billetera de Lightning" describe una tecnología de pago, no un modelo de seguridad universal.
We are still actively working on integrating a Lightning wallet into the BitBoxApp, enabling a seamless user experience between these two wallet philosophies. The hardware wallet can still play a role, however, by deriving the private keys for the Lightning wallet from its own backup, to avoid having to manage a new backup for the Lightning wallet.
Todavía estamos trabajando activamente en la integración de una billetera de Lightning en la BitBoxApp, permitiendo una experiencia de usuario fluida entre estas dos filosofías de billetera. Sin embargo, la billetera de hardware aún puede desempeñar un papel al derivar las claves privadas para la billetera de Lightning a partir de su propio respaldo, para evitar tener que gestionar un nuevo respaldo para la billetera de Lightning.
Conclusión
La red Lightning no es una parte separada de bitcoin ni un atajo para eludir las reglas de Bitcoin. Es una red de canales de pago respaldada por transacciones reales de Bitcoin.
Los participantes del canal actualizan las transacciones firmadas en lugar de transmitir cada pago. Los mecanismos de revocación desincentivan que cualquiera de las partes intente hacer trampa. Scripts complejos de Bitcoin vinculan varios canales para que un pago enrutado se complete de extremo a extremo o falle de manera segura.
Así es como Lightning puede sentirse instantáneo sin depender de un procesador de pagos centralizado. Su velocidad proviene de mover la actividad rutinaria fuera de la cadena; su seguridad proviene de mantener un camino de regreso a Bitcoin. El resultado se adapta bien a los pagos cotidianos, siempre que los usuarios comprendan las ventajas y desventajas en torno a la liquidez, la disponibilidad, los respaldos y el riesgo de las billeteras calientes.
Para los ahorros a largo plazo, el almacenamiento en frío seguirá siendo, por lo general, la mejor herramienta. Para pagos pequeños y frecuentes, Lightning ofrece un complemento atractivo, no un reemplazo, para la capa principal de Bitcoin.
¿Aún no tienes una BitBox?
Proteger tus criptomonedas no tiene por qué ser complicado. Las billeteras de hardware BitBox almacenan las llaves privadas de tus criptomonedas sin conexión, para que puedas gestionar tus monedas de forma segura.
Tanto la BitBox02 Nova como la BitBox02 también están disponibles en una edición exclusiva para Bitcoin, con un firmware radicalmente enfocado: menos código significa una menor superficie de ataque, lo que mejora aún más tu seguridad si solo guardas bitcoin.
¡Consigue una BitBox02 Nova o una BitBox02 en nuestra tienda!
Shift Crypto es una empresa privada con sede en Zurich, Suiza. Nuestro equipo de colaboradores de Bitcoin, expertos en criptomonedas e ingenieros de seguridad crea productos que permiten a los clientes disfrutar de un viaje sin estrés desde el nivel de principiante hasta el nivel de maestría en la gestión de criptomonedas. La BitBox02, nuestra billetera de hardware de segunda generación, permite a los usuarios almacenar, proteger y realizar transacciones con Bitcoin y otras criptomonedas con facilidad, junto con su software complementario, la BitBoxApp.