Lightning Network es una red descentralizada de canales de pago que permite realizar micropagos instantáneos y de alto volumen de transacciones con Bitcoin. Esta red elimina el riesgo de delegar la custodia de los fondos a terceros reduciendo las tarifas de transacción.
La red Lightning Network funciona como una capa adicional en la parte superior de la cadena de bloques de Bitcoin, lo que permite que las transacciones se realicen fuera de la cadena principal. Los usuarios pueden abrir canales de pago con otros usuarios y realizar transacciones sin necesidad de que cada transacción se registre en la cadena de bloques.
La capacidad de la Lightning Network ha aumentado significativamente en los últimos años, lo que demuestra su creciente popularidad y su potencial para resolver el problema de escalabilidad de Bitcoin. Esta red de pagos p2p es probablemente la innovación tecnológica más importante implementada en la cadena principal de Bitcoin.
La capa de pagos, propuesta por primera vez por Joseph Poon y Tadge Dryja en el año 2015, soporta un número virtualmente ilimitado de transacciones fuera de la cadena entre usuarios prácticamente sin ningún costo, aprovechando al mismo tiempo la seguridad ofrecida por Bitcoin.
Al menos tres compañías como, Poon y Dryja’s Lightning, Blockstream y Blockchain, trabajan con nuevas implementaciones de la tecnología, aunque muy pocos en este ámbito tecnológico pueden entender el futuro de los micropagos para aumentar las capacidades de la red de Bitcoin.
La red Lightning Network utiliza canales de pago bidireccionales entre dos partes, que permiten la realización de transacciones instantáneas sin la necesidad de que cada una sea confirmada por la red principal. Trabaja como una segunda capa sobre la red de Bitcoin utilizando contratos inteligentes para asegurarse de que la red sea segura. Los pagos son instantáneos, atómicos y con comisiones sumamente bajas, además, no son necesarias las confirmaciones de red.
¿Cómo se conforma la Red Lightning Network?
La red Lightning Network utiliza un concepto llamado enrutamiento para permitir que los pagos se realicen a través de múltiples canales.
Si dos participantes no tienen un canal directo entre ellos, la red encontrará una ruta de canales intermedios conectados para enrutar el pago de forma segura y privada.
Cada canal de pago tiene un saldo que se actualiza a medida que se realizan transacciones.
Cuando los participantes desean cerrar un canal y llevar los saldos actualizados a la cadena de bloques principal, pueden hacerlo presentando la transacción final en la cadena de bloques.
Esta red está diseñada para ser escalable, ya que permite que un gran número de transacciones se realicen fuera de la cadena, reduciendo así la carga en la cadena de bloques principal.
Además, la red promueve la privacidad, ya que las transacciones se realizan entre las partes involucradas sin que la información se haga pública en la cadena de bloques.
En resumen, Lightning Network es una solución de escalabilidad para las criptomonedas basadas en la blockchain.
Permite transacciones instantáneas y de bajo costo fuera de la cadena a través de canales de pago establecidos entre los participantes.
La red utiliza contratos inteligentes y enrutamiento para facilitar los pagos entre partes que no tienen un canal directo.
Con su enfoque en la velocidad, eficiencia y privacidad, ofrece una alternativa prometedora para abordar los desafíos de escalabilidad en las criptomonedas.
A continuación, repasemos en profundidad su funcionamiento interno a través de esquemas explicados lo más sencillo posible.
Bloque de construcción #1: Transacciones no confirmadas
En su esencia, el protocolo de Bitcoin consiste en transacciones, que suelen estar vinculadas a transacciones anteriores y potencialmente a transacciones futuras.
Cada transacción contiene entradas, que se refieren a las direcciones de los bitcoins que se envían desde las entradas y hacia las salidas, y que se refieren a direcciones a las que se envían.
Además, las entradas deben incluir los requisitos para enviar los bitcoins, como las firmas que demuestran la ‘propiedad’ de las direcciones de entrada.
Las salidas por su parte, establecen los nuevos requisitos que deben ser incluidos en la entrada de una transacción posterior.
Como una de sus características clave, la red Lightning Network se construye a partir de transacciones con Bitcoin regulares, solo que estas transacciones normalmente no se transmiten por la red de Bitcoin, en su lugar, se almacenan localmente en los nodos de los usuarios, aunque pueden transmitirse a través de la red en cualquier momento cumpliendo el concepto de red de pagos p2p.
Bloque de construcción #2: Protección de doble gasto
El segundo bloque de construcción para la Red Lightning Network, probablemente no requiere de mucha explicación, ya que es sin duda la razón de la existencia de Bitcoin en sí misma: la protección de doble gasto.
Si dos transacciones (o entradas) dependen de la misma salida, solo una puede confirmarse.
Lo importante a tener en cuenta aquí es que incluso las transacciones no confirmadas pueden ser conflictivas, es decir, solo una puede confirmarse.
Bloque de construcción #3: Multifirma
El tercer bloque de construcción de esta red es también sencillo: direcciones multifirma (multisig o direcciones P2SH)
Las direcciones multifirma son direcciones de Bitcoin que como su nombre lo indica, requieren múltiples claves privadas para ‘desbloquearse’ y gastar bitcoins.
Estas direcciones se pueden configurar con todo tipo de condiciones, por ejemplo, requerir 2 de 3 posibles claves, o 15 de 15, o casi cualquier otra combinación.
Lightning Network normalmente usa 2 de 2 configuraciones multifirma. Desbloquear bitcoins en 2 de 2 direcciones multifirma, requiere dos firmas de dos claves dedicadas.
Bloque de construcción #4: Bloqueo de tiempo
El cuarto bloque de construcción es el bloqueo de tiempo. Los bloqueos de tiempo pueden bloquear bitcoins en una salida, para hacerlos consumibles (para ser incluidos en una entrada posterior) solo en algún momento a futuro.
Hay dos tipos distintos de bloqueos de tiempo: el tipo absoluto, llamado CheckLockTimeVerify (CLTV), y el tipo relativo, CheckSequenceVerify (CSV).
CLTV bloquea bitcoins hasta un tiempo (más o menos) concreto a futuro: una hora y fecha actuales, o un tamaño de bloque específico.
En cambio CSV, utiliza el tiempo relativo.
Una vez que se graba una salida CSV en la cadena de bloques, se tarda una cantidad específica de bloques desde ese punto antes de que los bitcoins puedan volver a gastarse.
Bloque de construcción #5: Valores de hash y secretos
El quinto y último bloque de construcción que es la criptografía, es el elemento fundamental de Bitcoin, aunque en la red Lightning Network se aplica de una nueva forma.
En resumen, un ‘valor’ o ‘secreto’ es una cadena larga y única de números que es prácticamente imposible de adivinar, incluso para una computadora con intentos infinitos.
Con un cálculo especial, este valor puede ser ‘hasheado’ en una cadena diferente de números, un ‘hash’ y aquí está el truco: cualquier persona que conozca su valor, puede reproducir fácilmente dicho hash, aunque esto no funciona al revés, ya que es unidireccional, o sea, tiene sentido único.
Este truco puede ser utilizado con Bitcoin en sí mismo para ‘bloquear bitcoins’ (de hecho, así es realmente cómo funciona Bitcoin)
Por ejemplo, un hash puede ser incluido en una salida, y requiere una entrada posterior para incluir el valor correspondiente con el fin de ser consumible.
El primer desafío: canales de pago bidireccionales
Antes de que se presentara la Red Lightning Network, el concepto de los canales de pago había existido desde algún tiempo.
Los canales de pago típicos son útiles para ciertos propósitos, aunque también son limitados, ya que son unidireccionales.
Ana puede pagar a Bill varias transacciones fuera de la cadena, pero Bill no puede pagar a Ana por el mismo canal.
Como característica clave de la Lightning Network, los desarrolladores propusieron canales de pago bidireccionales sin confianza.
Apertura del canal
Para establecer un canal de pago bidireccional, ambas partes involucradas deben primero acordar una transacción de apertura.
Esta transacción de apertura determina cuántos bitcoins cada uno depositó en el canal.
Digamos que Ana quiere enviar 1 BTC a Bill. Dado que Ana y Bill esperan realizar transacciones más frecuentes, deciden abrir un canal de pago bidireccional y utilizarlo para enviar esa unidad de Bitcoin.
(Enviar 1 BTC es probablemente mucho para un canal de pago, ya que podría ser más útil para micropagos, aunque posible de todos modos)
Para abrir el canal, Ana y Bill envían 5 bitcoins a una dirección multifirma de 2-de-2. Esta es la ‘transacción de apertura’.
Los bitcoins solo se pueden gastar desde esta dirección, tanto si Ana como Bill firman una transacción posterior.
Además, Ana y Bill crean un secreto (una cadena de números) e intercambian el hash.
Ahora Ana inmediatamente crea una transacción posterior de la transacción de apertura. Esta es una ‘transacción de compromiso’.
Con la transacción de compromiso, Ana se envía 4 bitcoins a sí misma y 6 bitcoins a una segunda dirección multifirma.
Esta segunda dirección multifirma es un poco bizarra. Puede ser desbloqueada por Bill por su cuenta, aunque solo después de 1000 bloques extra que se hayan extraído luego de que se incluya de la blockchain, eso incluye un bloqueo CSV.
También puede ser abierto por Ana por su cuenta, aunque solo si ella también incluye el secreto por el que Bill acaba de darle el hash.
(Por supuesto, Ana no tiene ni idea de lo que es este secreto, ella solo sabe que es un hash, por lo que no hay manera de que haga uso de esta opción en ese momento)
Ana firma el final de esta transacción de compromiso. ¡Pero ella no lo transmite!, en su lugar, se lo ofrece a Bill.
Mientras tanto, Bill hace lo mismo, crea una transacción de compromiso, de la que se envía 6 bitcoins a sí mismo, y 4 a una nueva dirección multifirma.
Ana puede desbloquear esta dirección si espera otros 1000 bloques, o Bill puede desbloquearlo con Ana usando su secreto.
¡Bill firma esta mitad, y se la da a Ana!
Después de todo este intercambio de transacciones de compromiso con ‘mitad válida’ y hashes de secretos, ambos firman y transmiten la transacción de apertura para asegurarse de que está grabada en la cadena de bloques. El canal está ahora oficialmente abierto.
En este punto, tanto Ana como Bill podían firmar y difundir la transacción de compromiso con mitad válida que obtuvieron del otro. Si Ana lo hace, Bill obtiene 6 bitcoins inmediatamente.
Si Bill lo hace, Ana obtiene 4 bitcoins inmediatamente.
Quienquiera que firme y transmita la transacción, tendrá que esperar 1000 bloques para desbloquear la dirección multifirma posterior y reclamar los bitcoins restantes.
Sin embargo, este es el truco clave de un canal de pago: ni firmar ni difundir su mitad en absoluto de la transacción.
Actualización del canal
Un poco más tarde, Bill quiere enviar a Ana 1 BTC de vuelta, quieren actualizar el estado del canal para volver a hacer el balance de 5-5 otra vez. Para lograr esto, Ana y Bill hacen dos cosas:
Primero, ambos repiten el proceso como se describió anteriormente (excepto que la transacción de apertura ya está registrada en la cadena de bloques, esa parte se omite)
Esta vez, tanto Ana como Bill se atribuyen 5 bitcoins, y ambos atribuyen 5 bitcoins a la dirección multifirma bizarra que se comentó anteriormente.
Las condiciones para estas direcciones multifirma son similares, excepto que requieren nuevos secretos: tanto Ana como Bill se proveen con nuevos hashes. Ambos firman su nueva transacción de compromiso de media validez y se la dan a los demás.
En segundo lugar, Ana y Bill se entregan sus primeros secretos, como se utilizó en la primera construcción.
En este punto, nuevamente tanto Ana como Bill podrían firmar y difundir la nueva transacción de compromiso con mitad válida que acabaron de obtener.
Su contraparte obtendría 5 bitcoins inmediatamente, mientras que la transmisora tendría que esperar 1000 bloques. Como tal, el canal se actualiza.
Pero, ¿Qué impide a Bill transmitir la transacción de compromiso más antigua? Esa transacción de compromiso le llevó por un camino que le pagó 6 bitcoins, en lugar de 5.
Por supuesto, lo que detiene a Bill, es su primer secreto que ahora le ha otorgado a Ana.
Bill no puede firmar y transmitir con seguridad la transacción de compromiso más antigua, porque Ana ahora conoce el primer secreto de Bill.
Si Bill firmara y difundiera esa transacción de compromiso, inmediatamente enviaría 4 bitcoins a Ana y Bill tendría que esperar 1000 bloques para reclamar sus 6 bitcoins.
¡Esto ahora es un problema, porque Ana sabe su secreto, podría usarlo esta vez a su favor para vencer a Bill y reclamar los otros 6 bitcoins también!
Como Bill también tiene el secreto de Ana, esto es lo mismo por el lado contrario.
Si Ana intenta firmar y emitir una transacción de compromiso antigua, Bill puede robar todos los bitcoins del canal, esto por supuesto quiere decir, que tanto Ana como Bill están fuertemente incentivados a jugar las reglas del juego de manera justa y equitativa, y solo firmar y difundir el estado más reciente del canal.
A continuación, esta configuración del canal de pago bidireccional, debe ampliarse para permitir pagos a través de una red.
La red
En el apartado anterior, Ana y Bill establecieron un canal de pago bidireccional, ahora Ana quiere pagar 1 BTC a una tercera persona, Chris.
Para esto, Ana y Chris podrían abrir un canal de pago entre ellos, aunque en realidad no necesitan hacerlo.
Como resultado, Bill y Chris ya tienen un canal mutuo, por lo que Ana simplemente puede pagar a Chris a través de Bill.
Específicamente, Ana puede pagar a Bill 1 BTC, y Bill puede pagar a Chris 1 BTC.
Sin embargo, Ana realmente no confía en Bill o Chris para este asunto, tiene miedo de que si paga a Bill, Bill nunca pagará a Chris, o tal vez Bill le pague a Chris, pero Chris afirmará que nunca recibió el dinero, y Ana en este caso no sabría a quién culpar.
Ana por lo tanto, quiere asegurarse de que solo le pague a Bill 1 BTC, si también paga a Chris 1 BTC. Esto se logra (en parte) con un simple truco criptográfico.
Cuando Ana quiere enviarle a Chris 1 BTC, le dice a Chris que cree un valor (una cadena aleatoria de números) y le envíe el hash.
Ana también le dice a Chris que intercambie el valor original con Bill por 1 BTC.
Ana mientras tanto toma el hash de Chris, se la devuelve a Bill y le dice que le dará 1 BTC si le proporciona el valor correspondiente (que tiene solamente Chris)
Así, Bill se la devuelve a Chris y le da 1 BTC a cambio del valor.
Entonces, Bill se la devuelve a Ana con el valor. Ana sabe que Bill debe haber obtenido el valor de Chris a cambio de 1 BTC, y por lo tanto concluye que Chris consiguió su unidad de Bitcoin. Así que Ana puede darle confianza a Bill por 1 BTC.
¡Finalmente, todos están contentos!
¡Bueno, mejor dicho, casi todos contentos!
En este escenario ingenuo, el intermediario Bill todavía tiene que confiar en Ana y en Chris.
Bill tiene que confiar en Chris para darle el valor después de que le haya enviado 1 BTC, y Bill tiene que confiar en Ana para darle 1 BTC una vez que se le presente el valor.
Por lo tanto, las operaciones Bitcoin-For-Value deben estar absolutamente garantizadas a lo largo de la red.
Más específicamente, si Bill le da 1 BTC a Chris, tiene que estar garantizado de recuperar la unidad de Bitcoin de Ana.
Ahí es donde entran en juego los Contratos de Bloqueo de Tiempo del Hash (HTLC).
Contratos de Bloqueo de Tiempo del Hash
Así que Ana y Bill quieren intercambiar 1 BTC por el valor a través de un HTLC.
(Bill y Chris también quieren intercambiar 1 BTC por ese mismo valor, aunque eso no importa por ahora)
Para hacerlo, en lugar de enviar a Bill 1 BTC directamente, Ana envía 1 BTC a una nueva dirección multifirma.
Los bitcoins bloqueados en esta dirección se pueden desbloquear de dos maneras distintas.
La primera opción es que Bill incluya su firma y el valor.
La segunda opción es que Ana incluya su propia firma.
Sin embargo, esta opción tiene un bloqueo de tiempo-CLTV en ella: Ana puede firmar y difundir la transacción solo después de que hayan pasado dos semanas.
Esto significa que Bill tiene dos semanas para crear una transacción posterior en la que incluya su firma, el valor y la transmisión para enviar la unidad de Bitcoin desde la dirección multifirma a sí mismo.
Como tal, este comercio está garantizado. Bill solo puede reclamar la unidad de Bitcoin de Ana si proporciona el valor: transmitirlo a través de la red de Bitcoin lo hace visible públicamente para que Ana lo vea.
Y si Bill no proporciona el valor en el tiempo, hay una ‘alternativa fuera de tiempo’ para que Ana recupere su unidad de Bitcoin. Así de sencillo.
Vuelve a la red, ya que es realmente la razón de que la configuración HTLC sea necesaria.
Como se mencionó, no solo Ana y Bill, sino también Bill y Chris establecieron un HTLC.
Por lo tanto, si Chris reclama 1 BTC de Bill, Bill obtendrá el valor a cambio y este será visible en la cadena de bloques.
Por lo tanto si eso sucede, Bill se garantiza también obtener 1 BTC de Ana.
Bill puede tomar el valor que Chris hizo visible públicamente en la cadena de bloques, incluirlo en su HTLC con Ana y también reclamar 1 BTC para sí mismo. Los dos canales están efectivamente vinculados.
Como detalle final, es importante que Bill reciba el valor de Chris antes de que Ana pueda recuperar 1 BTC de Bill.
Si Bill obtiene el valor de Chris, solo después de que Ana haya recuperado la suya, Bill estará atrapado en medio de todos modos.
El tiempo de espera en el HTLC de Bill y Chris, tiene que expirar antes de que expire el tiempo de espera en el HTLC de Ana y Bill. (Por ejemplo, luego de diez días exactos, en lugar de dos semanas).
Esto es así porque los HTLC necesitan CheckLockTimeVerify (CLTV) y no CheckSequenceVerify (CSV).
Para concluir, hay un problema más que resolver para que la red Lightning Network sea útil, todo esto debe llevarse a cabo fuera de la cadena.
La auténtica red Lightning Network
Hasta ahora, Ana y Bill abrieron un canal de pago bidireccional, por el cual ambos financiaron con 5 bitcoins.
Han hecho dos transacciones de ida y vuelta, y en el estado actual del canal, tanto Ana como Bill pueden reclamar 5 bitcoins por sí mismos ‘dejando el canal’ en la cadena de bloques.
Ahora, quieren incluir un HTLC en el canal. Esto es para asegurarse de que si Chris reclama 1 BTC de Bill a cambio de su valor, Bill se garantiza a cambio 1 BTC de Ana.
Al igual que en el paso anterior, Ana y Bill comienzan creando una nueva transacción de compromiso cada uno.
En muchos sentidos, estas transacciones de compromiso son muy similares a las transacciones de compromiso anteriores.
Incluyen una salida normal y una salida a una dirección bizarra multifirma con un bloqueo de tiempo-CSV (CheckSequenceVerify) y un bloqueo de hash especial.
Del mismo modo que en el paso anterior, Ana y Bill intercambian sus viejos secretos para invalidar efectivamente el viejo canal.
Una vez intercambiados, tanto Ana como Bill pueden firmar sus mitades de las transacciones de compromiso y potencialmente dejarlas en la cadena de bloques en cualquier momento.
Todo está en territorio familiar, excepto por un cambio. Las transacciones de compromiso de Ana y Bill incluyen ahora una nueva salida que vale 1 BTC. (Esto hace un balance 4-5-1, 4 para Ana, 5 para Bill, 1 para la nueva salida)
Esta nueva salida es esencialmente el HTLC. Es incluso más bizarra que todas las otras salidas hasta el momento, porque hay tres maneras de desbloquearla.
En primer lugar, la nueva salida (en ambas transacciones de compromiso de Ana y Bill) libera la unidad de Bitcoin a condición de que la firma de Bill y el valor se incluya en la transacción posterior.
Como tal, independientemente de si Ana o Bill firman y transmiten la transacción de compromiso, solo Bill puede desbloquear esta salida si incluye el valor.
Pero hay una pequeña diferencia entre las dos transacciones de compromiso: si Bill deja el canal, hay un bloqueo de tiempo-CSV involucrado. Tendrá que esperar 1000 bloques. (Si Ana deja el canal, puede reclamar esta unidad de Bitcoin inmediatamente)
La razón por la que Bill tiene que esperar 1000 bloques si deja el canal, es muy similar a lo que se ha visto antes: permite que Ana tome esta unidad de Bitcoin en caso de que Bill alguna vez intente firmar y transmitir un estado antiguo del canal.
Ahí es donde entra en juego la segunda forma de desbloquear la salida. Ana puede robar los fondos si proporciona el secreto más reciente de Bill.
Dos pueden jugar este juego: si Ana trata de engañar y difundir este canal cuando ya está obsoleto, Bill puede reclamar esta unidad de Bitcoin usando el secreto de Ana. (Ni siquiera tendría que proporcionar el valor)
Y en tercer lugar, como con cualquier otro HTLC, ambas transacciones de compromiso también incluyen el tiempo de espera del CLTV habitual para Ana.
Si Bill no incluye el valor, digamos en 2 semanas (por ejemplo, porque no lo obtuvo de Chris), Ana puede reclamar su unidad de Bitcoin de vuelta. Una vez más, si Ana o Bill dejan el canal, no importa esta opción.
Entonces, ¿De dónde conseguimos todo esto?
Tanto Ana como Bill tienen una transacción de compromiso con mitad válida.
Si Ana deja su transacción de compromiso en la cadena de bloques, inmediatamente envía 5 bitcoins a Bill.
Además, puede esperar 1000 bloques y reclamar 4 bitcoins para sí misma.
También, Bill tiene dos semanas para proporcionar el valor y reclamar 1 BTC en la salida HTLC.
(Si no proporciona el valor en 2 semanas, Ana puede reclamar esta unidad de Bitcoin de vuelta)
Bill por su parte, también puede cancelar su transacción de compromiso en cualquier momento e inmediatamente enviar 4 bitcoins a Ana.
Entonces, tendría que esperar 1000 bloques para reclamar 5 bitcoins más de una dirección y otro Bitcoin de la salida HTLC si proporciona el valor. (Si no proporciona el valor en 2 semanas, Ana puede reclamarlo)
Y por supuesto, si Ana o Bill tratan de engañar en cualquier momento en el futuro, firmar y difundir este canal cuando esté obsoleto, ambos pueden bloquear completamente el otro canal y robar todos los bitcoins.
Solución del estado
En este punto, Bill se garantiza de recibir 1 BTC a cambio del valor (suponiendo que él lo tenga).
Todo lo que tiene que hacer es firmar y difundir la transacción de compromiso que obtuvo de Ana, incluir el valor en una transacción posterior, firmar y difundirlo también.
Ana lo sabe. No hay manera de que pueda engañar a Bill de su unidad de Bitcoin, ni siquiera si ella hubiese descubierto que el valor fuera mediante otros medios.
Como tal, los dos podrían tan solo ‘resolverlo’ fuera del canal.
Bill puede simplemente darle el valor a Ana, y ella puede acordar actualizar el estado del canal, al estado más normal sin el HTLC y el plazo límite.
Asumiendo que ambas partes quieren mantener el canal abierto, eso es lo que naturalmente harían, por lo tanto, es menos complicado que tener que dejar el canal en la cadena de bloques.
Cierre del canal
Finalmente, aquí está el verdadero poder de la red Lightning Network: con respecto a casi todo lo descrito anteriormente, nunca tendrá que impactar en la cadena de bloques de Bitcoin en absoluto.
Si tanto Ana como Bill quieren cerrar el canal pacíficamente, pueden crear una transacción simplemente desde la transacción de apertura original para anular todo lo que haya sucedido desde la transacción de apertura.
A partir de esta transacción de cierre, se envían ellos mismos su parte equitativa del canal, tal y como se representa por el estado del canal más reciente.
Concretamente, esto significa que si Ana quiere cerrar el canal, simplemente puede crear una transacción pagándose a sí misma 4 bitcoins y a Bill 6 bitcoins, y pedirle a Bill que firme y transmita la transacción.
Dado que no hay razón para que no lo haga, probablemente cooperará y cerrará el canal.
Al final, solo dos transacciones se habrán transmitido a través de la red de Bitcoin e incluidas en un bloque: las operaciones de apertura y cierre.
Esto será verdadero incluso, si Ana y Bill, entre ellos mismos se transaccionan un millón de veces, por lo tanto se simplifica una enorme carga de la cadena de bloques.
Ventajas y desventajas del Lightning Network
Ventajas
- Escalabilidad: La red Lightning Network permite una mayor escalabilidad al procesar un gran número de transacciones fuera de la cadena, reduciendo la carga en la cadena de bloques principal. Esto ayuda a evitar la congestión y los altos tiempos de confirmación de transacciones.
- Velocidad de transacción: las transacciones en esta red son instantáneas, lo que significa que los pagos pueden realizarse de manera rápida y eficiente sin tener que esperar confirmaciones en la cadena de bloques. Esto facilita el uso de criptomonedas en transacciones diarias.
- Bajas tarifas: debido a que las transacciones no necesitan ser registradas en la cadena de bloques principal para cada transacción individual, las tarifas asociadas son significativamente más bajas en comparación con las transacciones en la cadena de bloques principal.
- Privacidad: ofrece un mayor nivel de privacidad en comparación con las transacciones tradicionales en la cadena de bloques. Las transacciones se realizan entre las partes involucradas y no se hacen públicas en la cadena de bloques principal, lo que brinda un mayor grado de confidencialidad.
- Micropagos eficientes: permite realizar micropagos de forma eficiente, lo que es especialmente beneficioso para casos de uso como el pago por contenido en línea, servicios de transmisión de música o videojuegos.
Desventajas
- Requiere canales de pago: para utilizar esta red, los usuarios deben abrir canales de pago en la cadena de bloques principal, lo que implica una transacción y un tiempo de confirmación. Esto puede resultar inconveniente y requerir una planificación previa.
- Requiere conectividad y liquidez: para enrutar pagos a través de esta red, se requiere que los canales de pago estén conectados y tengan suficiente liquidez. En algunos casos, puede haber limitaciones para encontrar rutas de pago adecuadas, lo que puede afectar la capacidad de realizar transacciones.
- Riesgo de fondos bloqueados: en casos raros, puede haber problemas técnicos o fallos en la red que podrían resultar en la pérdida temporal de los fondos bloqueados en los canales de pago. Sin embargo, se están desarrollando mejoras continuas para mitigar estos riesgos.
- Complejidad técnica: la configuración y administración de los canales de pago en esta red, puede ser técnicamente compleja para los usuarios promedio. Se requiere un conocimiento más profundo de la tecnología y las transacciones fuera de la cadena.
- No es adecuada para todas las transacciones: aunque esta red es eficiente para transacciones pequeñas y frecuentes, no es la mejor opción para transacciones de alto valor debido a las limitaciones de capacidad y liquidez en los canales de pago.
Es importante tener en cuenta que la red Lightning Network aún sigue en desarrollo y continúa evolucionando.
Si bien presenta ventajas significativas, también existen desafíos y limitaciones que se están abordando mediante mejoras y actualizaciones continuas.
