- Tema
25k Popularidad
26k Popularidad
6k Popularidad
16k Popularidad
30k Popularidad
742 Popularidad
95k Popularidad
27k Popularidad
26k Popularidad
7k Popularidad
- Anclado
25k Popularidad
26k Popularidad
6k Popularidad
16k Popularidad
30k Popularidad
742 Popularidad
95k Popularidad
27k Popularidad
26k Popularidad
7k Popularidad
Análisis completo de las soluciones de escalado off-chain: estado del canal, Lighting Network y su desarrollo.
Profundidad del análisis de la expansión off-chain
Autor: Ellaine Xu, Hettie Jiang, June Wang, Walon Lin, Yiliu Lin
1. La necesidad de la escalabilidad
La visión futura de la blockchain es la descentralización, la seguridad y la escalabilidad. Pero generalmente la blockchain solo puede 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 la capacidad de la blockchain y la velocidad de las transacciones, garantizando al mismo tiempo la descentralización y la seguridad, es decir, resolver el problema de escalabilidad, que es uno de los temas candentes en el proceso de desarrollo actual de la blockchain.
Definamos primero la descentralización, la seguridad y la escalabilidad de la cadena de bloques:
Descentralización: cualquier persona puede convertirse en un nodo para participar en el sistema de blockchain, cuantos más nodos haya, mayor será el grado de descentralización, asegurando que la red no esté controlada por unos pocos participantes.
Seguridad: Cuanto mayor sea el costo de obtener el control del sistema blockchain, mayor será la seguridad, y la cadena podrá resistir ataques de una proporción mayor 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 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 bloque de 1 MB comenzó a enfrentar congestión. Desde 2015, la comunidad de Bitcoin ha tenido desacuerdos sobre el problema de escalabilidad; por un lado, algunos apoyan la expansión del bloque, mientras que otros apoyan el uso de Segwit para optimizar la estructura de la cadena principal. El 1 de agosto de 2017, el grupo que apoyaba bloques grandes desarrolló un sistema de cliente de 8 MB que comenzó a funcionar, lo que llevó a la primera bifurcación dura significativa de Bitcoin y al nacimiento de la nueva criptomoneda BCH.
De igual manera, la red de Ethereum también sacrificó parte de la escalabilidad para garantizar la seguridad y descentralización de la red, limitando el volumen de transacciones mediante la fijación de un límite en las tarifas de combustible que se pueden incluir en un solo bloque. El objetivo es lograr un consenso sin confianza y asegurar una amplia distribución de nodos.
Desde CryptoKitties en 2017, el verano de DeFi, hasta el surgimiento posterior de aplicaciones en cadena como GameFi y NFT, la demanda del mercado por capacidad de procesamiento ha ido en aumento, pero Ethereum solo puede manejar de 15 a 45 transacciones por segundo. Esto ha llevado a un aumento en los costos de transacción, tiempos de liquidación más largos y la mayoría de las DApps tienen dificultades para soportar los costos operativos, haciendo que toda la red sea lenta y cara para los usuarios, lo que requiere una solución urgente al problema de escalabilidad de la blockchain. La solución de escalabilidad ideal es aumentar la velocidad y la capacidad de transacción de la red blockchain tanto como sea posible, sin sacrificar la descentralización y la seguridad.
2. Tipos de soluciones de escalabilidad
Nosotros clasificamos las soluciones de escalabilidad en dos grandes categorías: escalabilidad en cadena y escalabilidad off-chain, basándonos en el criterio de "si se cambia una capa de la mainnet".
2.1 Expansión en cadena
Concepto clave: solución para lograr un efecto de escalabilidad mediante el cambio de una capa del protocolo de la red principal, la solución principal actual es el sharding.
La escalabilidad en cadena tiene varias soluciones, este artículo no se desarrollará, solo se enumerarán brevemente dos:
La opción uno es ampliar 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 disminuirá 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 shards son responsables de diferentes registros, y el cálculo en paralelo puede manejar múltiples transacciones simultáneamente. Esto puede reducir la presión de cálculo en los nodos y el umbral de entrada, aumentar la velocidad de procesamiento de transacciones y el grado de descentralización, pero también disminuirá la "seguridad" de toda la red.
Cambiar un protocolo de la red principal puede tener efectos negativos impredecibles, ya que cualquier pequeño defecto de seguridad en la capa subyacente puede amenazar gravemente la seguridad de toda la red. Por ejemplo, el incidente de vulnerabilidad de inflación de Zcash en 2018: la base de código de Zcash se modificó a partir de la versión 0.11.2 de Bitcoin, y en 2018 se descubrió que su código subyacente tenía una vulnerabilidad crítica que permitía la emisión ilimitada de tokens, el equipo pasó 8 meses realizando reparaciones en secreto y solo después de solucionar el problema se hizo pública esta situación.
2.2 off-chain expansión
Concepto clave: solución de escalabilidad que no modifica el protocolo de la red principal de primera capa existente.
Las soluciones de escalado off-chain se pueden dividir en Layer2 y otras soluciones:
3. Soluciones de escalabilidad off-chain
3.1 Canales Estatales
3.1.1 Resumen
El canal de estado establece que solo cuando el canal está abierto, cerrado o se resuelven disputas, los usuarios necesitan interactuar con la cadena principal, y las interacciones entre los usuarios se llevan a cabo off-chain, para reducir el tiempo y el costo monetario 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 juegos de ajedrez entre dos personas. Cada canal es gestionado por un contrato inteligente multi-firma que opera 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 ( según las pruebas de fraude firmadas y con sello de tiempo ). Después de que los participantes despliegan el contrato en la red de blockchain, depositan fondos y los bloquean, y una vez que ambas partes firman y confirman, el canal se abre oficialmente. El canal permite transacciones ilimitadas y gratuitas off-chain entre los participantes ( siempre que su valor neto de 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 contrario. Una vez que el otro firma y confirma, 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 se dependerá de la confirmación de la cadena principal en caso de disputas o al cerrar el canal. 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 todas las firmas, 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 firman su 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 en gran medida la carga computacional de la red 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 publicaron un borrador del libro blanco de la red Lightning.
En noviembre de 2015, Jeff Coleman resumió sistemáticamente el concepto de State Channel por primera vez, proponiendo que el Payment Channel de Bitcoin es un subcaso del concepto de State Channel.
2016/01, Joseph Poon y Thaddeus Dryja publicaron oficialmente el documento técnico "The Bitcoin Lightning Network: Scalable Off-Chain Instant Payments" proponiendo una solución de escalabilidad para la red Lightning de Bitcoin, Payment Channel (, que se utiliza exclusivamente para procesar los pagos de transferencias en la red de Bitcoin.
En noviembre de 2017, se propusieron las especificaciones de diseño de State Channel bajo el marco de Payment Channel, conocido como Sprites.
2018/06, Counterfactual propuso un diseño de Canales de Estado Generalizados muy detallado, este es el primer diseño completamente relacionado con los 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 amplió a N-Party Channels, Nitro es el primer protocolo construido sobre esta idea.
2019/10, Pisa amplió el concepto de Watchtowers para resolver el problema de que todos los participantes necesitan estar en línea continuamente.
2020/03, Hydra propuso Canales Isomórficos Rápidos.
)# 3.1.3 Principio técnico
La figura 1 muestra el flujo de trabajo tradicional en la 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 presenta los problemas de tiempo y costo discutidos anteriormente.
![Informe de investigación en profundidad: Análisis completo de la expansión off-chain]###https://img-cdn.gateio.im/webp-social/moments-087d35594a04d33375b8199b93eb355e.webp(
La figura 2 muestra el flujo de trabajo general que la mayoría de los protocolos de canales de estado siguen: en un escenario 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 se bloquean en el contrato, y el saldo se devuelve al usuario solo cuando se cierra el canal; después de que ambas partes confirmen con su firma, el canal de estado entre ellos se abre oficialmente.
En el segundo paso, Alice y Bob pueden realizar un número ilimitado de transacciones off-chain a través de este canal teóricamente ) línea azul discontinua (, los participantes se comunican entre sí mediante mensajes firmados criptográficamente ) en lugar de comunicarse con la red de blockchain (. Ambos usuarios deben firmar cada transacción para evitar el doble gasto malintencionado. 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 ) interacción 3( al contrato, si Bob firma y aprueba, el contrato liberará los fondos bloqueados de acuerdo al estado final y los devolverá al usuario correspondiente ) interacción 4,5(. Si Bob no responde a la firma, el contrato liberará los fondos bloqueados y los devolverá al usuario correspondiente una vez finalizado el 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(
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 discontinua azul (. Supongamos que en algún momento, Bob no responde a la firma de actualización de estado enviada por Alice en su turno ) interacción 3(, en este momento, Alice puede iniciar un desafío al presentar 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 ya ha sido aprobada por Bob, y el estado final ha sido confirmado por Bob. Luego, el contrato permite a Bob responder dentro de un período de tiempo presentando el 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, 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-ad088ac016d75b1ae0b0eda699e74709.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 técnica general ha pasado por: construcción de un canal de pago unidireccional mediante 2/2 firmas múltiples, aumentando RSMC###Revocable Sequence Maturity Contract( para construir un canal de pago bidireccional, luego, aumentando HTLC)Hash Time Lock Contract(, se puede conectar el canal de pago para extenderlo a pagos entre múltiples personas, construyendo finalmente 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 de "depósito)establecer canal(→transacción de la red Lightning)actualizar 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: