¿Qué es la Red Lightning?

La cadena de bloques tradicional puede ser reemplazada con mejoras y errores para asegurar una mejor calidad de la red Bitcoin en futuras transacciones a través de la Red Lightning

La red de pagos p2p denominada Red Lightning, es probablemente la innovación tecnológica más importante implementada en la parte principal de la red Bitcoin.

La capa de pagos, propuesta por primera vez por Joseph Poon y Tadge Dryja hace 2 años aproximados, soporta un número virtualmente ilimitado de transacciones fuera de la cadena entre los usuarios casi sin ningún costo, aprovechando al mismo tiempo la seguridad ofrecida por Bitcoin.

Al menos tres empresas, Poon y Dryja’s Lightning, Blockstream y Blockchain, trabajan en nuevas implementaciones de la tecnología, pero muy pocos fuera de este pequeño frente tecnológico pueden entienden completamente cómo el “futuro de los micropagos” se ajusta para aumentar las capacidades del Bitcoin.

En este artículo se establecen tres componentes básicos de la Red Lightning, y muestran cómo encajan juntos para innovar esta capa del protocolo. 

Esta característica establece los bloques de construcción necesarios y muestra cómo pueden combinarse para crear “contratos inteligentes”, que pueden aplicarse para realizar el primer requisito de la Red Lightning: un canal de pagos bidireccional.

Red Lightning



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 los bitcoins.

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 se construye a partir de transacciones de Bitcoin más o menos regulares, solo que estas transacciones normalmente no se transmiten por la red Bitcoin, en su lugar, se almacenan localmente en los nodos de los usuarios, pero pueden transmitirse a través de la red en cualquier momento cumpliendo el concepto de red de pagos p2p.

Red Lightning-transacciones no confirmadas

Bloque de construcción #2: Protección de doble gasto

El segundo bloque de construcción para la Red Lightning probablemente no requiere de mucha explicación, ya que es sin duda la razón de ser 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.

Red Lightning-protección de doble gasto

Bloque de construcción #3: Multisig

El tercer bloque de construcción de la Red Lightning es también sencillo: direcciones multifirma (multisig)(o generalmente, direcciones P2SH)

Las direcciones Multisig son direcciones Bitcoin que como su nombre lo indica, requieren múltiples claves privadas para “desbloquearse” y gastar bitcoins. Las direcciones Multisig se pueden configurar en todo tipo de condiciones, por ejemplo, para requerir 2 de 3 posibles claves, o 15 de 15, o casi cualquier otra combinación.

La Red Lightning normalmente usa 2 de 2 configuraciones multisig. Desbloquear bitcoins de 2 de 2 direcciones multisig, requiere dos firmas de dos claves dedicadas.

Red Lightning-multisig

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 diferentes 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. CSV en cambio, 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.

Red Lightning-bloqueo de tiempo

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, pero en la Red Lightning 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 (o secreto) puede ser “hasheado” en una cadena diferente de números, un “hash”; y aquí está el truco: cualquier persona que conoce el valor puede reproducir fácilmente el hash, pero esto no funciona al revés, es una calle con sentido único.

Este truco puede ser utilizado con Bitcoin a sí mismo, nuevamente 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.

Red Lightning-valores de hash y secretos

El primer desafío: canales de pago bidireccionales

Incluso antes de que se presentara la Red Lightning, el concepto de los canales de pago había existido desde hacía algún tiempo. Los canales de pago típicos son útiles para ciertos propósitos, pero también son limitados, 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 Red Lightning, Poon y Dryja 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 un Bitcoin a Bill. Dado que Ana y Bill esperan realizar transacciones más frecuentes, deciden abrir un canal de pago bidireccional y utilizarlo para enviar el Bitcoin. (Enviar un bitcoin entero es probablemente mucho para un canal de pago, ya que podría ser más útil para micropagos, pero es totalmente posible).

Para abrir el canal, Ana y Bill envían cinco 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 cuatro bitcoins a sí misma y ​​seis bitcoins a una segunda dirección multisig. Esta segunda dirección multisig es un poco bizarra. Puede ser desbloqueada por Bill por su cuenta, pero solo después de 1000 bloques extra que se hayan extraído luego de que se incluya en la blockchain; eso incluye un bloqueo CSV.

También puede ser abierto por Ana por su cuenta, pero 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 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, pero se refleja. También crea una transacción de compromiso, de la que se envía seis bitcoins a sí mismo, y cuatro 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 seis bitcoins inmediatamente. Si Bill lo hace, Ana obtiene cuatro bitcoins inmediatamente. Pero quienquiera que firme y transmita la transacción, tendrá que esperar 1000 bloques para desbloquear la dirección multisig posterior y reclamar los bitcoins restantes.

Red Lightning-apertura del canal

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 un bitcoin de vuelta, quieren actualizar el estado del canal para volver a hacer el balance de 55 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 cinco bitcoins, y ambos atribuyen cinco bitcoins a la dirección multifirma bizarra que se comentó. Las condiciones para estas direcciones multisig 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 utiliza 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 cinco 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ó seis bitcoins, en lugar de cinco.

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 fuera a firmar y difundir esa transacción de compromiso, inmediatamente enviaría cuatro bitcoins a Ana y él tendría que esperar 1000 bloques para reclamar sus seis bitcoins. ¡Esto es un problema, porque ahora que Ana sabe su secreto, podría usarlo esta vez a su favor para vencer a Bill y reclamar los otros seis bitcoins también!

Como Bill también tiene el secreto de Ana, esto es igualmente cierto por el contrario. Si Ana intenta firmar y emitir una transacción de compromiso antigua, Bill puede robar todos los bitcoins del canal, esto por supuesto, significa 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.

Red Lightning-actualización 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 un Bitcoin a una tercera persona, Chris.

Para esto, Ana y Chris podrían abrir un canal de pago entre ellos, pero 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 un Bitcoin, y Bill puede pagar a Chris un Bitcoin.

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 un Bitcoin, si también paga a Chris un Bitcoin. 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 Bitcoin. Así que Ana puede darle confianza a Bill por 1 BTC.

¡Finalmente, todos están contentos!

Red Lightning-la red

Bien… casi todo el mundo está feliz.

En este escenario “ingenuo”, el intermediario Bill todavía tiene que confiar en Ana y en Chris. Bill tiene que confiar en Chris para realmente darle el valor después de que le haya enviado 1 BTC, y Bill tiene que confiar en Ana para realmente darle 1 BTC una vez que se le presenta 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 un Bitcoin a Chris, él debe estar garantizado de recuperar el 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 Bitcoin por el valor a través de un HTLC. (Bill y Chris también quieren intercambiar 1 Bitcoin por ese mismo valor, pero no importa eso por ahora)

Para hacerlo, en lugar de enviar a Bill 1 Bitcoin directamente, Ana envía 1 Bitcoin a una nueva dirección multisig. Los bitcoins bloqueados en esta dirección se pueden desbloquear de dos maneras diferentes.

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 el Bitcoin desde la dirección multisig a sí mismo. Como tal, este comercio está garantizado. Bill solo puede reclamar el Bitcoin de Ana si proporciona el valor: transmitirlo a través de la red 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 Bitcoin. Así de sencillo.

Red Lightning-contrato de bloqueo de tiempo del hash

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 su Bitcoin 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 de obtener un Bitcoin 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 un Bitcoin 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 su Bitcoin de Bill. Si Bill obtiene el valor de Chris solo después de que Ana haya recuperado la suya, Bill estará atrapado en el medio después de todo.

El tiempo de espera en el HTLC de Bill y Chris debe por lo tanto 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 HTLCs necesitan CheckLockTimeVerify (CLTV) y no CheckSequenceVerify (CSV).

Red Lightning-contrato de tiempo de bloqueo del hash de la red

Para concluir, hay un problema más que resolver: para que la Red Lightning sea útil, todo esto debe llevarse a cabo fuera de la cadena.

La Red Lightning

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 un Bitcoin de Bill a cambio de su valor, Bill se garantiza un Bitcoin de Ana a cambio.

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 multisig 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 un Bitcoin. (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 el 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 transmitan 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 este 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 este 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 de Bill (el más reciente)

Dos pueden jugar este juego: Si Ana trata de engañar y difundir este canal cuando ya está obsoleto, Bill puede reclamar este 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 Bitcoin de vuelta. Una vez más, si Ana o Bill dejan el canal, no importa en 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 el Bitcoin en la salida HTLC. (Si no proporciona el valor en 2 semanas, Ana puede reclamar este 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.

Red Lightning-canal de pago bidireccional con HTLC

Solución del estado

En este punto, Bill se garantiza de recibir un Bitcoin 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 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: es menos complicado que tener que dejar el canal en la cadena de bloques.

Red Lightning-canal de pago bidireccional

Cierre del canal

Y finalmente, aquí está el verdadero poder de la Red Lightning: 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 simplemente crear una transacción 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, en este momento simplemente puede crear una transacción pagándose a sí misma 4 bitcoins y 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 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.

Red Lightning-cerrar transacción

Si te ha interesado la tecnología de la red Lightning, comenta, comparte, vota para mejorar la experiencia de usuario de este artículo. ¡Muchas Gracias!

¿TE HA RESULTADO INTERESANTE ESTE ARTÍCULO? ¡VOTA PARA MEJORARLO!
[Votos: 0 Promedio: 0]
loading...

¡Dale comenta, tu opinión es importante!