Profundidad de análisis de la escalabilidad off-chain
Autor: Cobo Ventures
1. La necesidad de la ampliació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 mejorar 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. Cuantos más nodos haya, mayor será el grado de descentralización, asegurando que la red no esté controlada por unos pocos grandes participantes centralizados.
Seguridad: Cuanto mayor sea el costo para obtener el control del sistema blockchain, mayor será la seguridad, y 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 de Bitcoin surgió de un problema de escalabilidad. A medida que aumentaban el número de usuarios y el volumen de transacciones, la red de Bitcoin, con un límite de 1 MB por bloque, comenzó a enfrentar problemas de congestión; desde 2015, la comunidad de Bitcoin ha tenido desacuerdos sobre la expansión, donde una parte apoya la ampliación del bloque, mientras que la otra apoya el uso de la propuesta Segwit de testigos segregados en bloques más pequeños. El 1 de agosto de 2017, el grupo de expansión desarrolló 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 dio origen a la nueva criptomoneda BCH.
La red de Ethereum también optó por sacrificar parte de la escalabilidad para garantizar la seguridad y la descentralización de la red. Aunque la red de Ethereum no limita la cantidad de transacciones como lo hace la red de Bitcoin al restringir el tamaño de los bloques, sino que de manera indirecta establece un límite en las tarifas de combustible que puede contener un solo bloque, el objetivo sigue siendo lograr un consenso sin confianza y asegurar una amplia distribución de nodos.
Desde CryptoKitties en 2017, el verano DeFi, hasta la posterior aparición de GameFi y NFT, la demanda de rendimiento en el mercado 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 constante en los costos de transacción, tiempos de liquidación más largos y ha dificultado que la mayoría de las Dapps soporten sus costos operativos. En general, la red se ha vuelto lenta y cara para los usuarios, y el problema de la escalabilidad de blockchain necesita ser resuelto urgentemente. La solución de escalabilidad ideal es: aumentar la velocidad de transacción y el rendimiento de la red blockchain tanto como sea posible, sin sacrificar la descentralización y la seguridad.
2. Categorías de soluciones de escalabilidad
Dividimos los planes de expansión en dos grandes categorías: expansión en cadena y expansión off-chain, basándonos en el estándar "si se cambia una capa de la red principal".
2.1 Expansión en cadena
Concepto clave: solución para lograr la escalabilidad mediante el cambio de una capa del protocolo de la red principal, siendo la principal solución actual el sharding.
La escalabilidad en cadena tiene varias soluciones, este artículo no se desarrollará, solo enumeraré brevemente dos soluciones:
La opción uno es ampliar el espacio del bloque, es decir, aumentar la cantidad de transacciones empaquetadas en cada bloque, pero esto aumentará 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 el registro, sino que diferentes fragmentos, es decir, diferentes nodos son responsables de diferentes registros. El cálculo en paralelo puede manejar múltiples transacciones al mismo tiempo; esto puede reducir la presión de cálculo en los nodos y las barreras de entrada, aumentando 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 disminuirá la "seguridad" de toda la red.
Cambiar el código del protocolo de la capa principal de la red puede tener efectos negativos impredecibles, ya que cualquier pequeño fallo de seguridad en la base puede amenazar gravemente la seguridad de toda la red, que puede verse obligada a realizar un fork o interrumpir una actualización de reparación. Por ejemplo, el incidente de la vulnerabilidad de inflación de Zcash en 2018: el código de Zcash se basa en la modificación del código de la versión 0.11.2 de Bitcoin, y en 2018 un ingeniero descubrió que había una vulnerabilidad crítica en el código subyacente, es decir, que los tokens podían ser emitidos sin límite, y el equipo pasó 8 meses realizando reparaciones 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 modifica el protocolo de la mainnet de capa uno existente.
Las soluciones de escalado off-chain se pueden dividir en Layer2 y otras soluciones:
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 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, además de permitir que el número de transacciones no esté limitado.
El canal de estado es un protocolo P2P simple, adecuado para "aplicaciones basadas en turnos", como el juego de ajedrez entre dos personas. Cada canal es gestionado por un contrato inteligente multi-firma que opera en la red principal, que controla los activos depositados en el canal, verifica las actualizaciones de estado y arbitra disputas entre los participantes ( según las pruebas de fraude con firma y sello de tiempo ). Después de que los participantes desplieguen el contrato en la red blockchain, depositan una cantidad de dinero y la bloquean; una vez que ambas partes firman y confirman, el canal se abre oficialmente. El canal permite transacciones gratuitas ilimitadas off-chain ( entre los participantes, siempre que el valor neto de sus transferencias no supere el total de tokens depositados ). Los participantes se turnan para enviar actualizaciones de estado a la otra parte, esperando la confirmación de la firma de la otra parte. Una vez que la otra parte confirma con su firma, esta actualización de estado se considera completada. Normalmente, las actualizaciones de estado acordadas por ambas partes no se suben a la red principal, y solo se dependen de la confirmación de la red principal en caso de disputas o al cerrar el canal. Cuando se necesita cerrar el canal, cualquiera de los participantes puede presentar una solicitud de transacción en la red 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 bloqueados restantes según los saldos de cada participante en el estado final del canal; si otros participantes no aprueban la firma, todos deben 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.
3.1.2 Línea de tiempo
2015/02, Joseph Poon y Thaddeus Dryja publicaron el borrador del libro blanco de la red Lightning.
En noviembre de 2015, Jeff Coleman resumió sistemáticamente el concepto de State Channel, proponiendo que el Payment Channel de Bitcoin es un subcaso dentro 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 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.
2018/06, Counterfactual propuso un diseño de Canales de Estado Generalizados muy detallado, que es el primer diseño completamente relacionado con canales de estado.
2018/10, el artículo Generalised State Channel Networks propone 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 construido sobre esta idea.
2019/10, Pisa para abordar 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 tradicional en la cadena: Alice y Bob interactúan con contratos inteligentes desplegados en la red principal, y los usuarios cambian el estado del contrato inteligente enviando transacciones a la cadena. La desventaja es que conlleva los problemas de tiempo y costo discutidos anteriormente.
![Informe de investigación de profundidad de 10,000 caracteres: 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 siguen la mayoría de los protocolos de canales de estado: en un caso optimista, Alice y Bob necesitan realizar 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 desde su EOA personal a la dirección del contrato en cadena ), 1,2(, estos fondos quedan bloqueados en el contrato hasta que se cierre el canal, momento en el cual se devuelve el saldo al usuario; después de que ambos firmen y confirmen, el canal de estado entre ellos se abre oficialmente.
En el segundo paso, Alice y Bob pueden llevar a cabo un número ilimitado de transacciones off-chain a través de este canal ) línea azul discontinua (, los participantes se comunican entre sí a través de mensajes firmados criptográficamente ) 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.
El tercer paso, si Alice quiere cerrar el canal y finalizar la transacción con Bob, Alice necesita enviar el estado final de su cuenta ) interacción 3( 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 ) interacción 4,5(. Si Bob no responde con 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 de profundidad de diez mil palabras: Análisis completo de la expansión 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, los dos participantes depositan fondos ) interacción 1, 2(, y luego comienzan a intercambiar actualizaciones de estado ) línea azul discontinua (. 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 presentar su último estado válido al contrato ) interacción 4(, y este estado válido también contiene la firma anterior de Bob, lo que demuestra que la última transacción 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 mediante la presentación del siguiente estado al contrato; si Bob responde, ambos pueden continuar realizando transacciones en el canal de estado; si Bob no responde dentro de ese período de tiempo, 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:
Determinación instantánea
Tarifas muy bajas
Buena privacidad
Alta escalabilidad
Alta flexibilidad
Desventajas:
Se requiere que todas las partes participantes estén en línea de forma continua.
No es adecuado para cálculos complejos
El costo inicial de establecer un canal es alto
Escasa escalabilidad
Necesita depositar fondos bloqueados
3.1.5 Aplicación
Red Lightning de Bitcoin
Resumen:
La red Lightning es un canal de pagos de bajo valor dentro de la red de Bitcoin, cuya evolución técnica general ha pasado por: construir un canal de pago unidireccional con 2/2 multiclave, luego, tras agregar RSMC###Revocable Sequence Maturity Contract(, se puede construir un canal de pago bidireccional; después, al añadir HTLC)Hash Time Lock Contract(, se puede expandir el canal de pago a pagos entre múltiples partes, finalmente construyendo la red de pagos, es decir, 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 de Bitcoin. El uso general de la red Lightning sigue el proceso "depósito)establecer canal(→transacción de la red Lightning)actualizar el estado del canal(→reembolso/liquidación)finalizar 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;
En enero de 2016, se publicó la versión oficial del libro blanco 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 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.
8 me gusta
Recompensa
8
5
Compartir
Comentar
0/400
SandwichTrader
· Hace46m
No entendí nada de la primera capa, ¡expansión, jaja, qué tontería!
Ver originalesResponder0
PumpStrategist
· 07-27 12:11
Otra vez la misma trampa Unholy Trinity. En el aspecto técnico, aún no hay avances.
Ver originalesResponder0
fork_in_the_road
· 07-27 12:04
Aún están trabajando en la expansión.
Ver originalesResponder0
TokenTaxonomist
· 07-27 12:04
estadísticamente hablando, el 99.7% de las soluciones de escalado fracasan en la optimización del trilema...
Ver originalesResponder0
Anon32942
· 07-27 11:54
Habló durante medio día y al final es solo un triángulo.
Análisis profundo de las soluciones de escalado off-chain: State Channels y la Lightning Network de Bitcoin
Profundidad de análisis de la escalabilidad off-chain
Autor: Cobo Ventures
1. La necesidad de la ampliació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 mejorar 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. Cuantos más nodos haya, mayor será el grado de descentralización, asegurando que la red no esté controlada por unos pocos grandes participantes centralizados.
Seguridad: Cuanto mayor sea el costo para obtener el control del sistema blockchain, mayor será la seguridad, y 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 de Bitcoin surgió de un problema de escalabilidad. A medida que aumentaban el número de usuarios y el volumen de transacciones, la red de Bitcoin, con un límite de 1 MB por bloque, comenzó a enfrentar problemas de congestión; desde 2015, la comunidad de Bitcoin ha tenido desacuerdos sobre la expansión, donde una parte apoya la ampliación del bloque, mientras que la otra apoya el uso de la propuesta Segwit de testigos segregados en bloques más pequeños. El 1 de agosto de 2017, el grupo de expansión desarrolló 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 dio origen a la nueva criptomoneda BCH.
La red de Ethereum también optó por sacrificar parte de la escalabilidad para garantizar la seguridad y la descentralización de la red. Aunque la red de Ethereum no limita la cantidad de transacciones como lo hace la red de Bitcoin al restringir el tamaño de los bloques, sino que de manera indirecta establece un límite en las tarifas de combustible que puede contener un solo bloque, el objetivo sigue siendo lograr un consenso sin confianza y asegurar una amplia distribución de nodos.
Desde CryptoKitties en 2017, el verano DeFi, hasta la posterior aparición de GameFi y NFT, la demanda de rendimiento en el mercado 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 constante en los costos de transacción, tiempos de liquidación más largos y ha dificultado que la mayoría de las Dapps soporten sus costos operativos. En general, la red se ha vuelto lenta y cara para los usuarios, y el problema de la escalabilidad de blockchain necesita ser resuelto urgentemente. La solución de escalabilidad ideal es: aumentar la velocidad de transacción y el rendimiento de la red blockchain tanto como sea posible, sin sacrificar la descentralización y la seguridad.
2. Categorías de soluciones de escalabilidad
Dividimos los planes de expansión en dos grandes categorías: expansión en cadena y expansión off-chain, basándonos en el estándar "si se cambia una capa de la red principal".
2.1 Expansión en cadena
Concepto clave: solución para lograr la escalabilidad mediante el cambio de una capa del protocolo de la red principal, siendo la principal solución actual el sharding.
La escalabilidad en cadena tiene varias soluciones, este artículo no se desarrollará, solo enumeraré brevemente dos soluciones:
La opción uno es ampliar el espacio del bloque, es decir, aumentar la cantidad de transacciones empaquetadas en cada bloque, pero esto aumentará 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 el registro, sino que diferentes fragmentos, es decir, diferentes nodos son responsables de diferentes registros. El cálculo en paralelo puede manejar múltiples transacciones al mismo tiempo; esto puede reducir la presión de cálculo en los nodos y las barreras de entrada, aumentando 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 disminuirá la "seguridad" de toda la red.
Cambiar el código del protocolo de la capa principal de la red puede tener efectos negativos impredecibles, ya que cualquier pequeño fallo de seguridad en la base puede amenazar gravemente la seguridad de toda la red, que puede verse obligada a realizar un fork o interrumpir una actualización de reparación. Por ejemplo, el incidente de la vulnerabilidad de inflación de Zcash en 2018: el código de Zcash se basa en la modificación del código de la versión 0.11.2 de Bitcoin, y en 2018 un ingeniero descubrió que había una vulnerabilidad crítica en el código subyacente, es decir, que los tokens podían ser emitidos sin límite, y el equipo pasó 8 meses realizando reparaciones 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 modifica el protocolo de la mainnet de capa uno existente.
Las soluciones de escalado off-chain se pueden dividir en Layer2 y otras soluciones:
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 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, además de permitir que el número de transacciones no esté limitado.
El canal de estado es un protocolo P2P simple, adecuado para "aplicaciones basadas en turnos", como el juego de ajedrez entre dos personas. Cada canal es gestionado por un contrato inteligente multi-firma que opera en la red principal, que controla los activos depositados en el canal, verifica las actualizaciones de estado y arbitra disputas entre los participantes ( según las pruebas de fraude con firma y sello de tiempo ). Después de que los participantes desplieguen el contrato en la red blockchain, depositan una cantidad de dinero y la bloquean; una vez que ambas partes firman y confirman, el canal se abre oficialmente. El canal permite transacciones gratuitas ilimitadas off-chain ( entre los participantes, siempre que el valor neto de sus transferencias no supere el total de tokens depositados ). Los participantes se turnan para enviar actualizaciones de estado a la otra parte, esperando la confirmación de la firma de la otra parte. Una vez que la otra parte confirma con su firma, esta actualización de estado se considera completada. Normalmente, las actualizaciones de estado acordadas por ambas partes no se suben a la red principal, y solo se dependen de la confirmación de la red principal en caso de disputas o al cerrar el canal. Cuando se necesita cerrar el canal, cualquiera de los participantes puede presentar una solicitud de transacción en la red 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 bloqueados restantes según los saldos de cada participante en el estado final del canal; si otros participantes no aprueban la firma, todos deben 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.
3.1.2 Línea de tiempo
2015/02, Joseph Poon y Thaddeus Dryja publicaron el borrador del libro blanco de la red Lightning.
En noviembre de 2015, Jeff Coleman resumió sistemáticamente el concepto de State Channel, proponiendo que el Payment Channel de Bitcoin es un subcaso dentro 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 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.
2018/06, Counterfactual propuso un diseño de Canales de Estado Generalizados muy detallado, que es el primer diseño completamente relacionado con canales de estado.
2018/10, el artículo Generalised State Channel Networks propone 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 construido sobre esta idea.
2019/10, Pisa para abordar 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 tradicional en la cadena: Alice y Bob interactúan con contratos inteligentes desplegados en la red principal, y los usuarios cambian el estado del contrato inteligente enviando transacciones a la cadena. La desventaja es que conlleva los problemas de tiempo y costo discutidos anteriormente.
![Informe de investigación de profundidad de 10,000 caracteres: 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 siguen la mayoría de los protocolos de canales de estado: en un caso optimista, Alice y Bob necesitan realizar 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 desde su EOA personal a la dirección del contrato en cadena ), 1,2(, estos fondos quedan bloqueados en el contrato hasta que se cierre el canal, momento en el cual se devuelve el saldo al usuario; después de que ambos firmen y confirmen, el canal de estado entre ellos se abre oficialmente.
En el segundo paso, Alice y Bob pueden llevar a cabo un número ilimitado de transacciones off-chain a través de este canal ) línea azul discontinua (, los participantes se comunican entre sí a través de mensajes firmados criptográficamente ) 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.
El tercer paso, si Alice quiere cerrar el canal y finalizar la transacción con Bob, Alice necesita enviar el estado final de su cuenta ) interacción 3( 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 ) interacción 4,5(. Si Bob no responde con 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 de profundidad de diez mil palabras: Análisis completo de la expansión 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, los dos participantes depositan fondos ) interacción 1, 2(, y luego comienzan a intercambiar actualizaciones de estado ) línea azul discontinua (. 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 presentar su último estado válido al contrato ) interacción 4(, y este estado válido también contiene la firma anterior de Bob, lo que demuestra que la última transacción 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 mediante la presentación del siguiente estado al contrato; si Bob responde, ambos pueden continuar realizando transacciones en el canal de estado; si Bob no responde dentro de ese período de tiempo, 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 dentro de la red de Bitcoin, cuya evolución técnica general ha pasado por: construir un canal de pago unidireccional con 2/2 multiclave, luego, tras agregar RSMC###Revocable Sequence Maturity Contract(, se puede construir un canal de pago bidireccional; después, al añadir HTLC)Hash Time Lock Contract(, se puede expandir el canal de pago a pagos entre múltiples partes, finalmente construyendo la red de pagos, es decir, 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 de Bitcoin. El uso general de la red Lightning sigue el proceso "depósito)establecer canal(→transacción de la red Lightning)actualizar el estado del canal(→reembolso/liquidación)finalizar canal("; teóricamente, la red Lightning puede procesar un millón de transacciones por segundo.
Línea de tiempo: