La visión futura de la blockchain es la descentralización, la seguridad y la escalabilidad, pero a menudo solo se pueden lograr dos de ellas, lo que se conoce como el problema del triángulo imposible de la blockchain. Durante años, las personas han estado explorando cómo resolver este dilema, cómo aumentar el rendimiento y la velocidad de las transacciones de la blockchain garantizando la descentralización y la seguridad, es decir, resolver el problema de la escalabilidad, que es uno de los temas candentes en el proceso de desarrollo actual de la blockchain.
La descentralización, seguridad y escalabilidad de la blockchain se definen de la siguiente manera:
Descentralización: cualquier persona puede convertirse en un nodo y participar en la producción y verificación del sistema de blockchain. Cuantos más nodos haya, mayor será el grado de descentralización, lo que garantiza que la red no esté controlada por un pequeño grupo de grandes participantes centralizados.
Seguridad: Cuanto mayor sea el costo para obtener el control del sistema de blockchain, mayor será la seguridad, por lo que la cadena puede resistir ataques de una proporción mayor de participantes.
Escalabilidad: la capacidad de la blockchain para procesar grandes volúmenes de transacciones.
La primera bifurcación dura significativa de la red Bitcoin surgió del problema de escalabilidad. A medida que aumentaba el número de usuarios y el volumen de transacciones de Bitcoin, la red de Bitcoin, con un límite de 1MB por bloque, comenzó a enfrentar problemas de congestión; desde 2015, la comunidad de Bitcoin ha tenido desacuerdos sobre la escalabilidad. Por un lado, está el grupo de expansión representado por Bitcoin ABC, que apoya la ampliación del tamaño de los bloques; por otro lado, está el grupo de bloques pequeños representado por Bitcoin Core, que cree que se debe utilizar la solución de testigos segregados (Segwit) para optimizar la estructura de la cadena principal. El 1 de agosto de 2017, Bitcoin ABC lanzó su sistema de cliente desarrollado hasta 8MB, lo que llevó a la primera bifurcación dura significativa en la historia de Bitcoin y dio lugar al nuevo tipo de moneda BCH.
De manera similar, la red de Ethereum también ha optado por sacrificar una parte de la escalabilidad para garantizar la seguridad y la descentralización de la red; aunque la red de Ethereum no ha limitado el volumen de transacciones como lo ha hecho la red de Bitcoin al restringir el tamaño de los bloques, sino que ha transformado indirectamente esto en establecer un límite en las tarifas de combustible que puede acomodar un solo bloque, pero el objetivo sigue siendo lograr un consenso sin confianza y asegurar una amplia distribución de nodos (. Ya sea eliminando o aumentando el límite, se eliminarán muchos nodos más pequeños que no tienen suficiente ancho de banda, almacenamiento y capacidad de cálculo ).
Desde CryptoKitties en 2017, el verano de DeFi, hasta el posterior auge de aplicaciones en cadena como GameFi y NFT, la demanda del mercado por capacidad de procesamiento ha aumentado constantemente. Sin embargo, incluso Ethereum, que es Turing completo, solo puede procesar entre 15 y 45 transacciones por segundo ( TPS ), lo que ha llevado a un aumento continuo en los costos de transacción, tiempos de liquidación más largos, y la mayoría de los Dapps encuentran difícil soportar los costos operativos. Todo el red se ha vuelto lenta y costosa para los usuarios, y el problema de escalabilidad de la blockchain necesita ser resuelto urgentemente. La solución de escalabilidad en un estado ideal es: sin sacrificar la descentralización y la seguridad, aumentar tanto como sea posible la velocidad de transacción de la red blockchain ( un tiempo de finalización más corto ) y un rendimiento de transacción ( TPS más alto ).
2. Tipos de soluciones de escalado
Nosotros clasificamos los planes de expansión en dos grandes categorías: escalado en cadena y escalado off-chain, basándonos en el estándar de "si se cambia una capa de la red principal".
2.1 escalabilidad en cadena
Concepto clave: solución para lograr el efecto de escalabilidad mediante el cambio de una capa del protocolo de la cadena principal, la principal solución actual es el sharding.
La escalabilidad en cadena tiene varias soluciones, este artículo no se desarrollará, a continuación se enumeran brevemente dos soluciones:
La opción uno es expandir el espacio del bloque, es decir, aumentar la cantidad de transacciones empaquetadas en cada bloque, pero esto aumentará los requisitos para dispositivos de nodos de alto rendimiento, elevará la barrera de entrada para los nodos y reducirá el grado de "descentralización".
La opción dos es la fragmentación, que divide el libro mayor de la blockchain en varias partes, ya no participando cada nodo en todos los registros, sino que diferentes fragmentos, es decir, diferentes nodos son responsables de diferentes registros, y el cálculo en paralelo puede manejar múltiples transacciones al mismo tiempo; esto puede reducir la presión computacional en los nodos y el umbral de entrada, mejorar la velocidad de procesamiento de transacciones y el grado de descentralización; pero esto significa que la potencia de cálculo de toda la red se dispersa, lo que puede reducir la "seguridad" de toda la red.
Cambiar el código de un protocolo principal de la red podría tener consecuencias negativas impredecibles, ya que cualquier pequeño fallo de seguridad en la base podría amenazar seriamente la seguridad de toda la red, lo que podría llevar a que la red se vea obligada a bifurcarse o interrumpir la actualización de reparación. Por ejemplo, el incidente de vulnerabilidad de inflación de Zcash en 2018: el código de Zcash se basa en una modificación del código de la versión 0.11.2 de Bitcoin, y en 2018 un ingeniero descubrió que su código subyacente tenía una vulnerabilidad crítica, lo que permitía la emisión ilimitada de tokens. El equipo pasó 8 meses arreglando esto en secreto, y solo después de corregir la vulnerabilidad se hizo pública esta situación.
2.2 off-chain expansión
Concepto central: solución de escalado que no altera el protocolo de la mainnet de capa uno existente.
Las soluciones de escalabilidad off-chain se pueden dividir en Layer2 y otras soluciones:
Layer2: Canales de estado, cadenas laterales, Plasma, Rollups
Otros: Validium, Volition
3. Soluciones de escalabilidad off-chain
3.1 Canales de Estado (
)# 3.1.1 Resumen
Los canales de estado establecen que los usuarios solo necesitan interactuar con la cadena principal cuando el canal está abierto, cerrado o se resuelve una disputa, y que las interacciones entre usuarios se realicen off-chain, con el fin de reducir el tiempo y el costo monetario de las transacciones de los usuarios, y permitir que el número de transacciones no tenga restricciones.
Los canales de estado son protocolos P2P simples, adecuados para "aplicaciones basadas en turnos", como un juego de ajedrez entre dos personas. Cada canal es gestionado por un contrato inteligente de múltiples firmas que se ejecuta en la cadena principal, que controla los activos depositados en el canal, verifica las actualizaciones de estado y arbitra disputas entre los participantes ### según pruebas de fraude con firma y marca de tiempo (. Después de que los participantes desplieguen el contrato en la red de blockchain, depositan una cantidad de fondos y los bloquean; una vez que ambas partes firman y confirman, el canal se abre oficialmente. El canal permite transacciones gratuitas off-chain ilimitadas entre los participantes ) siempre que el valor neto de sus transferencias no exceda el total de tokens depositados (. Los participantes se turnan para enviar actualizaciones de estado al otro, esperando la confirmación de la firma de la otra parte. Una vez que la otra parte firma y confirma, esta actualización de estado se considera completada. Normalmente, las actualizaciones de estado acordadas por ambas partes no se suben a la cadena principal, solo en caso de disputas o cuando se cierra el canal, se dependerá de la confirmación de la cadena principal. Cuando se necesita cerrar el canal, cualquier participante puede presentar una solicitud de transacción en la cadena principal; si la solicitud de salida recibe la aprobación de firma unánime, se ejecutará de inmediato en la cadena, es decir, el contrato inteligente distribuirá los fondos bloqueados restantes según el saldo de cada participante en el estado final del canal; si otros participantes no aprueban la firma, todos deberán esperar el final del "período de desafío" para recibir los fondos restantes.
En resumen, el esquema de canales de estado puede reducir significativamente la carga computacional de la cadena principal, aumentar la velocidad de las transacciones y disminuir los costos de transacción.
![Informe de investigación a fondo: Análisis completo de la Profundidad off-chain])https://img-cdn.gateio.im/webp-social/moments-ead28de03be9fc22dcfe3f679ee36bc5.webp(
)# 3.1.2 Línea de tiempo
En febrero de 2015, Joseph Poon y Thaddeus Dryja publicaron un borrador del libro blanco de la red Lightning.
En noviembre de 2015, Jeff Coleman resumió sistemáticamente el concepto de State Channel por primera vez, proponiendo que el Payment Channel de Bitcoin es un subcaso del concepto de State Channel.
En enero de 2016, Joseph Poon y Thaddeus Dryja publicaron oficialmente el libro blanco "The Bitcoin Lightning Network: Scalable Off-Chain Instant Payments" que propone el esquema de escalabilidad de la red Lightning de Bitcoin Payment Channel###, el cual se utiliza únicamente para procesar pagos de transferencias en la red de Bitcoin.
En noviembre de 2017, se propuso la primera especificación de diseño de State Channel bajo el marco de Payment Channel, llamada Sprites.
En junio de 2018, Counterfactual propuso un diseño de Canales de Estado Generalizados muy detallado, que es el primer diseño completamente relacionado con canales de estado.
En octubre de 2018, el artículo Generalised State Channel Networks presentó los conceptos de State Channel Networks y Virtual Channels.
En febrero de 2019, el concepto de canales de estado se expandió a los Canales N-Partidos, Nitro es el primer protocolo construido sobre esta idea.
En octubre de 2019, Pisa amplió el concepto de Watchtowers para resolver el problema de que todos los participantes necesitan estar en línea de manera continua.
En marzo de 2020, Hydra propuso Canales Isomórficos Rápidos.
(# 3.1.3 Principios técnicos
El flujo de trabajo de los canales de estado es el siguiente:
Alice y Bob depositan fondos desde su EOA personal a la dirección del contrato en cadena, estos fondos se bloquean en el contrato hasta que se cierra el canal y el saldo se devuelve al usuario; después de que ambos firman y confirman, el canal de estado entre ellos se abre oficialmente.
Alice y Bob pueden llevar a cabo transacciones ilimitadas teóricamente a través de este canal off-chain, los participantes se comunican entre sí mediante mensajes firmados criptográficamente ) en lugar de comunicarse con la red de blockchain ###. Ambos usuarios deben firmar cada transacción para prevenir el doble gasto malicioso. A través de estos mensajes, proponen actualizaciones del estado de sus cuentas y aceptan las actualizaciones de estado propuestas por la otra parte.
Si Alice quiere cerrar el canal y finalizar la transacción con Bob, Alice necesita enviar el estado final de su cuenta al contrato. Si Bob firma y aprueba, el contrato liberará los fondos bloqueados de acuerdo con el estado final y los devolverá al usuario correspondiente. Si Bob no responde con la firma, el contrato liberará los fondos bloqueados y los devolverá al usuario correspondiente al finalizar el período de desafío.
Si en algún momento, Bob no responde a la firma de actualización de estado enviada por Alice en su turno, Alice puede iniciar un desafío presentando el último estado válido ante el contrato, que también incluye la firma anterior de Bob, demostrando así que la última transacción ya ha recibido la aprobación de Bob y que el estado final ha sido confirmado por Bob. Luego, el contrato permite a Bob responder durante un período de tiempo presentando el siguiente estado al contrato; si Bob responde, ambos pueden continuar realizando transacciones dentro del canal de estado; si Bob no responde durante ese período, el contrato cierra automáticamente el canal de estado y devuelve los fondos a Alice.
(# 3.1.4 Ventajas y desventajas
Ventajas:
Inmediatez: las actualizaciones de estado son casi instantáneas, sin necesidad de esperar la confirmación del bloque.
Privacidad: solo el estado final se registrará en la cadena, los estados intermedios son privados.
Escalabilidad: teóricamente puede expandirse infinitamente, siempre que los fondos de los participantes sean suficientes
Bajo costo: las transacciones off-chain no requieren el pago de tarifas de gas
Desventajas:
Eficiencia de capital baja: se necesita bloquear capital
Requisitos en línea: los participantes deben monitorear en línea de manera continua.
Tiempo de salida largo: se debe esperar el período de desafío al cerrar el canal
Dependencia de nodos centralizados: necesita servicios de monitoreo de terceros ) como Watchtowers ###
Explosión de estado: N usuarios necesitan N(N-1)/2 canales
Liquidez limitada: los fondos están bloqueados en un canal específico
(# 3.1.5 Aplicación
Red Lightning de Bitcoin
Resumen: La Red Lightning es un canal de pagos de bajo valor en la red Bitcoin, cuya evolución técnica general ha pasado por: la construcción de un canal de pago unidireccional mediante 2/2 firmas múltiples, la adición de RSMC) Revocable Sequence Maturity Contract### que permite la construcción de un canal de pago bidireccional, y luego la adición de HTLC( Hash Time Lock Contract) que expande los canales de pago para permitir pagos entre múltiples partes, construyendo finalmente la red de pagos que es la Red Lightning. A través de canales de pago de bajo valor off-chain, y luego utilizando intermediarios para formar una red de transacciones, se puede resolver el problema de escalabilidad de la red Bitcoin. El uso general de la Red Lightning sigue el proceso de "depósito( establecer canal) → transacciones de la Red Lightning( actualizar estado del canal) → reembolso/ajuste( cerrar canal)"; teóricamente, la Red Lightning puede manejar un millón de transacciones por segundo.
Línea de tiempo:
En febrero de 2015, Joseph Poon y Thaddeus Dryja publicaron el borrador del libro blanco de la red Lightning;
Se lanzó la versión oficial del libro blanco en enero de 2016 y se fundó Lightning Labs;
El 15 de marzo de 2018, Lightning Labs lanzó la primera versión de la red principal de Lightning Network Daemon (LND) versión 0.4.
A principios de 2021, la capacidad pública de la red Lightning (TVL) era de aproximadamente 40 millones de dólares, con alrededor de 100,000 usuarios utilizando la red Lightning.
Esta página puede contener contenido de terceros, que se proporciona únicamente con fines informativos (sin garantías ni declaraciones) y no debe considerarse como un respaldo por parte de Gate a las opiniones expresadas ni como asesoramiento financiero o profesional. Consulte el Descargo de responsabilidad para obtener más detalles.
15 me gusta
Recompensa
15
4
Compartir
Comentar
0/400
ImpermanentPhilosopher
· 07-20 20:36
No puedo entender el problema triangular.
Ver originalesResponder0
MevHunter
· 07-20 20:20
¿Quién no ha entendido alguna vez el dilema del triángulo?
Análisis profundo de las soluciones de escalado off-chain: de estado del canal a Layer2
Profundidad de análisis de la expansión off-chain
1. La necesidad de la expansión
La visión futura de la blockchain es la descentralización, la seguridad y la escalabilidad, pero a menudo solo se pueden lograr dos de ellas, lo que se conoce como el problema del triángulo imposible de la blockchain. Durante años, las personas han estado explorando cómo resolver este dilema, cómo aumentar el rendimiento y la velocidad de las transacciones de la blockchain garantizando la descentralización y la seguridad, es decir, resolver el problema de la escalabilidad, que es uno de los temas candentes en el proceso de desarrollo actual de la blockchain.
La descentralización, seguridad y escalabilidad de la blockchain se definen de la siguiente manera:
Descentralización: cualquier persona puede convertirse en un nodo y participar en la producción y verificación del sistema de blockchain. Cuantos más nodos haya, mayor será el grado de descentralización, lo que garantiza que la red no esté controlada por un pequeño grupo de grandes participantes centralizados.
Seguridad: Cuanto mayor sea el costo para obtener el control del sistema de blockchain, mayor será la seguridad, por lo que la cadena puede resistir ataques de una proporción mayor de participantes.
Escalabilidad: la capacidad de la blockchain para procesar grandes volúmenes de transacciones.
La primera bifurcación dura significativa de la red Bitcoin surgió del problema de escalabilidad. A medida que aumentaba el número de usuarios y el volumen de transacciones de Bitcoin, la red de Bitcoin, con un límite de 1MB por bloque, comenzó a enfrentar problemas de congestión; desde 2015, la comunidad de Bitcoin ha tenido desacuerdos sobre la escalabilidad. Por un lado, está el grupo de expansión representado por Bitcoin ABC, que apoya la ampliación del tamaño de los bloques; por otro lado, está el grupo de bloques pequeños representado por Bitcoin Core, que cree que se debe utilizar la solución de testigos segregados (Segwit) para optimizar la estructura de la cadena principal. El 1 de agosto de 2017, Bitcoin ABC lanzó su sistema de cliente desarrollado hasta 8MB, lo que llevó a la primera bifurcación dura significativa en la historia de Bitcoin y dio lugar al nuevo tipo de moneda BCH.
De manera similar, la red de Ethereum también ha optado por sacrificar una parte de la escalabilidad para garantizar la seguridad y la descentralización de la red; aunque la red de Ethereum no ha limitado el volumen de transacciones como lo ha hecho la red de Bitcoin al restringir el tamaño de los bloques, sino que ha transformado indirectamente esto en establecer un límite en las tarifas de combustible que puede acomodar un solo bloque, pero el objetivo sigue siendo lograr un consenso sin confianza y asegurar una amplia distribución de nodos (. Ya sea eliminando o aumentando el límite, se eliminarán muchos nodos más pequeños que no tienen suficiente ancho de banda, almacenamiento y capacidad de cálculo ).
Desde CryptoKitties en 2017, el verano de DeFi, hasta el posterior auge de aplicaciones en cadena como GameFi y NFT, la demanda del mercado por capacidad de procesamiento ha aumentado constantemente. Sin embargo, incluso Ethereum, que es Turing completo, solo puede procesar entre 15 y 45 transacciones por segundo ( TPS ), lo que ha llevado a un aumento continuo en los costos de transacción, tiempos de liquidación más largos, y la mayoría de los Dapps encuentran difícil soportar los costos operativos. Todo el red se ha vuelto lenta y costosa para los usuarios, y el problema de escalabilidad de la blockchain necesita ser resuelto urgentemente. La solución de escalabilidad en un estado ideal es: sin sacrificar la descentralización y la seguridad, aumentar tanto como sea posible la velocidad de transacción de la red blockchain ( un tiempo de finalización más corto ) y un rendimiento de transacción ( TPS más alto ).
2. Tipos de soluciones de escalado
Nosotros clasificamos los planes de expansión en dos grandes categorías: escalado en cadena y escalado off-chain, basándonos en el estándar de "si se cambia una capa de la red principal".
2.1 escalabilidad en cadena
Concepto clave: solución para lograr el efecto de escalabilidad mediante el cambio de una capa del protocolo de la cadena principal, la principal solución actual es el sharding.
La escalabilidad en cadena tiene varias soluciones, este artículo no se desarrollará, a continuación se enumeran brevemente dos soluciones:
La opción uno es expandir el espacio del bloque, es decir, aumentar la cantidad de transacciones empaquetadas en cada bloque, pero esto aumentará los requisitos para dispositivos de nodos de alto rendimiento, elevará la barrera de entrada para los nodos y reducirá el grado de "descentralización".
La opción dos es la fragmentación, que divide el libro mayor de la blockchain en varias partes, ya no participando cada nodo en todos los registros, sino que diferentes fragmentos, es decir, diferentes nodos son responsables de diferentes registros, y el cálculo en paralelo puede manejar múltiples transacciones al mismo tiempo; esto puede reducir la presión computacional en los nodos y el umbral de entrada, mejorar la velocidad de procesamiento de transacciones y el grado de descentralización; pero esto significa que la potencia de cálculo de toda la red se dispersa, lo que puede reducir la "seguridad" de toda la red.
Cambiar el código de un protocolo principal de la red podría tener consecuencias negativas impredecibles, ya que cualquier pequeño fallo de seguridad en la base podría amenazar seriamente la seguridad de toda la red, lo que podría llevar a que la red se vea obligada a bifurcarse o interrumpir la actualización de reparación. Por ejemplo, el incidente de vulnerabilidad de inflación de Zcash en 2018: el código de Zcash se basa en una modificación del código de la versión 0.11.2 de Bitcoin, y en 2018 un ingeniero descubrió que su código subyacente tenía una vulnerabilidad crítica, lo que permitía la emisión ilimitada de tokens. El equipo pasó 8 meses arreglando esto en secreto, y solo después de corregir la vulnerabilidad se hizo pública esta situación.
2.2 off-chain expansión
Concepto central: solución de escalado que no altera el protocolo de la mainnet de capa uno existente.
Las soluciones de escalabilidad off-chain se pueden dividir en Layer2 y otras soluciones:
Layer2: Canales de estado, cadenas laterales, Plasma, Rollups
Otros: Validium, Volition
3. Soluciones de escalabilidad off-chain
3.1 Canales de Estado (
)# 3.1.1 Resumen
Los canales de estado establecen que los usuarios solo necesitan interactuar con la cadena principal cuando el canal está abierto, cerrado o se resuelve una disputa, y que las interacciones entre usuarios se realicen off-chain, con el fin de reducir el tiempo y el costo monetario de las transacciones de los usuarios, y permitir que el número de transacciones no tenga restricciones.
Los canales de estado son protocolos P2P simples, adecuados para "aplicaciones basadas en turnos", como un juego de ajedrez entre dos personas. Cada canal es gestionado por un contrato inteligente de múltiples firmas que se ejecuta en la cadena principal, que controla los activos depositados en el canal, verifica las actualizaciones de estado y arbitra disputas entre los participantes ### según pruebas de fraude con firma y marca de tiempo (. Después de que los participantes desplieguen el contrato en la red de blockchain, depositan una cantidad de fondos y los bloquean; una vez que ambas partes firman y confirman, el canal se abre oficialmente. El canal permite transacciones gratuitas off-chain ilimitadas entre los participantes ) siempre que el valor neto de sus transferencias no exceda el total de tokens depositados (. Los participantes se turnan para enviar actualizaciones de estado al otro, esperando la confirmación de la firma de la otra parte. Una vez que la otra parte firma y confirma, esta actualización de estado se considera completada. Normalmente, las actualizaciones de estado acordadas por ambas partes no se suben a la cadena principal, solo en caso de disputas o cuando se cierra el canal, se dependerá de la confirmación de la cadena principal. Cuando se necesita cerrar el canal, cualquier participante puede presentar una solicitud de transacción en la cadena principal; si la solicitud de salida recibe la aprobación de firma unánime, se ejecutará de inmediato en la cadena, es decir, el contrato inteligente distribuirá los fondos bloqueados restantes según el saldo de cada participante en el estado final del canal; si otros participantes no aprueban la firma, todos deberán esperar el final del "período de desafío" para recibir los fondos restantes.
En resumen, el esquema de canales de estado puede reducir significativamente la carga computacional de la cadena principal, aumentar la velocidad de las transacciones y disminuir los costos de transacción.
![Informe de investigación a fondo: Análisis completo de la Profundidad off-chain])https://img-cdn.gateio.im/webp-social/moments-ead28de03be9fc22dcfe3f679ee36bc5.webp(
)# 3.1.2 Línea de tiempo
En febrero de 2015, Joseph Poon y Thaddeus Dryja publicaron un borrador del libro blanco de la red Lightning.
En noviembre de 2015, Jeff Coleman resumió sistemáticamente el concepto de State Channel por primera vez, proponiendo que el Payment Channel de Bitcoin es un subcaso del concepto de State Channel.
En enero de 2016, Joseph Poon y Thaddeus Dryja publicaron oficialmente el libro blanco "The Bitcoin Lightning Network: Scalable Off-Chain Instant Payments" que propone el esquema de escalabilidad de la red Lightning de Bitcoin Payment Channel###, el cual se utiliza únicamente para procesar pagos de transferencias en la red de Bitcoin.
En noviembre de 2017, se propuso la primera especificación de diseño de State Channel bajo el marco de Payment Channel, llamada Sprites.
En junio de 2018, Counterfactual propuso un diseño de Canales de Estado Generalizados muy detallado, que es el primer diseño completamente relacionado con canales de estado.
En octubre de 2018, el artículo Generalised State Channel Networks presentó los conceptos de State Channel Networks y Virtual Channels.
En febrero de 2019, el concepto de canales de estado se expandió a los Canales N-Partidos, Nitro es el primer protocolo construido sobre esta idea.
En octubre de 2019, Pisa amplió el concepto de Watchtowers para resolver el problema de que todos los participantes necesitan estar en línea de manera continua.
En marzo de 2020, Hydra propuso Canales Isomórficos Rápidos.
(# 3.1.3 Principios técnicos
El flujo de trabajo de los canales de estado es el siguiente:
Alice y Bob depositan fondos desde su EOA personal a la dirección del contrato en cadena, estos fondos se bloquean en el contrato hasta que se cierra el canal y el saldo se devuelve al usuario; después de que ambos firman y confirman, el canal de estado entre ellos se abre oficialmente.
Alice y Bob pueden llevar a cabo transacciones ilimitadas teóricamente a través de este canal off-chain, los participantes se comunican entre sí mediante mensajes firmados criptográficamente ) en lugar de comunicarse con la red de blockchain ###. Ambos usuarios deben firmar cada transacción para prevenir el doble gasto malicioso. A través de estos mensajes, proponen actualizaciones del estado de sus cuentas y aceptan las actualizaciones de estado propuestas por la otra parte.
Si Alice quiere cerrar el canal y finalizar la transacción con Bob, Alice necesita enviar el estado final de su cuenta al contrato. Si Bob firma y aprueba, el contrato liberará los fondos bloqueados de acuerdo con el estado final y los devolverá al usuario correspondiente. Si Bob no responde con la firma, el contrato liberará los fondos bloqueados y los devolverá al usuario correspondiente al finalizar el período de desafío.
Si en algún momento, Bob no responde a la firma de actualización de estado enviada por Alice en su turno, Alice puede iniciar un desafío presentando el último estado válido ante el contrato, que también incluye la firma anterior de Bob, demostrando así que la última transacción ya ha recibido la aprobación de Bob y que el estado final ha sido confirmado por Bob. Luego, el contrato permite a Bob responder durante un período de tiempo presentando el siguiente estado al contrato; si Bob responde, ambos pueden continuar realizando transacciones dentro del canal de estado; si Bob no responde durante ese período, el contrato cierra automáticamente el canal de estado y devuelve los fondos a Alice.
(# 3.1.4 Ventajas y desventajas
Ventajas:
Desventajas:
(# 3.1.5 Aplicación
Red Lightning de Bitcoin
Resumen: La Red Lightning es un canal de pagos de bajo valor en la red Bitcoin, cuya evolución técnica general ha pasado por: la construcción de un canal de pago unidireccional mediante 2/2 firmas múltiples, la adición de RSMC) Revocable Sequence Maturity Contract### que permite la construcción de un canal de pago bidireccional, y luego la adición de HTLC( Hash Time Lock Contract) que expande los canales de pago para permitir pagos entre múltiples partes, construyendo finalmente la red de pagos que es la Red Lightning. A través de canales de pago de bajo valor off-chain, y luego utilizando intermediarios para formar una red de transacciones, se puede resolver el problema de escalabilidad de la red Bitcoin. El uso general de la Red Lightning sigue el proceso de "depósito( establecer canal) → transacciones de la Red Lightning( actualizar estado del canal) → reembolso/ajuste( cerrar canal)"; teóricamente, la Red Lightning puede manejar un millón de transacciones por segundo.
Línea de tiempo: