La visión futura de la blockchain es la descentralización, la seguridad y la escalabilidad, pero generalmente 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, mejorar el rendimiento y la velocidad de las transacciones de la blockchain bajo la premisa de garantizar 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, 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 blockchain; cuanto mayor sea el número de nodos, mayor será el grado de descentralización, asegurando que la red no esté controlada por participantes centralizados.
Seguridad: cuanto mayor sea el costo necesario para obtener el control del sistema blockchain, mayor será la seguridad, la cadena podrá resistir ataques de un mayor porcentaje de participantes.
Escalabilidad: la capacidad de la blockchain para procesar una gran cantidad de transacciones.
La primera bifurcación dura significativa de la red Bitcoin se originó en el 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 1MB por bloque, comenzó a enfrentar problemas de congestión. Desde 2015, la comunidad de Bitcoin ha tenido desacuerdos sobre el problema de escalabilidad; una parte apoya la expansión del bloque, mientras que la otra cree que se debe utilizar el esquema de testigos segregados para optimizar la estructura de la cadena principal. El 1 de agosto de 2017, el sistema de cliente de Bitcoin ABC, que desarrolló bloques de 8MB, comenzó a funcionar, lo que llevó a la primera bifurcación dura significativa de Bitcoin y dio lugar a la nueva criptomoneda BCH.
La red de Ethereum también elige 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 Bitcoin, restringe la cantidad de tarifas de combustible que puede contener un solo bloque para limitar el volumen de transacciones, con el objetivo de lograr un Consenso Sin Confianza y asegurar una amplia distribución de nodos.
Desde CryptoKitties en 2017, pasando por el verano DeFi, hasta el surgimiento posterior de aplicaciones on-chain como GameFi y NFT, la demanda de capacidad de procesamiento en el mercado ha aumentado constantemente. Pero incluso Ethereum, que es Turing completo, solo puede manejar entre 15 y 45 transacciones por segundo, lo que lleva a un aumento en los costos de transacción, tiempos de liquidación más largos y hace que la mayoría de los Dapps no puedan soportar los costos de operación, lo que hace que toda la red sea lenta y cara para los usuarios. El problema de la escalabilidad de la blockchain necesita ser resuelto 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
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 en cadena y expansión off-chain.
2.1 escalabilidad en cadena
Concepto clave: solución que logra un efecto de escalado al cambiar un nivel del protocolo de la red principal, la principal solución actual es el sharding.
La escalabilidad en cadena tiene varias soluciones, a continuación se enumeran brevemente dos:
La opción uno es ampliar el espacio del bloque, aumentando la cantidad de transacciones empaquetadas en cada bloque, pero esto incrementará los requisitos para dispositivos de nodos de alto rendimiento, reduciendo el grado de "descentralización".
La opción dos es el sharding, que consiste en dividir el libro mayor de la blockchain en varias partes, donde diferentes nodos son responsables de diferentes registros, permitiendo que el cálculo en paralelo procese múltiples transacciones al mismo tiempo. Esto puede reducir la presión computacional sobre los nodos y la barrera de entrada, mejorar la velocidad de procesamiento de transacciones y el grado de descentralización, pero disminuirá la "seguridad" de toda la red.
Modificar el código del protocolo de la red principal en una capa puede tener consecuencias negativas impredecibles, ya que cualquier pequeño fallo de seguridad en el nivel subyacente puede amenazar gravemente la seguridad de toda la red, lo que podría obligar a la red a realizar bifurcaciones o interrupciones para reparaciones y actualizaciones. Por ejemplo, el incidente del fallo de inflación de Zcash en 2018: el código de Zcash se basa en una versión modificada del código de Bitcoin 0.11.2, y en 2018 un ingeniero descubrió un grave fallo en el código subyacente, que permitía la emisión ilimitada de tokens; el equipo tardó 8 meses en arreglarlo en secreto y solo después de la reparación se hizo público este incidente.
2.2 off-chain expansión
Concepto clave: solución de escalado que no modifica el protocolo de la capa uno existente.
Las soluciones de escalado off-chain se pueden subdividir en Layer 2 y otras soluciones:
Layer2: Construir nuevas capas sobre la cadena principal, procesar la mayoría de las transacciones y cálculos, solo interactuar con la cadena principal cuando sea necesario. Incluye canales de estado, cadenas laterales, Plasma, Rollups, etc.
Otras soluciones: no construir una nueva capa, sino lograr la escalabilidad a través de otros medios técnicos. Como Validium, Volition, etc.
3. Profundidad de las soluciones de escalabilidad off-chain
Canales Estatales 3.1
3.1.1 Resumen
Los canales de estado estipulan que los usuarios solo necesitan interactuar con la red principal al abrir, cerrar o resolver disputas en el canal, realizando las interacciones entre usuarios off-chain para reducir el tiempo y el costo monetario de las transacciones, y así lograr un número ilimitado de transacciones.
Los canales de estado son 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 se ejecuta en la cadena principal, y este contrato 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 despliegan el contrato en la red 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 su valor neto de transferencias no exceda el total de tokens depositados ). Los participantes envían alternadamente actualizaciones de estado al otro, esperando la confirmación de 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 disputa o cierre del canal se dependerá de la confirmación de la cadena principal. Cuando se necesita cerrar el canal, cualquiera de los participantes puede solicitar una transacción en la cadena principal, y si la solicitud de salida recibe la aprobación de firma unánime de todos, se ejecuta inmediatamente en la cadena, es decir, el contrato inteligente distribuye los fondos restantes bloqueados según el saldo de cada participante en el estado final del canal; si otros participantes no han aprobado la firma, todos deberán 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 en gran medida la carga computacional de 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" que propone el esquema de escalado de la red Lightning de Bitcoin Payment Channel(, el cual se utiliza únicamente para procesar pagos de transferencia en la red de Bitcoin.
En noviembre de 2017, se propuso la especificación de diseño Sprites relacionada con State Channel basada en el marco de Payment Channel.
2018/06, Counterfactual presentó un diseño de Canales de Estado Generalizados muy detallado, que es el primer diseño completamente relacionado con los canales de estado.
En octubre de 2018, 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 los N-Party Channels, Nitro es el primer protocolo basado en esta idea.
2019/10, Pisa para resolver el problema de que todos los participantes necesitan estar en línea de manera continua, amplió el concepto de Watchtowers.
La Figura 1 muestra el flujo de trabajo en la cadena tradicional: Alice y Bob interactúan con un contrato inteligente desplegado en la red principal, y los usuarios cambian el estado del contrato inteligente enviando transacciones a la cadena. La desventaja es que esto genera los problemas de tiempo y costo discutidos anteriormente.
![Informe de investigación de profundidad de diez mil palabras: Análisis completo de la expansión off-chain]###https://img-cdn.gateio.im/webp-social/moments-ead28de03be9fc22dcfe3f679ee36bc5.webp(
La Figura 2 muestra el flujo de trabajo general que la mayoría de los protocolos de canales de estado siguen: en un caso optimista, Alice y Bob necesitan ejecutar la misma operación que antes, pero esta vez utilizan un canal de estado en lugar de interactuar con un contrato en cadena.
Primer paso, Alice y Bob interactúan depositando fondos de su EOA personal a la dirección del contrato en cadena ), 1,2(, estos fondos se bloquean en el contrato hasta que se cierre el canal, momento en el cual el saldo se devuelve al usuario; después de que ambos firman y confirman, el canal de estado entre ellos se abre oficialmente.
Segundo paso, Alice y Bob pueden realizar transacciones ilimitadas off-chain a través de este canal ) línea azul discontinua (, los participantes se comunican entre sí a través de mensajes de firma cifrados ) en lugar de comunicarse con la red de 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 el otro.
Tercer paso, si Alice quiere cerrar el canal y finalizar la transacción con Bob, Alice necesita enviar el estado final de su cuenta ) interaccion 3( al contrato, si Bob firma y aprueba, el contrato liberará los fondos bloqueados según el estado final de vuelta al usuario correspondiente ) interaccion 4,5(. Si Bob no responde a la firma, el contrato liberará los fondos bloqueados de vuelta al usuario correspondiente después de que finalice el período de desafío.
![Informe de investigación en profundidad de 10,000 palabras: Análisis completo de la escalabilidad off-chain])https://img-cdn.gateio.im/webp-social/moments-ad088ac016d75b1ae0b0eda699e74709.webp(
La Figura 3 muestra el flujo de trabajo del canal de estado en un escenario pesimista: al principio, dos participantes depositan fondos ) interacción 1, 2(, y luego comienzan a intercambiar actualizaciones de estado ) línea punteada azul (. Supongamos que en algún momento, Bob no responde a la firma de actualización de estado enviada por Alice ) interacción 3(, en este momento, Alice puede iniciar un desafío al enviar su último estado válido al contrato ) interacción 4(, este estado válido 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 dentro de un período de tiempo presentando el siguiente estado al contrato; si Bob responde, ambos pueden continuar transaccionando 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 ) interacción 5(.
![Informe de investigación en profundidad: Análisis completo de la expansión off-chain])https://img-cdn.gateio.im/webp-social/moments-815c5eb2bdba725e04eebe67b22d42aa.webp(
)# 3.1.4 Ventajas y desventajas
Ventajas:
Confirmación instantánea de transacciones
Alta capacidad de procesamiento
Bajo costo de transacción
Buena privacidad
Desventajas:
Se necesita bloquear fondos
Se requiere que todos los participantes estén en línea en tiempo real
Retiro con retraso
El costo de inicialización del canal es alto
Molestia por reabrir el canal
La complejidad de la red de canales es alta
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, cuya evolución tecnológica en su conjunto ha pasado por: la construcción de un canal de pagos unidireccional mediante 2/2 firmas múltiples, y tras la adición de RSMC###Revocable Sequence Maturity Contract( se puede construir un canal de pagos bidireccional, y luego tras la adición de HTLC)Hash Time Lock Contract( se pueden conectar canales de pagos para extender a pagos multipersonales, y finalmente construir una red de pagos que es 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)terminar 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 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;
15 de marzo de 2018, Lightning Labs lanzó la primera versión de la red principal de la red Lightning, Lightning Network Daemon )LND( versión 0.4.
A principios de 2021, la capacidad pública de la red Lightning )TVL( era de solo aproximadamente 40 millones de dólares, con alrededor de 100,000 usuarios utilizando la red Lightning.
En junio de 2021, El Salvador anunció que adoptaría el bitcoin como moneda de curso legal,
Ver originales
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.
19 me gusta
Recompensa
19
5
Republicar
Compartir
Comentar
0/400
LiquidationSurvivor
· 08-10 12:37
El triángulo de la muerte, un tema recurrente
Ver originalesResponder0
GateUser-00be86fc
· 08-10 12:35
Tres de dos es realmente mortal
Ver originalesResponder0
GateUser-bd883c58
· 08-10 12:30
Es un verdadero rompecabezas triangular, que nunca se puede resolver.
Ver originalesResponder0
LightningPacketLoss
· 08-10 12:16
¿Imposible triangular? Esto no es más que destino.
Análisis de la solución de escalado off-chain: principios y aplicaciones de la tecnología del estado del canal
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 generalmente 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, mejorar el rendimiento y la velocidad de las transacciones de la blockchain bajo la premisa de garantizar 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, 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 blockchain; cuanto mayor sea el número de nodos, mayor será el grado de descentralización, asegurando que la red no esté controlada por participantes centralizados.
Seguridad: cuanto mayor sea el costo necesario para obtener el control del sistema blockchain, mayor será la seguridad, la cadena podrá resistir ataques de un mayor porcentaje de participantes.
Escalabilidad: la capacidad de la blockchain para procesar una gran cantidad de transacciones.
La primera bifurcación dura significativa de la red Bitcoin se originó en el 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 1MB por bloque, comenzó a enfrentar problemas de congestión. Desde 2015, la comunidad de Bitcoin ha tenido desacuerdos sobre el problema de escalabilidad; una parte apoya la expansión del bloque, mientras que la otra cree que se debe utilizar el esquema de testigos segregados para optimizar la estructura de la cadena principal. El 1 de agosto de 2017, el sistema de cliente de Bitcoin ABC, que desarrolló bloques de 8MB, comenzó a funcionar, lo que llevó a la primera bifurcación dura significativa de Bitcoin y dio lugar a la nueva criptomoneda BCH.
La red de Ethereum también elige 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 Bitcoin, restringe la cantidad de tarifas de combustible que puede contener un solo bloque para limitar el volumen de transacciones, con el objetivo de lograr un Consenso Sin Confianza y asegurar una amplia distribución de nodos.
Desde CryptoKitties en 2017, pasando por el verano DeFi, hasta el surgimiento posterior de aplicaciones on-chain como GameFi y NFT, la demanda de capacidad de procesamiento en el mercado ha aumentado constantemente. Pero incluso Ethereum, que es Turing completo, solo puede manejar entre 15 y 45 transacciones por segundo, lo que lleva a un aumento en los costos de transacción, tiempos de liquidación más largos y hace que la mayoría de los Dapps no puedan soportar los costos de operación, lo que hace que toda la red sea lenta y cara para los usuarios. El problema de la escalabilidad de la blockchain necesita ser resuelto 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
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 en cadena y expansión off-chain.
2.1 escalabilidad en cadena
Concepto clave: solución que logra un efecto de escalado al cambiar un nivel del protocolo de la red principal, la principal solución actual es el sharding.
La escalabilidad en cadena tiene varias soluciones, a continuación se enumeran brevemente dos:
La opción uno es ampliar el espacio del bloque, aumentando la cantidad de transacciones empaquetadas en cada bloque, pero esto incrementará los requisitos para dispositivos de nodos de alto rendimiento, reduciendo el grado de "descentralización".
La opción dos es el sharding, que consiste en dividir el libro mayor de la blockchain en varias partes, donde diferentes nodos son responsables de diferentes registros, permitiendo que el cálculo en paralelo procese múltiples transacciones al mismo tiempo. Esto puede reducir la presión computacional sobre los nodos y la barrera de entrada, mejorar la velocidad de procesamiento de transacciones y el grado de descentralización, pero disminuirá la "seguridad" de toda la red.
Modificar el código del protocolo de la red principal en una capa puede tener consecuencias negativas impredecibles, ya que cualquier pequeño fallo de seguridad en el nivel subyacente puede amenazar gravemente la seguridad de toda la red, lo que podría obligar a la red a realizar bifurcaciones o interrupciones para reparaciones y actualizaciones. Por ejemplo, el incidente del fallo de inflación de Zcash en 2018: el código de Zcash se basa en una versión modificada del código de Bitcoin 0.11.2, y en 2018 un ingeniero descubrió un grave fallo en el código subyacente, que permitía la emisión ilimitada de tokens; el equipo tardó 8 meses en arreglarlo en secreto y solo después de la reparación se hizo público este incidente.
2.2 off-chain expansión
Concepto clave: solución de escalado que no modifica el protocolo de la capa uno existente.
Las soluciones de escalado off-chain se pueden subdividir en Layer 2 y otras soluciones:
Layer2: Construir nuevas capas sobre la cadena principal, procesar la mayoría de las transacciones y cálculos, solo interactuar con la cadena principal cuando sea necesario. Incluye canales de estado, cadenas laterales, Plasma, Rollups, etc.
Otras soluciones: no construir una nueva capa, sino lograr la escalabilidad a través de otros medios técnicos. Como Validium, Volition, etc.
3. Profundidad de las soluciones de escalabilidad off-chain
Canales Estatales 3.1
3.1.1 Resumen
Los canales de estado estipulan que los usuarios solo necesitan interactuar con la red principal al abrir, cerrar o resolver disputas en el canal, realizando las interacciones entre usuarios off-chain para reducir el tiempo y el costo monetario de las transacciones, y así lograr un número ilimitado de transacciones.
Los canales de estado son 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 se ejecuta en la cadena principal, y este contrato 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 despliegan el contrato en la red 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 su valor neto de transferencias no exceda el total de tokens depositados ). Los participantes envían alternadamente actualizaciones de estado al otro, esperando la confirmación de 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 disputa o cierre del canal se dependerá de la confirmación de la cadena principal. Cuando se necesita cerrar el canal, cualquiera de los participantes puede solicitar una transacción en la cadena principal, y si la solicitud de salida recibe la aprobación de firma unánime de todos, se ejecuta inmediatamente en la cadena, es decir, el contrato inteligente distribuye los fondos restantes bloqueados según el saldo de cada participante en el estado final del canal; si otros participantes no han aprobado la firma, todos deberán 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 en gran medida la carga computacional de 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" que propone el esquema de escalado de la red Lightning de Bitcoin Payment Channel(, el cual se utiliza únicamente para procesar pagos de transferencia en la red de Bitcoin.
En noviembre de 2017, se propuso la especificación de diseño Sprites relacionada con State Channel basada en el marco de Payment Channel.
2018/06, Counterfactual presentó un diseño de Canales de Estado Generalizados muy detallado, que es el primer diseño completamente relacionado con los canales de estado.
En octubre de 2018, 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 los N-Party Channels, Nitro es el primer protocolo basado en esta idea.
2019/10, Pisa para resolver el problema de que todos los participantes necesitan estar en línea de manera continua, amplió el concepto de Watchtowers.
2020/03, Hydra propuso Canales Isomórficos Rápidos.
)# 3.1.3 Principios técnicos
La Figura 1 muestra el flujo de trabajo en la cadena tradicional: Alice y Bob interactúan con un contrato inteligente desplegado en la red principal, y los usuarios cambian el estado del contrato inteligente enviando transacciones a la cadena. La desventaja es que esto genera los problemas de tiempo y costo discutidos anteriormente.
![Informe de investigación de profundidad de diez mil palabras: Análisis completo de la expansión off-chain]###https://img-cdn.gateio.im/webp-social/moments-ead28de03be9fc22dcfe3f679ee36bc5.webp(
La Figura 2 muestra el flujo de trabajo general que la mayoría de los protocolos de canales de estado siguen: en un caso optimista, Alice y Bob necesitan ejecutar la misma operación que antes, pero esta vez utilizan un canal de estado en lugar de interactuar con un contrato en cadena.
Primer paso, Alice y Bob interactúan depositando fondos de su EOA personal a la dirección del contrato en cadena ), 1,2(, estos fondos se bloquean en el contrato hasta que se cierre el canal, momento en el cual el saldo se devuelve al usuario; después de que ambos firman y confirman, el canal de estado entre ellos se abre oficialmente.
Segundo paso, Alice y Bob pueden realizar transacciones ilimitadas off-chain a través de este canal ) línea azul discontinua (, los participantes se comunican entre sí a través de mensajes de firma cifrados ) en lugar de comunicarse con la red de 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 el otro.
Tercer paso, si Alice quiere cerrar el canal y finalizar la transacción con Bob, Alice necesita enviar el estado final de su cuenta ) interaccion 3( al contrato, si Bob firma y aprueba, el contrato liberará los fondos bloqueados según el estado final de vuelta al usuario correspondiente ) interaccion 4,5(. Si Bob no responde a la firma, el contrato liberará los fondos bloqueados de vuelta al usuario correspondiente después de que finalice el período de desafío.
![Informe de investigación en profundidad de 10,000 palabras: Análisis completo de la escalabilidad off-chain])https://img-cdn.gateio.im/webp-social/moments-ad088ac016d75b1ae0b0eda699e74709.webp(
La Figura 3 muestra el flujo de trabajo del canal de estado en un escenario pesimista: al principio, dos participantes depositan fondos ) interacción 1, 2(, y luego comienzan a intercambiar actualizaciones de estado ) línea punteada azul (. Supongamos que en algún momento, Bob no responde a la firma de actualización de estado enviada por Alice ) interacción 3(, en este momento, Alice puede iniciar un desafío al enviar su último estado válido al contrato ) interacción 4(, este estado válido 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 dentro de un período de tiempo presentando el siguiente estado al contrato; si Bob responde, ambos pueden continuar transaccionando 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 ) interacción 5(.
![Informe de investigación en profundidad: Análisis completo de la expansión off-chain])https://img-cdn.gateio.im/webp-social/moments-815c5eb2bdba725e04eebe67b22d42aa.webp(
)# 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 de Bitcoin, cuya evolución tecnológica en su conjunto ha pasado por: la construcción de un canal de pagos unidireccional mediante 2/2 firmas múltiples, y tras la adición de RSMC###Revocable Sequence Maturity Contract( se puede construir un canal de pagos bidireccional, y luego tras la adición de HTLC)Hash Time Lock Contract( se pueden conectar canales de pagos para extender a pagos multipersonales, y finalmente construir una red de pagos que es 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)terminar canal("; teóricamente, la red Lightning puede procesar un millón de transacciones por segundo.
Línea de tiempo: