《off-chain Profundidad解析》

Autor: equipo de investigación

1. La necesidad de la expansión

El futuro de la blockchain es una visión grandiosa: descentralización, seguridad y escalabilidad; pero generalmente la blockchain solo puede lograr dos de estos, y satisfacer los 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 la descentralización y la seguridad, es decir, resolver el problema de la escalabilidad, que es uno de los temas candentes en el 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; cuanto mayor sea el número de nodos, 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, lo que permitirá que la cadena resista ataques de una mayor proporción 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ó del problema de escalabilidad. A medida que aumentaba el número de usuarios y el volumen de transacciones de Bitcoin, 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. Por un lado, están los partidarios de la ampliación del bloque, representados por Bitcoin ABC, y por el otro, el grupo de bloques pequeños, representado por Bitcoin Core, que cree que se debe optimizar la estructura de la cadena principal utilizando la solución de testigos separados (Segwit). El 1 de agosto de 2017, Bitcoin ABC lanzó un sistema cliente desarrollado por sí mismo de 8MB, lo que dio lugar a la primera bifurcación dura significativa en la historia de Bitcoin y, por lo tanto, al nacimiento de la nueva criptomoneda BCH.

De manera similar, la red de Ethereum también ha optado 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 el volumen de transacciones como lo hace la red de Bitcoin al restringir el tamaño de los bloques, sino que ha cambiado de manera indirecta a establecer un límite en la tarifa de combustible que puede acomodar un solo bloque, el propósito sigue siendo lograr un Consenso Sin Confianza y garantizar una amplia distribución de nodos. ( Ya sea que se elimine o se aumente el límite, se eliminarán muchos nodos más pequeños que carecen de ancho de banda, almacenamiento y capacidad de cálculo suficientes. ).

Desde CryptoKitties en 2017, el verano de DeFi, hasta el auge posterior de aplicaciones en cadena como GameFi y NFT, la demanda del mercado por capacidad de procesamiento ha aumentado constantemente. Sin embargo, incluso Ethereum, que es Turing-completo, solo puede manejar de 15 a 45 transacciones por segundo ( TPS ), lo que ha resultado en un aumento continuo de los costos de transacción, un tiempo de liquidación más largo y la mayoría de las Dapps enfrentando costos operativos insostenibles. 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 con urgencia. La solución de escalabilidad ideal es: aumentar la velocidad de transacción 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

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 cambia una capa de la red principal".

2.1 Expansión en cadena

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

La escalabilidad en 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 reducirá el grado de "descentralización".
• La opción dos es el sharding, que divide el libro de contabilidad de la blockchain en varias partes, en lugar de que cada nodo participe en todos los registros, diferentes shards, es decir, diferentes nodos son responsables de diferentes registros, y el cálculo en paralelo puede procesar múltiples transacciones simultáneamente; esto puede reducir la presión computacional en los nodos y el umbral de entrada, mejorando 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 reducirá la "seguridad" de toda la red.

Cambiar el código del protocolo principal de la red puede tener efectos negativos impredecibles, ya que cualquier pequeño fallo de seguridad en la base puede amenazar seriamente la seguridad de toda la red; la red podría verse obligada a bifurcarse o a interrumpir la 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 modificaciones del código de Bitcoin versión 0.11.2, 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 emitirse ilimitadamente; 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 clave: solución de escalamiento que no altera el protocolo de la red principal de capa uno existente.

Las soluciones de escalabilidad off-chain se pueden subdividir en Layer2 y otras soluciones:

3. Profundidad de la solución de escalado off-chain

3.1 Canales de Estado

3.1.1 Resumen

Los canales de estado establecen que los usuarios solo necesitan interactuar con la red principal al abrir, cerrar o resolver disputas en el canal, 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 tenga restricciones.

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 las disputas entre los participantes ( según pruebas de fraude firmadas y con sello de tiempo ). Después de que los participantes desplieguen el contrato en la red de blockchain, depositan una cantidad de dinero y lo 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 exceda el total de tokens depositados ). Los participantes se turnan para enviar actualizaciones de estado al otro, esperando la confirmación de la firma del otro. Una vez que la otra parte confirma la 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, solo se dependerá de la confirmación de la cadena principal en caso de disputas o cuando se cierra el canal. Cuando se necesita cerrar el canal, cualquiera de los participantes puede presentar una solicitud de transacción en la cadena principal; si la solicitud de salida obtiene la aprobación unánime de las firmas, 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 han aprobado 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 red principal, aumentar la velocidad de las transacciones y reducir 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" que propone el esquema de escalabilidad 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 primera especificación de diseño de State Channel basada en 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 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 expandió a los 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 continuamente en línea.
• 2020/03, Hydra propuso Canales Isomórficos Rápidos.

)# 3.1.3 Principios técnicos

La Figura 1 muestra el flujo de trabajo en una 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 conlleva 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 el caso optimista, Alice y Bob necesitan realizar las mismas operaciones 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 hasta que se cierre el canal y el saldo se devuelve al usuario; después de la firma de confirmación, el canal de estado entre los dos 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í mediante mensajes firmados criptográficamente ) en lugar de comunicarse con la red blockchain (. Ambos usuarios deben firmar cada transacción para prevenir el doble gasto malicioso. A través de estos mensajes, proponen actualizaciones de estado de sus cuentas y aceptan las actualizaciones de estado propuestas por el otro.
• Tercer paso, si Alice quiere cerrar el canal y terminar la transacción con Bob, Alice necesita presentar el estado final de su cuenta ) a el contrato interactuando 3(, si Bob firma y aprueba, el contrato liberará los fondos bloqueados de acuerdo al estado final y los devolverá al usuario correspondiente ) interactuando 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 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 discontinua azul (. Supongamos que en algún momento, Bob no responde a la actualización de estado firmada que Alice envió en su turno ) interacción 3(, en este punto, Alice puede iniciar un desafío ) interacción 4( al presentar su última actualización de estado válida al contrato, que también incluye la firma anterior de Bob, demostrando así que la última transacción ya 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 presentando el siguiente estado al contrato; si Bob responde, ambos pueden continuar realizando transacciones dentro del 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 de profundidad de 10,000 palabras: 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:

• La inmediatez de las transacciones es alta, adecuada para pagos pequeños de alta frecuencia.
• Tarifas de transacción bajas
• Alta privacidad, las transacciones off-chain no se hacen públicas
• Alta escalabilidad, teóricamente TPS ilimitados

Desventajas:

• Se necesita bloquear fondos
• Se necesita confirmación en cadena cuando el canal está cerrado.
• Los participantes deben permanecer en línea
• No es adecuado para transacciones de gran volumen o baja frecuencia
• Hay riesgo de robo de fondos

3.1.5 Aplicación

Red Lightning de Bitcoin

Resumen:

La red Lightning es un canal de pagos de bajo valor de la red 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 el RSMC###Revocable Sequence Maturity Contract( se puede construir un canal de pago bidireccional, luego se agrega.