Profundidad de análisis 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 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, la gente ha 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, uno de los temas de discusión más 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 nivel 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, y la cadena podrá resistir ataques de una mayor proporción de participantes.
• Escalabilidad: la capacidad de la blockchain para procesar grandes volúmenes de transacciones.

La primera bifurcación dura significativa de la red Bitcoin se originó a partir 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; a partir de 2015, la comunidad de Bitcoin tuvo discrepancias sobre el problema de escalabilidad, una parte representada por Bitcoin ABC que apoyaba la expansión del bloque, y la otra parte representada por Bitcoin Core, que creía que se debía usar la solución Segwit para optimizar la estructura de la cadena principal. El 1 de agosto de 2017, Bitcoin ABC lanzó un sistema de cliente desarrollado por sí mismo con un tamaño de 8MB, lo que provocó la primera bifurcación dura significativa en la historia de Bitcoin y, por lo tanto, dio origen a una nueva criptomoneda, BCH.

Igualmente, 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 la red de Ethereum no limita el volumen de transacciones al restringir el tamaño de los bloques como lo hace la red de Bitcoin, sino que en cambio establece un límite en la tarifa 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. ( 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ómputo suficientes. ).

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 mayor capacidad de procesamiento 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 resulta en un aumento constante de los costos de transacción, tiempos de liquidación más largos y la mayoría de las Dapps enfrentando dificultades para soportar los costos operativos. En general, la red se ha vuelto lenta y costosa para los usuarios, y el problema de la escalabilidad de blockchain necesita ser resuelto urgentemente. La solución ideal de escalabilidad es: aumentar la velocidad de transacción de la red blockchain ( un tiempo de finalización más corto ) y un mayor rendimiento de transacciones ( TPS ) sin sacrificar la descentralización y la seguridad.

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

2.1 Expansión en la cadena

Concepto clave: solución para lograr un efecto de escalabilidad mediante el cambio de una capa del protocolo de la red principal, la principal propuesta actual es el sharding.

La expansión en cadena tiene varias soluciones, este artículo no se desarrollará, a continuación se enumeran brevemente dos soluciones:

• La opción uno es expandir el espacio del bloque, es decir, aumentar la cantidad de transacciones empaquetadas en cada bloque, pero esto incrementará los requerimientos para dispositivos de nodos de alto rendimiento, elevará la barrera 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 todos los registros, sino que diferentes fragmentos, es decir, diferentes nodos, son responsables de diferentes registros, permitiendo que el procesamiento en paralelo maneje múltiples transacciones simultáneamente; esto puede reducir la presión computacional en los nodos y las barreras de entrada, aumentar 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 podría amenazar gravemente la seguridad de toda la red, lo que podría obligar a la red a realizar una bifurcación 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 una 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, lo que permitía la emisión ilimitada de tokens, 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 Expansión off-chain

Concepto clave: solución de escalado que no altera 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. Profundidad de la solución de escalado 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, y realizar las interacciones entre usuarios off-chain, con el fin de reducir el tiempo y el costo monetario de las transacciones de los usuarios, y permitir 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 opera en la red principal, el cual controla los activos depositados en el canal, valida las actualizaciones de estado y arbitra disputas entre los participantes ( de acuerdo con pruebas de fraude ) que incluyen firmas y sellos de tiempo. Después de que los participantes desplieguen 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 exceda el total de tokens depositados ). Los participantes se turnan para enviar actualizaciones de estado al otro, esperando la confirmación con la firma de la otra parte. Una vez que la otra parte confirma con su firma, la actualización de estado se considera completada. Normalmente, las actualizaciones de estado acordadas por ambas partes no se suben a la red principal; solo se confía en la red principal para su confirmación 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; 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 firman para aprobar, todos deben esperar el final del "período de desafío" para poder recibir los fondos restantes.

En resumen, el esquema de canales de estado puede reducir significativamente la carga computacional en 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 un borrador del libro blanco de la red Lightning.
• 2015/11, Jeff Coleman resumió sistemáticamente por primera vez el concepto de State Channel, 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 un esquema de escalabilidad para la red Lightning de Bitcoin, Payment Channel(, que se utiliza únicamente para procesar pagos de transferencia en la red de Bitcoin.
• Noviembre de 2017, se propuso la primera especificación de diseño sobre 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 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 basado en 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

Flujo de trabajo del canal de estado:

1. Alice y Bob depositan fondos desde su EOA personal a la dirección del contrato en la cadena, estos fondos se bloquean en el contrato hasta que el canal se cierra y el saldo se devuelve al usuario; después de que ambas partes firman para confirmar, el canal de estado entre ellos se abre oficialmente.

2. Alice y Bob pueden realizar transacciones ilimitadas fuera de la cadena a través de este canal, 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 prevenir el fraude de doble gasto. A través de estos mensajes, proponen actualizaciones del estado de sus cuentas y aceptan las actualizaciones de estado propuestas por el otro.

3. Si Alice quiere cerrar el canal y finalizar la transacción con Bob, Alice necesita enviar el estado final de su cuenta al contrato. Si Bob firma y aprueba, el contrato liberará los fondos bloqueados y los devolverá al usuario correspondiente según el estado final. Si Bob no responde con 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.

Flujo de trabajo del canal de estado en un escenario pesimista: Al principio, dos participantes depositan fondos y luego comienzan a intercambiar actualizaciones de estado. Supongamos que en un momento dado, Bob no responde a la firma de actualización de estado enviada por Alice durante su turno; en este momento, Alice puede iniciar un desafío enviando su último estado válido al contrato, que también incluye la firma anterior de Bob, demostrando así que la última transacción ha sido aprobada por Bob y que 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 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.

![Informe de investigación de 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:

• Confirmación instantánea, la transacción se puede completar de inmediato.
• Alta capacidad de procesamiento, teóricamente transacciones infinitas
• Tarifas bajas, solo se necesita pagar tarifas en cadena al abrir y cerrar el canal.
• Buena privacidad, las transacciones off-chain no se harán públicas en la mainnet.

Desventajas:

• Baja utilización de fondos, se requiere bloquear fondos
• Poco amigable para el usuario, requiere monitoreo continuo del canal
• Crear canales es relativamente complejo
• Difícil de diseñar un canal de estado general
• Falta de liquidez, el canal no puede transferir fondos de manera flexible.

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: 2/2 multi-firma construyendo un canal de pago unidireccional, después de agregar RSMC)Revocable Sequence Maturity Contract( se puede construir un canal de pago bidireccional, luego agregando HTLC)Hash Time Lock Contract( se puede expandir el canal de pago a pagos entre múltiples partes, y finalmente construir una red de pagos, es decir, la red Lightning. A través de canales de pago de bajo valor off-chain, y luego aprovechando 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(→ transacciones 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:

• En febrero de 2015, Joseph Poon y Thaddeus Dryja publicaron el borrador del libro blanco de la red Lightning;
• Se publicó la versión oficial del libro blanco en enero de 2016 y se estableció