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 estas, 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.
Definición de la descentralización, seguridad y escalabilidad de la blockchain:
Descentralización: cualquier persona puede convertirse en un nodo para participar en la producción y verificación del sistema blockchain, cuanto más nodos haya, mayor será el grado de descentralización, asegurando que la red no esté controlada por un pequeño grupo.
Seguridad: Cuanto mayor sea el costo para obtener el control del sistema 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 una gran cantidad de transacciones.
El primer gran hard fork de la red Bitcoin surgió de un problema de escalabilidad. A medida que aumentaba el número de usuarios y el volumen de transacciones de Bitcoin, la red, 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, con una parte a favor de ampliar el bloque y la otra que considera que se debe optimizar la estructura de la cadena principal utilizando el esquema de segregated witness (Segwit). El 1 de agosto de 2017, la parte que apoyaba la ampliación del bloque ejecutó un nuevo cliente por su cuenta, lo que llevó al primer gran hard fork en la historia de Bitcoin, dando lugar a la nueva criptomoneda BCH.
De igual manera, la red de Ethereum optó por sacrificar una parte de la escalabilidad para garantizar la seguridad y la descentralización de la red. Aunque no limita el tamaño de los bloques como lo hace la red de Bitcoin, establece un límite indirecto en las tarifas de gas que puede contener un solo bloque, con el objetivo de lograr un Consenso Sin Confianza y asegurar una amplia distribución de nodos.
Desde CryptoKitties en 2017, el verano de DeFi, hasta la posterior aparición de aplicaciones en cadena como GameFi y NFT, la demanda del mercado por el rendimiento ha ido en aumento. 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 en los costos de transacción y a un prolongamiento del tiempo de liquidación, dificultando que la mayoría de las Dapps soporten los costos operativos. La red se ha vuelto lenta y cara para los usuarios, y el problema de escalabilidad de la blockchain necesita ser resuelto urgentemente. La solución ideal de escalabilidad es: aumentar la velocidad y el rendimiento de las transacciones de la red blockchain tanto como sea posible, sin sacrificar la descentralización y la seguridad.
2. Categorías de soluciones de escalabilidad
Según el estándar de "si se cambia una capa de la red principal", se pueden clasificar los planes de expansión en dos grandes categorías: expansión on-chain y expansión off-chain.
2.1 expansión on-chain
Concepto clave: solución para lograr un efecto de escalado mediante el cambio de una capa del protocolo de la red principal, la solución principal actual es el sharding.
La expansión en cadena tiene varias soluciones, este artículo no se extenderá, solo se enumerarán brevemente dos:
La opción uno es ampliar el espacio de bloque, es decir, aumentar la cantidad de transacciones empaquetadas en cada bloque, pero esto incrementará los requisitos para los dispositivos de nodos de alto rendimiento, elevará el umbral de entrada para 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 no todos los nodos participan en todas las contabilidades, sino que diferentes shards, es decir, diferentes nodos, son responsables de diferentes contabilidades, permitiendo que el cálculo en paralelo procese 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 reduce la "seguridad" de toda la red.
Cambiar el código del protocolo de la capa principal de la red puede tener efectos negativos impredecibles; cualquier pequeño fallo de seguridad en la base puede amenazar gravemente la seguridad de toda la red, y la red puede verse obligada a realizar un fork o interrumpir la actualización de reparación.
2.2 off-chain escalamiento
Concepto clave: solución de escalado que no modifica el protocolo de la mainnet de capa uno existente.
Las soluciones de escalado off-chain se pueden dividir en Layer2 y otras soluciones:
Capa 2:
Canales Estatales
Plasma
Rollups
Optimistic Rollups
ZK Rollups
Otros:
Sidechains
Validium
3. Profundidad de la expansión off-chain
Canales de Estado 3.1
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 en caso de resolver disputas. Las interacciones entre usuarios se realizan off-chain, con el fin de reducir el tiempo y costo de las transacciones, permitiendo un número ilimitado de transacciones.
El canal de estado es un protocolo P2P simple, adecuado 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 opera en la cadena principal, el cual 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 sello de tiempo ). Los participantes, después de desplegar el contrato en la red, depositan fondos y los bloquean; después de la confirmación de ambas partes, el canal se abre oficialmente. El canal permite transacciones gratuitas ilimitadas off-chain entre los participantes ( siempre que el valor neto de las transferencias no supere el total de tokens depositados ). Los participantes se turnan para enviar actualizaciones de estado al otro, esperando la confirmación de firma de la otra parte. Una vez que la otra parte 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 disputas o cierre del canal se dependerá de la confirmación de la cadena principal. Al cerrar el canal, cualquiera de los participantes puede proponer una solicitud de transacción en la cadena principal; si se obtiene la aprobación por unanimidad de las firmas, se ejecuta inmediatamente en la cadena, es decir, el contrato distribuye los fondos restantes bloqueados según el saldo final de cada participante en el canal; si otros participantes no firman la aprobación, 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 computacional de la cadena principal, aumentar la velocidad de las transacciones y disminuir los costos de las transacciones.
3.1.2 Línea de tiempo
2015/02, Joseph Poon y Thaddeus Dryja publican el 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.
2016/01, Joseph Poon y Thaddeus Dryja publicaron oficialmente el libro blanco "The Bitcoin Lightning Network: Scalable Off-Chain Instant Payments" proponiendo una solución de escalabilidad para la red Lightning de Bitcoin llamada Payment Channel(, que se utiliza únicamente para procesar pagos en la red de Bitcoin.
En noviembre de 2017, se propuso el primer estándar de diseño de State Channel basado en el marco de Payment Channel, llamado Sprites.
2018/06, Counterfactual presentó 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 propuso los conceptos de State Channel Networks y Virtual Channels.
2019/02, el concepto de canales de estado se expandió a N-Party Channels, Nitro es el primer protocolo basado en esta idea.
2019/10, Pisa amplió el concepto de Watchtowers para resolver el problema de que todos los participantes deban estar en línea de forma continua.
Flujo de trabajo tradicional en cadena: Alice y Bob interactúan con el contrato inteligente desplegado en la red principal, los usuarios cambian el estado del contrato inteligente enviando transacciones a la cadena. La desventaja es que trae los problemas de tiempo y costo discutidos anteriormente.
El flujo de trabajo general que la mayoría de los protocolos de canales de estado siguen: en un caso optimista, Alice y Bob deben ejecutar la misma operación que antes, pero esta vez utilizando un canal de estado, sin interactuar con contratos en la cadena.
Primer paso, 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 cierren el canal y se devuelvan al usuario; una vez que ambos firman la confirmación, el canal de estado entre ellos se abre oficialmente.
En el segundo paso, Alice y Bob pueden realizar teóricamente transacciones ilimitadas fuera de la cadena a través de este canal, los participantes se comunican entre sí mediante mensajes firmados criptográficamente ### en lugar de comunicarse con la red blockchain (. 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.
Paso tres, si Alice quiere cerrar el canal y terminar la transacción con Bob, Alice debe presentar el estado final de su cuenta al contrato. Si Bob firma y aprueba, el contrato liberará los fondos bloqueados y los devolverá al usuario correspondiente según el estado final. Si Bob no responde a la firma, el contrato liberará los fondos bloqueados y los devolverá al usuario correspondiente una vez que termine el período de desafío.
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 algún momento, Bob no responde a la firma de actualización de estado enviada por Alice en una ronda, en este momento, Alice puede iniciar un desafío presentando su último estado válido al contrato, este estado válido también incluye la firma anterior de Bob, demostrando así que la última transacción ha sido aprobada por 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 negociando dentro del canal de estado; si Bob no responde dentro de este período de tiempo, el contrato cierra automáticamente el canal de estado y devuelve los fondos a Alice.
![Informe de investigación exhaustiva: Análisis completo de la Profundidad off-chain])https://img-cdn.gateio.im/webp-social/moments-ad088ac016d75b1ae0b0eda699e74709.webp(
)# 3.1.4 Ventajas y desventajas
Ventajas:
Confirmación de transacciones instantáneas
Tarifas de transacción extremadamente bajas
Buena escalabilidad, teóricamente TPS infinito
Buena privacidad, solo el estado final está en la cadena
Actualización de estado flexible
Desventajas:
Se requiere bloquear fondos por adelantado
Los participantes deben monitorear en línea de manera continua
Se debe esperar el período de desafío cuando el canal está cerrado
Establecer canales múltiples es complejo
No apto para transferencias de valor a gran escala
![Informe de investigación profunda de diez mil palabras: Análisis completo de la expansión off-chain]###https://img-cdn.gateio.im/webp-social/moments-815c5eb2bdba725e04eebe67b22d42aa.webp(
)# 3.1.5 Aplicación
Red Lightning de Bitcoin:
Resumen:
La red Lightning es un canal de pagos de bajo valor en la red de Bitcoin. La evolución tecnológica general ha pasado por: construir un canal de pagos unidireccional mediante 2/2 multisig, agregar RSMC para construir un canal de pagos bidireccional, y luego agregar HTLC para expandir el canal de pagos a pagos entre múltiples partes, finalmente construyendo la 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. La utilización de la red Lightning sigue el proceso "depósito ### establecer canal ( → transacciones de la red Lightning ) actualizar estado del canal ( → reembolso/liquidación ) cerrar canal ("; teóricamente, 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 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 del Lightning Network, 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.
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, incluidos OKX, Kraken y Bitfinex, anunciaron su apoyo a la red Lightning, permitiendo depósitos y retiros de BTC instantáneos y económicos.
En octubre de 2022, Lightning Labs lanzó la nueva versión alfa del protocolo Taro protocol) basado en Taproot(, que actualmente está en pruebas en la red de pruebas. En el futuro, se podrá utilizar para acuñar, enviar y recibir activos en la red de Bitcoin, y realizar transacciones instantáneas, de gran volumen y a bajo costo a través de la red Lightning.
El 23 de noviembre de 2022, según 1ml.com, la red Lightning tiene un total de 76,236 canales de pago, con un capital de canal de 5049 $BTC)$81.8M(
Desarrollo ecológico:
El ecosistema de la red Lightning de BTC se compone de abajo hacia arriba: la red BTC de base, la infraestructura central y diversas Dapps.
La infraestructura básica incluye:
Soluciones de red Lightning: individuos y empresas pueden ejecutar, conectar a
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.
11 me gusta
Recompensa
11
4
Compartir
Comentar
0/400
StopLossMaster
· hace3h
Demasiado apretado, demasiado apretado.
Ver originalesResponder0
LiquidationWatcher
· 08-05 22:38
Layer2 es realmente genial de usar
Ver originalesResponder0
LiquidityWitch
· 08-05 22:29
La escalabilidad es un punto que vale la pena discutir.
Análisis en profundidad de las soluciones de escalado off-chain: de State Channels a Lighting Network
Análisis profundo 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 estas, 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.
Definición de la descentralización, seguridad y escalabilidad de la blockchain:
Descentralización: cualquier persona puede convertirse en un nodo para participar en la producción y verificación del sistema blockchain, cuanto más nodos haya, mayor será el grado de descentralización, asegurando que la red no esté controlada por un pequeño grupo.
Seguridad: Cuanto mayor sea el costo para obtener el control del sistema 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 una gran cantidad de transacciones.
El primer gran hard fork de la red Bitcoin surgió de un problema de escalabilidad. A medida que aumentaba el número de usuarios y el volumen de transacciones de Bitcoin, la red, 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, con una parte a favor de ampliar el bloque y la otra que considera que se debe optimizar la estructura de la cadena principal utilizando el esquema de segregated witness (Segwit). El 1 de agosto de 2017, la parte que apoyaba la ampliación del bloque ejecutó un nuevo cliente por su cuenta, lo que llevó al primer gran hard fork en la historia de Bitcoin, dando lugar a la nueva criptomoneda BCH.
De igual manera, la red de Ethereum optó por sacrificar una parte de la escalabilidad para garantizar la seguridad y la descentralización de la red. Aunque no limita el tamaño de los bloques como lo hace la red de Bitcoin, establece un límite indirecto en las tarifas de gas que puede contener un solo bloque, con el objetivo de lograr un Consenso Sin Confianza y asegurar una amplia distribución de nodos.
Desde CryptoKitties en 2017, el verano de DeFi, hasta la posterior aparición de aplicaciones en cadena como GameFi y NFT, la demanda del mercado por el rendimiento ha ido en aumento. 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 en los costos de transacción y a un prolongamiento del tiempo de liquidación, dificultando que la mayoría de las Dapps soporten los costos operativos. La red se ha vuelto lenta y cara para los usuarios, y el problema de escalabilidad de la blockchain necesita ser resuelto urgentemente. La solución ideal de escalabilidad es: aumentar la velocidad y el rendimiento de las transacciones de la red blockchain tanto como sea posible, sin sacrificar la descentralización y la seguridad.
2. Categorías de soluciones de escalabilidad
Según el estándar de "si se cambia una capa de la red principal", se pueden clasificar los planes de expansión en dos grandes categorías: expansión on-chain y expansión off-chain.
2.1 expansión on-chain
Concepto clave: solución para lograr un efecto de escalado mediante el cambio de una capa del protocolo de la red principal, la solución principal actual es el sharding.
La expansión en cadena tiene varias soluciones, este artículo no se extenderá, solo se enumerarán brevemente dos:
La opción uno es ampliar el espacio de bloque, es decir, aumentar la cantidad de transacciones empaquetadas en cada bloque, pero esto incrementará los requisitos para los dispositivos de nodos de alto rendimiento, elevará el umbral de entrada para 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 no todos los nodos participan en todas las contabilidades, sino que diferentes shards, es decir, diferentes nodos, son responsables de diferentes contabilidades, permitiendo que el cálculo en paralelo procese 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 reduce la "seguridad" de toda la red.
Cambiar el código del protocolo de la capa principal de la red puede tener efectos negativos impredecibles; cualquier pequeño fallo de seguridad en la base puede amenazar gravemente la seguridad de toda la red, y la red puede verse obligada a realizar un fork o interrumpir la actualización de reparación.
2.2 off-chain escalamiento
Concepto clave: solución de escalado que no modifica el protocolo de la mainnet de capa uno existente.
Las soluciones de escalado off-chain se pueden dividir en Layer2 y otras soluciones:
Capa 2:
Otros:
3. Profundidad de la expansión off-chain
Canales de Estado 3.1
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 en caso de resolver disputas. Las interacciones entre usuarios se realizan off-chain, con el fin de reducir el tiempo y costo de las transacciones, permitiendo un número ilimitado de transacciones.
El canal de estado es un protocolo P2P simple, adecuado 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 opera en la cadena principal, el cual 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 sello de tiempo ). Los participantes, después de desplegar el contrato en la red, depositan fondos y los bloquean; después de la confirmación de ambas partes, el canal se abre oficialmente. El canal permite transacciones gratuitas ilimitadas off-chain entre los participantes ( siempre que el valor neto de las transferencias no supere el total de tokens depositados ). Los participantes se turnan para enviar actualizaciones de estado al otro, esperando la confirmación de firma de la otra parte. Una vez que la otra parte 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 disputas o cierre del canal se dependerá de la confirmación de la cadena principal. Al cerrar el canal, cualquiera de los participantes puede proponer una solicitud de transacción en la cadena principal; si se obtiene la aprobación por unanimidad de las firmas, se ejecuta inmediatamente en la cadena, es decir, el contrato distribuye los fondos restantes bloqueados según el saldo final de cada participante en el canal; si otros participantes no firman la aprobación, 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 computacional de la cadena principal, aumentar la velocidad de las transacciones y disminuir los costos de las transacciones.
3.1.2 Línea de tiempo
2015/02, Joseph Poon y Thaddeus Dryja publican el 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.
2016/01, Joseph Poon y Thaddeus Dryja publicaron oficialmente el libro blanco "The Bitcoin Lightning Network: Scalable Off-Chain Instant Payments" proponiendo una solución de escalabilidad para la red Lightning de Bitcoin llamada Payment Channel(, que se utiliza únicamente para procesar pagos en la red de Bitcoin.
En noviembre de 2017, se propuso el primer estándar de diseño de State Channel basado en el marco de Payment Channel, llamado Sprites.
2018/06, Counterfactual presentó 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 propuso los conceptos de State Channel Networks y Virtual Channels.
2019/02, el concepto de canales de estado se expandió a N-Party Channels, Nitro es el primer protocolo basado en esta idea.
2019/10, Pisa amplió el concepto de Watchtowers para resolver el problema de que todos los participantes deban estar en línea de forma continua.
2020/03, Hydra propuso Canales Isomórficos Rápidos.
)# 3.1.3 Principios técnicos
Flujo de trabajo tradicional en cadena: Alice y Bob interactúan con el contrato inteligente desplegado en la red principal, los usuarios cambian el estado del contrato inteligente enviando transacciones a la cadena. La desventaja es que trae los problemas de tiempo y costo discutidos anteriormente.
El flujo de trabajo general que la mayoría de los protocolos de canales de estado siguen: en un caso optimista, Alice y Bob deben ejecutar la misma operación que antes, pero esta vez utilizando un canal de estado, sin interactuar con contratos en la cadena.
Primer paso, 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 cierren el canal y se devuelvan al usuario; una vez que ambos firman la confirmación, el canal de estado entre ellos se abre oficialmente.
En el segundo paso, Alice y Bob pueden realizar teóricamente transacciones ilimitadas fuera de la cadena a través de este canal, los participantes se comunican entre sí mediante mensajes firmados criptográficamente ### en lugar de comunicarse con la red blockchain (. 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.
Paso tres, si Alice quiere cerrar el canal y terminar la transacción con Bob, Alice debe presentar el estado final de su cuenta al contrato. Si Bob firma y aprueba, el contrato liberará los fondos bloqueados y los devolverá al usuario correspondiente según el estado final. Si Bob no responde a la firma, el contrato liberará los fondos bloqueados y los devolverá al usuario correspondiente una vez que termine el período de desafío.
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 algún momento, Bob no responde a la firma de actualización de estado enviada por Alice en una ronda, en este momento, Alice puede iniciar un desafío presentando su último estado válido al contrato, este estado válido también incluye la firma anterior de Bob, demostrando así que la última transacción ha sido aprobada por 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 negociando dentro del canal de estado; si Bob no responde dentro de este período de tiempo, el contrato cierra automáticamente el canal de estado y devuelve los fondos a Alice.
![Informe de investigación exhaustiva: Análisis completo de la Profundidad off-chain])https://img-cdn.gateio.im/webp-social/moments-ad088ac016d75b1ae0b0eda699e74709.webp(
)# 3.1.4 Ventajas y desventajas
Ventajas:
Desventajas:
![Informe de investigación profunda de diez mil palabras: Análisis completo de la expansión off-chain]###https://img-cdn.gateio.im/webp-social/moments-815c5eb2bdba725e04eebe67b22d42aa.webp(
)# 3.1.5 Aplicación
Red Lightning de Bitcoin:
Resumen: La red Lightning es un canal de pagos de bajo valor en la red de Bitcoin. La evolución tecnológica general ha pasado por: construir un canal de pagos unidireccional mediante 2/2 multisig, agregar RSMC para construir un canal de pagos bidireccional, y luego agregar HTLC para expandir el canal de pagos a pagos entre múltiples partes, finalmente construyendo la 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. La utilización de la red Lightning sigue el proceso "depósito ### establecer canal ( → transacciones de la red Lightning ) actualizar estado del canal ( → reembolso/liquidación ) cerrar canal ("; teóricamente, puede procesar un millón de transacciones por segundo.
Línea de tiempo:
Desarrollo ecológico: El ecosistema de la red Lightning de BTC se compone de abajo hacia arriba: la red BTC de base, la infraestructura central y diversas Dapps.
La infraestructura básica incluye: