Análisis profundo de la profundidad de expansión off-chain
1. La necesidad de la expansión
La visión futura de la blockchain es lograr descentralización, seguridad y escalabilidad. Pero generalmente solo se pueden lograr dos de estos, lo que se conoce como el problema del triángulo imposible de la blockchain. Durante años, las personas han estado explorando cómo aumentar el rendimiento y la velocidad de las transacciones de la blockchain, asegurando la descentralización y la seguridad, es decir, resolver el problema de la escalabilidad.
La descentralización, la seguridad y la escalabilidad de la blockchain se definen de la siguiente manera:
Descentralización: cualquier persona puede convertirse en un nodo para participar en la producción y verificación del sistema de blockchain; cuántos más nodos haya, mayor será el grado de descentralización.
Seguridad: Cuanto mayor sea el costo para obtener el control del sistema de blockchain, mayor será la seguridad, y la cadena podrá resistir ataques de una mayor proporción de participantes.
Escalabilidad: la capacidad de la blockchain para procesar un gran volumen 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, la red Bitcoin, con un límite de 1 MB por bloque, comenzó a enfrentar congestión. Desde 2015, la comunidad de Bitcoin ha tenido desacuerdos sobre el problema de escalabilidad; una parte apoya la ampliación del bloque, mientras que la otra cree que se debe utilizar la solución de Segregated Witness (Segwit) para optimizar la estructura de la cadena principal. El 1 de agosto de 2017, la parte que apoyaba la ampliación del bloque desarrolló de forma independiente un sistema de cliente de 8 MB que comenzó a funcionar, lo que llevó a la primera bifurcación dura significativa en la historia de Bitcoin y al nacimiento de la nueva criptomoneda BCH.
La red de Ethereum también optó por sacrificar una parte de la escalabilidad para garantizar la seguridad y la descentralización de la red. Aunque Ethereum no limita la cantidad de transacciones como Bitcoin a través de un tamaño de bloque restringido, sino que establece un límite indirecto en las tarifas de gas que puede aceptar un único bloque, el objetivo es lograr un consenso sin confianza y asegurar una amplia distribución de nodos.
Desde los CryptoKitties de 2017, el verano de DeFi, hasta el surgimiento posterior de aplicaciones en cadena como GameFi y NFT, la demanda de capacidad de procesamiento en el mercado ha aumentado constantemente. Sin embargo, incluso Ethereum, que es Turing completo, solo puede manejar de 15 a 45 transacciones por segundo ( TPS ). Esto ha llevado a un aumento continuo en los costos de transacción, a tiempos de liquidación más largos y a que la mayoría de las Dapps tengan dificultades para soportar los costos de operación. La red en su conjunto se ha vuelto lenta y cara para los usuarios, y el problema de la escalabilidad de la blockchain debe resolverse urgentemente. La solución de escalabilidad ideal es: aumentar la velocidad de transacción y la capacidad de procesamiento de la red blockchain tanto como sea posible, sin sacrificar la descentralización y la seguridad.
2. Categorías de soluciones de escalabilidad
Nosotros clasificamos las soluciones de escalabilidad en dos categorías principales: escalabilidad en cadena y escalabilidad off-chain, basándonos en el criterio de "si se cambia una capa de la red principal".
2.1 Expansión en cadena
Concepto clave: solución para aumentar la capacidad mediante el cambio de una capa del protocolo de la red principal, siendo la principal solución actual el sharding.
La expansión en cadena tiene varias soluciones, este artículo no se desarrollará, solo enumeraré brevemente dos:
La opción uno es expandir el espacio del bloque, aumentando 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 unirse a los nodos y reducirá el grado de "descentralización".
La opción dos es el sharding, que divide el libro mayor de la blockchain en varias partes, donde diferentes fragmentos, es decir, diferentes nodos, son responsables de diferentes registros contables. El cálculo en paralelo puede procesar múltiples transacciones simultáneamente; esto puede reducir la presión de cálculo en los nodos y el umbral de entrada, mejorar la velocidad de procesamiento de transacciones y el grado de descentralización; pero significa que la potencia de cálculo de toda la red se dispersa, lo que reducirá la "seguridad" de toda la red.
Cambiar el código del protocolo principal de la red puede tener efectos negativos impredecibles, ya que cualquier pequeña vulnerabilidad de seguridad en la capa subyacente puede amenazar seriamente la seguridad de toda la red, lo que podría obligar a la red a bifurcarse o interrumpir la actualización de la reparación.
2.2 off-chain expansión
Concepto clave: solución de escalado que no cambia el protocolo de la red principal de capa uno existente.
Las soluciones de escalado off-chain se pueden dividir en Layer2 y otras soluciones:
Layer2: Canales de Estado, Plasma, Rollups( Rollups Optimistas y Rollups ZK)
Otros: Sidechains, Validium
3. Profundidad de la solución de escalado 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 los usuarios se realicen off-chain, con el fin de reducir el tiempo y costo de las transacciones de los usuarios, y permitir que el número de transacciones no tenga límites.
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, el cual controla los activos depositados en el canal, verifica las actualizaciones de estado y arbitra las disputas entre los participantes. Después de que los participantes despliegan el contrato en la red blockchain, depositan fondos y los bloquean; una vez que ambas partes firman y confirman, el canal se abre oficialmente. El canal permite transacciones off-chain gratuitas e ilimitadas entre los participantes siempre que el valor neto de la transferencia no exceda el total de tokens depositados. Los participantes se turnan para enviar actualizaciones de estado al otro, esperando la confirmación de firma del otro. Una vez que el otro participante confirma con su firma, la 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 disputa o cierre del canal se dependerá de la cadena principal para la confirmación. Cuando se necesita cerrar el canal, cualquiera de los participantes puede presentar una solicitud de transacción en la cadena principal; si la solicitud de salida obtiene la aprobación por firma unánime, se ejecuta inmediatamente en cadena, es decir, el contrato inteligente distribuye los fondos bloqueados restantes según el saldo de cada participante en el estado final del canal; si otros participantes no firman para aprobar, todos deben esperar a que termine el "período de desafío" para recibir los fondos restantes.
En resumen, el esquema de canales de estado puede reducir significativamente la carga de cálculo en la cadena principal, aumentar la velocidad de las transacciones y disminuir los costos de transacción.
(# 3.1.2 Línea de tiempo
2015/02, Joseph Poon y Thaddeus Dryja publican el borrador del libro blanco de la red Lightning.
2015/11, 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.
2016/01, Joseph Poon y Thaddeus Dryja publicaron oficialmente el libro blanco "The Bitcoin Lightning Network: Scalable Off-Chain Instant Payments" proponiendo un esquema de escalado para la red Lightning de Bitcoin, Payment Channel) canal de pago###, que se utiliza únicamente para procesar pagos de transferencias en la red de Bitcoin.
En noviembre de 2017, se propuso el primer marco de diseño de State Channel basado en Payment Channel, llamado Sprites.
2018/06, Counterfactual propuso un diseño detallado de Canales de Estado Generalizados, que es el primer diseño completamente relacionado con canales de estado.
2018/10, el artículo Generalised State Channel Networks introdujo los conceptos de State Channel Networks y Virtual Channels.
2019/02, el concepto de canales de estado se amplió a N-Party Channels, Nitro es el primer protocolo establecido sobre esta idea.
2019/10, Pisa para abordar el problema de que todos los participantes necesitan estar en línea de forma continua, amplió el concepto de Watchtowers.
Flujo de trabajo en la cadena tradicional: Alice y Bob interactúan con un contrato inteligente desplegado en la mainnet, los usuarios cambian el estado del contrato inteligente enviando transacciones a la cadena. La desventaja es que provoca problemas de tiempo y costo.
El flujo de trabajo general que siguen la mayoría de los protocolos de canales de estado:
Alice y Bob transfieren fondos de su EOA personal a una dirección de contrato en la cadena, estos fondos se bloquean en el contrato hasta que se cierran los canales y se devuelven al usuario; después de que ambos firman y confirman, el canal de estado entre ellos se abre oficialmente.
Alice y Bob pueden realizar teóricamente un número ilimitado de transacciones off-chain a través de este canal, y los participantes se comunican entre sí mediante mensajes firmados encriptados. Ambos usuarios deben firmar cada transacción para evitar 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 desea cerrar el canal y finalizar la transacción con Bob, Alice debe 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 a la firma, el contrato liberará los fondos bloqueados y los devolverá al usuario correspondiente al final del período de desafío.
![Informe de investigación en profundidad: Análisis completo de la expansión off-chain])https://img-cdn.gateio.im/webp-social/moments-ead28de03be9fc22dcfe3f679ee36bc5.webp###
Flujo de trabajo del canal de estado en un escenario pesimista: al principio, dos participantes depositan fondos y luego comienzan a intercambiar actualizaciones de estado. Supongamos que en un momento dado, Bob no responde a la firma de actualización de estado enviada por Alice en su turno, en este momento, Alice puede iniciar un desafío presentando su última actualización de estado válida al contrato, esta actualización válida también incluye la firma anterior de Bob, lo que demuestra que la última transacción ha sido aprobada por Bob y que el estado final ha sido confirmado por Bob. Luego, el contrato permite que Bob responda 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 dentro de 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 transacciones se completan casi instantáneamente
Alta profundidad: teóricamente puede escalarse indefinidamente
Bajo costo: las transacciones off-chain casi no tienen costo.
Privacidad: sólo es necesario interactuar en la cadena al abrir y cerrar el canal.
Desventajas:
Eficiencia de capital baja: se requiere bloquear fondos
Requisitos en línea: los participantes deben estar en línea de manera continua
Escenarios de aplicación limitados: más adecuados para interacciones frecuentes entre participantes fijos.
Complejidad del cierre de canales y resolución de disputas
Problema de liquidez de la red de canales
)# 3.1.5 Aplicación
Red de relámpago de Bitcoin:
Resumen: La red Lightning es un canal de pagos de bajo valor en la red de Bitcoin, cuya evolución técnica en general ha pasado por: construir un canal de pagos unidireccional con 2/2 firmas múltiples, luego se puede construir un canal de pagos bidireccional tras añadir RSMC, y después, al añadir HTLC, se pueden conectar los canales de pagos para extender a pagos multipersonales, finalmente construyendo una red de pagos, es decir, la red Lightning. A través de canales de pagos 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 de Bitcoin. El uso general de la red Lightning sigue el proceso de "depósito ### establecer canal ### → transacción de la red Lightning ( actualizar estado del canal ) → reembolso/liquidación ( cerrar canal )"; teóricamente, la red Lightning puede procesar un millón de transacciones por segundo.
Línea de tiempo:
En febrero de 2015, Joseph Poon y Thaddeus Dryja publicaron un borrador del libro blanco de la red Lightning.
Se publicó 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 Lightning en mainnet, versión LND 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.
En junio de 2021, El Salvador anunció la adopción de Bitcoin como moneda de curso legal, y en septiembre lanzó la billetera Chivo basada en la red Lightning.
En 2022, Cash App y 26 plataformas de intercambio de criptomonedas, incluidas OKX, Kraken y Bitfinex, anunciaron su apoyo a la red Lightning.
En octubre de 2022, Lightning Labs lanzó la nueva versión del protocolo Taro basado en Taproot, versión alpha (, que actualmente se está probando en la red de pruebas.
El 23 de noviembre de 2022, la red Lightning tenía 76,236 canales de pago, con un capital de 5049 $BTC)$81.8M(
Desarrollo ecológico:
El ecosistema de la red Lightning de BTC de abajo hacia arriba es: la red BTC de base---infraestructura básica clave---varias Dapps.
La infraestructura básica central incluye:
Solución de red relámpago: tanto particulares como empresas pueden ejecutar programas de software conectados a la red relámpago, siendo el que mayor cuota de mercado tiene Lightning Labs.
Nodos y servicios de liquidez: dado que operar un nodo de forma independiente es bastante complejo para los usuarios, es necesario proporcionar una interfaz más amigable para ayudar a gestionar los canales de pago instantáneo.
Sobre la infraestructura básica se encuentran diversos servicios financieros y de pago, así como aplicaciones, por ejemplo, Strike se basa en soluciones LND que permiten a los usuarios comprar y vender BTC, utilizar BTC para recompensar a los creadores en Twitter y permitir a los comerciantes de Shopify aceptar BTC, entre otros.
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.
Explicación detallada de las soluciones de escalado off-chain: desde State Channels hasta soluciones Layer2
Análisis profundo de la profundidad de expansión off-chain
1. La necesidad de la expansión
La visión futura de la blockchain es lograr descentralización, seguridad y escalabilidad. Pero generalmente solo se pueden lograr dos de estos, lo que se conoce como el problema del triángulo imposible de la blockchain. Durante años, las personas han estado explorando cómo aumentar el rendimiento y la velocidad de las transacciones de la blockchain, asegurando la descentralización y la seguridad, es decir, resolver el problema de la escalabilidad.
La descentralización, la seguridad y la escalabilidad de la blockchain se definen de la siguiente manera:
Descentralización: cualquier persona puede convertirse en un nodo para participar en la producción y verificación del sistema de blockchain; cuántos más nodos haya, mayor será el grado de descentralización.
Seguridad: Cuanto mayor sea el costo para obtener el control del sistema de blockchain, mayor será la seguridad, y la cadena podrá resistir ataques de una mayor proporción de participantes.
Escalabilidad: la capacidad de la blockchain para procesar un gran volumen 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, la red Bitcoin, con un límite de 1 MB por bloque, comenzó a enfrentar congestión. Desde 2015, la comunidad de Bitcoin ha tenido desacuerdos sobre el problema de escalabilidad; una parte apoya la ampliación del bloque, mientras que la otra cree que se debe utilizar la solución de Segregated Witness (Segwit) para optimizar la estructura de la cadena principal. El 1 de agosto de 2017, la parte que apoyaba la ampliación del bloque desarrolló de forma independiente un sistema de cliente de 8 MB que comenzó a funcionar, lo que llevó a la primera bifurcación dura significativa en la historia de Bitcoin y al nacimiento de la nueva criptomoneda BCH.
La red de Ethereum también optó por sacrificar una parte de la escalabilidad para garantizar la seguridad y la descentralización de la red. Aunque Ethereum no limita la cantidad de transacciones como Bitcoin a través de un tamaño de bloque restringido, sino que establece un límite indirecto en las tarifas de gas que puede aceptar un único bloque, el objetivo es lograr un consenso sin confianza y asegurar una amplia distribución de nodos.
Desde los CryptoKitties de 2017, el verano de DeFi, hasta el surgimiento posterior de aplicaciones en cadena como GameFi y NFT, la demanda de capacidad de procesamiento en el mercado ha aumentado constantemente. Sin embargo, incluso Ethereum, que es Turing completo, solo puede manejar de 15 a 45 transacciones por segundo ( TPS ). Esto ha llevado a un aumento continuo en los costos de transacción, a tiempos de liquidación más largos y a que la mayoría de las Dapps tengan dificultades para soportar los costos de operación. La red en su conjunto se ha vuelto lenta y cara para los usuarios, y el problema de la escalabilidad de la blockchain debe resolverse urgentemente. La solución de escalabilidad ideal es: aumentar la velocidad de transacción y la capacidad de procesamiento de la red blockchain tanto como sea posible, sin sacrificar la descentralización y la seguridad.
2. Categorías de soluciones de escalabilidad
Nosotros clasificamos las soluciones de escalabilidad en dos categorías principales: escalabilidad en cadena y escalabilidad off-chain, basándonos en el criterio de "si se cambia una capa de la red principal".
2.1 Expansión en cadena
Concepto clave: solución para aumentar la capacidad mediante el cambio de una capa del protocolo de la red principal, siendo la principal solución actual el sharding.
La expansión en cadena tiene varias soluciones, este artículo no se desarrollará, solo enumeraré brevemente dos:
La opción uno es expandir el espacio del bloque, aumentando 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 unirse a los nodos y reducirá el grado de "descentralización".
La opción dos es el sharding, que divide el libro mayor de la blockchain en varias partes, donde diferentes fragmentos, es decir, diferentes nodos, son responsables de diferentes registros contables. El cálculo en paralelo puede procesar múltiples transacciones simultáneamente; esto puede reducir la presión de cálculo en los nodos y el umbral de entrada, mejorar la velocidad de procesamiento de transacciones y el grado de descentralización; pero significa que la potencia de cálculo de toda la red se dispersa, lo que reducirá la "seguridad" de toda la red.
Cambiar el código del protocolo principal de la red puede tener efectos negativos impredecibles, ya que cualquier pequeña vulnerabilidad de seguridad en la capa subyacente puede amenazar seriamente la seguridad de toda la red, lo que podría obligar a la red a bifurcarse o interrumpir la actualización de la reparación.
2.2 off-chain expansión
Concepto clave: solución de escalado que no cambia el protocolo de la red principal de capa uno existente.
Las soluciones de escalado off-chain se pueden dividir en Layer2 y otras soluciones:
Layer2: Canales de Estado, Plasma, Rollups( Rollups Optimistas y Rollups ZK)
Otros: Sidechains, Validium
3. Profundidad de la solución de escalado 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 los usuarios se realicen off-chain, con el fin de reducir el tiempo y costo de las transacciones de los usuarios, y permitir que el número de transacciones no tenga límites.
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, el cual controla los activos depositados en el canal, verifica las actualizaciones de estado y arbitra las disputas entre los participantes. Después de que los participantes despliegan el contrato en la red blockchain, depositan fondos y los bloquean; una vez que ambas partes firman y confirman, el canal se abre oficialmente. El canal permite transacciones off-chain gratuitas e ilimitadas entre los participantes siempre que el valor neto de la transferencia no exceda el total de tokens depositados. Los participantes se turnan para enviar actualizaciones de estado al otro, esperando la confirmación de firma del otro. Una vez que el otro participante confirma con su firma, la 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 disputa o cierre del canal se dependerá de la cadena principal para la confirmación. Cuando se necesita cerrar el canal, cualquiera de los participantes puede presentar una solicitud de transacción en la cadena principal; si la solicitud de salida obtiene la aprobación por firma unánime, se ejecuta inmediatamente en cadena, es decir, el contrato inteligente distribuye los fondos bloqueados restantes según el saldo de cada participante en el estado final del canal; si otros participantes no firman para aprobar, todos deben esperar a que termine el "período de desafío" para recibir los fondos restantes.
En resumen, el esquema de canales de estado puede reducir significativamente la carga de cálculo en la cadena principal, aumentar la velocidad de las transacciones y disminuir los costos de transacción.
(# 3.1.2 Línea de tiempo
2015/02, Joseph Poon y Thaddeus Dryja publican el borrador del libro blanco de la red Lightning.
2015/11, 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.
2016/01, Joseph Poon y Thaddeus Dryja publicaron oficialmente el libro blanco "The Bitcoin Lightning Network: Scalable Off-Chain Instant Payments" proponiendo un esquema de escalado para la red Lightning de Bitcoin, Payment Channel) canal de pago###, que se utiliza únicamente para procesar pagos de transferencias en la red de Bitcoin.
En noviembre de 2017, se propuso el primer marco de diseño de State Channel basado en Payment Channel, llamado Sprites.
2018/06, Counterfactual propuso un diseño detallado de Canales de Estado Generalizados, que es el primer diseño completamente relacionado con canales de estado.
2018/10, el artículo Generalised State Channel Networks introdujo los conceptos de State Channel Networks y Virtual Channels.
2019/02, el concepto de canales de estado se amplió a N-Party Channels, Nitro es el primer protocolo establecido sobre esta idea.
2019/10, Pisa para abordar el problema de que todos los participantes necesitan estar en línea de forma continua, amplió el concepto de Watchtowers.
2020/03, Hydra propuso Canales Isomórficos Rápidos.
(# 3.1.3 Principios técnicos
Flujo de trabajo en la cadena tradicional: Alice y Bob interactúan con un contrato inteligente desplegado en la mainnet, los usuarios cambian el estado del contrato inteligente enviando transacciones a la cadena. La desventaja es que provoca problemas de tiempo y costo.
El flujo de trabajo general que siguen la mayoría de los protocolos de canales de estado:
Alice y Bob transfieren fondos de su EOA personal a una dirección de contrato en la cadena, estos fondos se bloquean en el contrato hasta que se cierran los canales y se devuelven al usuario; después de que ambos firman y confirman, el canal de estado entre ellos se abre oficialmente.
Alice y Bob pueden realizar teóricamente un número ilimitado de transacciones off-chain a través de este canal, y los participantes se comunican entre sí mediante mensajes firmados encriptados. Ambos usuarios deben firmar cada transacción para evitar 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 desea cerrar el canal y finalizar la transacción con Bob, Alice debe 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 a la firma, el contrato liberará los fondos bloqueados y los devolverá al usuario correspondiente al final del período de desafío.
![Informe de investigación en profundidad: Análisis completo de la expansión off-chain])https://img-cdn.gateio.im/webp-social/moments-ead28de03be9fc22dcfe3f679ee36bc5.webp###
Flujo de trabajo del canal de estado en un escenario pesimista: al principio, dos participantes depositan fondos y luego comienzan a intercambiar actualizaciones de estado. Supongamos que en un momento dado, Bob no responde a la firma de actualización de estado enviada por Alice en su turno, en este momento, Alice puede iniciar un desafío presentando su última actualización de estado válida al contrato, esta actualización válida también incluye la firma anterior de Bob, lo que demuestra que la última transacción ha sido aprobada por Bob y que el estado final ha sido confirmado por Bob. Luego, el contrato permite que Bob responda 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 dentro de 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 de relámpago de Bitcoin:
Resumen: La red Lightning es un canal de pagos de bajo valor en la red de Bitcoin, cuya evolución técnica en general ha pasado por: construir un canal de pagos unidireccional con 2/2 firmas múltiples, luego se puede construir un canal de pagos bidireccional tras añadir RSMC, y después, al añadir HTLC, se pueden conectar los canales de pagos para extender a pagos multipersonales, finalmente construyendo una red de pagos, es decir, la red Lightning. A través de canales de pagos 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 de Bitcoin. El uso general de la red Lightning sigue el proceso de "depósito ### establecer canal ### → transacción de la red Lightning ( actualizar estado del canal ) → reembolso/liquidación ( cerrar canal )"; teóricamente, la red Lightning puede procesar un millón de transacciones por segundo.
Línea de tiempo:
Desarrollo ecológico: El ecosistema de la red Lightning de BTC de abajo hacia arriba es: la red BTC de base---infraestructura básica clave---varias Dapps.
La infraestructura básica central incluye:
Sobre la infraestructura básica se encuentran diversos servicios financieros y de pago, así como aplicaciones, por ejemplo, Strike se basa en soluciones LND que permiten a los usuarios comprar y vender BTC, utilizar BTC para recompensar a los creadores en Twitter y permitir a los comerciantes de Shopify aceptar BTC, entre otros.
Hasta noviembre de 2022,