Análisis profundo de la expansión off-chain

Autor: Ellaine Xu, Hettie Jiang, June Wang, Walon Lin, Yiliu Lin

1. La necesidad de la expansión

El futuro de la blockchain es una visión grandiosa: descentralización, seguridad y escalabilidad; pero a menudo la blockchain solo puede lograr dos de ellas, y satisfacer estos tres requisitos 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 al mismo tiempo 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.

Definamos primero de manera general la descentralización, la seguridad y la escalabilidad de la blockchain:

• Descentralización: cualquier persona puede convertirse en un nodo para participar en la producción y verificación del sistema de blockchain, cuántos más nodos haya, mayor será el grado de descentralización, asegurando así que la red no esté controlada por un pequeño grupo de grandes participantes centralizados.
• Seguridad: Cuanto mayor sea el costo para obtener el control del sistema de blockchain, mayor será la seguridad, por lo que la cadena puede resistir ataques de una mayor proporción de participantes.
• Escalabilidad: la capacidad de la blockchain para procesar grandes volúmenes de transacciones.

El primer hard fork significativo en la red de Bitcoin surgió debido a problemas de escalabilidad. A medida que aumentaba el número de usuarios y el volumen de transacciones de Bitcoin, la red de 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. Por un lado, están los partidarios de la ampliación del bloque, representados por Bitcoin ABC, y por otro lado, están los partidarios de bloques pequeños, representados por Bitcoin Core, quienes creen que se debe utilizar la solución de Segregated Witness (Segwit) para optimizar la estructura de la cadena principal. El 1 de agosto de 2017, Bitcoin ABC lanzó un sistema cliente desarrollado por sí mismo de 8MB, lo que provocó la primera bifurcación dura significativa en la historia de Bitcoin, y de esta manera nació la nueva criptomoneda BCH.

De manera similar, la red de Ethereum también optó por sacrificar una parte de la escalabilidad para garantizar la seguridad y la descentralización de la red; aunque la red de Ethereum no limita la cantidad de transacciones al restringir el tamaño de los bloques como lo hace la red de Bitcoin, sino que en su lugar establece un límite en las tarifas de combustible que puede contener un solo bloque, el objetivo es lograr un Consenso Sin Confianza y asegurar una amplia distribución de nodos. Tanto si se eliminan como si se aumentan los límites, se eliminarán muchos nodos más pequeños que no tienen suficiente ancho de banda, almacenamiento y capacidad de cálculo.

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 la capacidad de procesamiento ha ido en aumento. Sin embargo, incluso Ethereum, que es Turing completo, solo puede procesar de 15 a 45 transacciones por segundo ( TPS ). Como resultado, los costos de transacción han ido en aumento, el tiempo de liquidación se ha alargado, y la mayoría de las Dapps tienen dificultades para soportar los costos operativos. La red en su conjunto 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 de las transacciones de la red blockchain ( un tiempo de finalización ) más corto y un mayor volumen de transacciones ( TPS ), sin sacrificar la descentralización y la seguridad.

2. Tipos de soluciones de escalabilidad

Dividimos los planes de escalabilidad en dos categorías principales: escalabilidad en cadena y escalabilidad off-chain, basándonos en el criterio de "si cambia una capa de la red principal".

2.1 Expansión en cadena

Concepto clave: solución para lograr efectos de escalabilidad al modificar una capa del protocolo de la red principal, la solución principal actualmente es el sharding.

La expansión en la cadena tiene varias soluciones, este artículo no se desarrollará, a continuación se enumeran 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 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, no siendo cada nodo responsable de todas las transacciones, sino que diferentes fragmentos y diferentes nodos se encargan de distintas transacciones. El cálculo en paralelo puede manejar múltiples transacciones al mismo tiempo; esto puede reducir la presión de cálculo de los nodos y el umbral de entrada, aumentando la velocidad de procesamiento de transacciones y el grado de descentralización; pero esto significa que la capacidad de cálculo de toda la red se dispersa, lo que disminuirá la "seguridad" de toda la red.

Modificar el código del protocolo de la cadena principal 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, lo que puede obligar a la red a bifurcarse o interrumpir las actualizaciones de reparación. Por ejemplo, el incidente de 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, en 2018 un ingeniero descubrió una vulnerabilidad crítica en el código subyacente, es decir, que los tokens podían emitirse de forma ilimitada, y el equipo pasó 8 meses realizando reparaciones secretas, solo después de corregir la vulnerabilidad se hizo público este incidente.

2.2 Expansión off-chain

Concepto clave: solución de escalado que no altera el protocolo de la mainnet de primera capa existente.

La solución de escalado off-chain se puede dividir en Layer2 y otras soluciones:

3. Profundidad de la solución de escalado 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 se abre, se cierra o se resuelve un conflicto, 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, y 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 un juego de ajedrez entre dos personas. Cada canal es gestionado por un contrato inteligente multifirma 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 ) basándose en pruebas de fraude ### que incluyen firmas y sellos 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 el valor neto de sus transferencias no supere el total de tokens depositados ). Los participantes envían actualizaciones de estado a la otra parte por turnos, 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 cadena principal, y solo se dependen 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 hacer una solicitud de transacción en la cadena principal; si la solicitud de salida obtiene la aprobación de firma unánime, se ejecuta inmediatamente en la cadena, es decir, el contrato inteligente distribuye los fondos bloqueados restantes según el saldo de cada participante en el estado final del canal; si otros participantes no aprueban con su firma, todos deben esperar a que termine el "periodo de desafío" para recibir los fondos restantes.

En resumen, la solución de canal de estado puede reducir significativamente la carga computacional de la cadena principal, mejorar 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.
• 2015/11, Jeff Coleman resumió sistemáticamente el concepto de State Channel por primera vez, proponiendo que el Payment Channel de Bitcoin es un subcaso del concepto de State Channel.
• 2016/01, Joseph Poon y Thaddeus Dryja publicaron oficialmente el libro blanco "The Bitcoin Lightning Network: Scalable Off-Chain Instant Payments" proponiendo el esquema de escalabilidad 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 Sprites, la primera especificación de diseño sobre State Channel basada en el marco de Payment Channel.
• 2018/06, Counterfactual propuso un diseño de Canales de Estado Generalizados muy detallado, este 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 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 de forma continua.
• 2020/03, Hydra propuso Canales Isomórficos Rápidos.

![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-ead28de03be9fc22dcfe3f679ee36bc5.webp(

3.1.3 Principios técnicos

La Figura 1 muestra el flujo de trabajo tradicional en la cadena: Alice y Bob interactúan con un contrato inteligente desplegado en la red principal, los usuarios cambian el estado del contrato inteligente enviando transacciones a la cadena. La desventaja es que esto conlleva problemas de tiempo y costo discutidos anteriormente.

![Informe de investigación profunda: Análisis completo de la expansión off-chain])https://img-cdn.gateio.im/webp-social/moments-ad088ac016d75b1ae0b0eda699e74709.webp(

La Figura 2 muestra el flujo de trabajo general que siguen la mayoría de los protocolos de canal 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 de su EOA personal en la dirección del contrato en cadena ), 1,2(, estos fondos se bloquean en el contrato hasta que se cierra el canal y el saldo se devuelve al usuario; después de que ambos firman la confirmación, el canal de estado entre ellos se abre oficialmente.
• Paso dos, Alice y Bob pueden teóricamente 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 firmados criptográficamente ) en lugar de comunicarse con la red de blockchain (. Ambos usuarios deben firmar cada transacción para prevenir 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 al contrato el estado final de su cuenta ) interacción 3(, 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 a la firma, el contrato liberará los fondos bloqueados y los devolverá al usuario correspondiente después de que termine 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-815c5eb2bdba725e04eebe67b22d42aa.webp(

La figura 3 muestra el flujo de trabajo de un canal de estado en un escenario pesimista: al principio, dos participantes depositan fondos ) en la 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 ) en la interacción 3(; en este momento, Alice puede iniciar un desafío ) en la interacción 4( al presentar su última actualización de estado válida al contrato, la cual también incluye la firma anterior de Bob, demostrando así que la última transacción ya fue aprobada por Bob, y que el estado final ha sido confirmado por Bob. Luego, el contrato permite a Bob responder durante un tiempo determinado 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 plazo, el contrato cierra automáticamente el canal de estado y devuelve los fondos a Alice ) en la 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-010d7309e0cc697da400d07e6948a16e.webp(

3.1.4 Ventajas y desventajas

Ventajas:

• Confirmación de transacciones instantáneas
• Alta capacidad de procesamiento
• Baja tarifa de transacción
• Alta privacidad

Desventajas:

• Se necesita bloquear fondos
• Los usuarios necesitan iniciar sesión con frecuencia
• Complejidad aumentada

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 experimentado: construcción de un canal de pago unidireccional 2/2 con múltiples firmas, aumento de RSMC.