Profundidad de análisis de escalado off-chain

1. La necesidad de la expansión

La visión futura de la blockchain es lograr descentralización, seguridad y escalabilidad. Sin embargo, a menudo solo se pueden satisfacer dos de estos aspectos, lo que se conoce como el problema del triángulo imposible de la blockchain. Actualmente, uno de los temas candentes en el desarrollo de la blockchain es 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.

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, cuanto mayor sea el número de nodos, mayor será el grado de descentralización.

• 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 manejar grandes volúmenes de transacciones.

La primera bifurcación dura significativa de la red Bitcoin se originó en el problema de la escalabilidad. A medida que aumentaba el número de usuarios y el volumen de transacciones, el límite de capacidad de 1MB por bloque provocó congestión en la red. Desde 2015, la comunidad de Bitcoin comenzó a tener desacuerdos sobre el problema de la escalabilidad, lo que finalmente llevó a la primera bifurcación dura significativa de Bitcoin el 1 de agosto de 2017, que dio origen a BCH.

La red de Ethereum también opta por sacrificar una parte de la escalabilidad para garantizar la seguridad y la descentralización. Desde CryptoKitties en 2017, hasta el verano de DeFi y los posteriores GameFi y NFT, la demanda del mercado por el rendimiento ha aumentado constantemente. Sin embargo, Ethereum solo puede procesar de 15 a 45 transacciones por segundo, lo que provoca un aumento en los costos de transacción y un alargamiento del tiempo de liquidación, haciendo que la mayoría de las DApps no puedan soportar los costos operativos. La solución ideal de escalado es aumentar la velocidad de las transacciones y el rendimiento sin sacrificar la descentralización y la seguridad.

2. Categoría de soluciones de escalabilidad

De acuerdo con "si se cambia una capa de la red principal", los planes de expansión se pueden dividir en dos grandes categorías: expansión en cadena y expansión off-chain.

2.1 Expansión en cadena

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

La escalabilidad en la cadena tiene principalmente dos soluciones:

1. Ampliar el espacio del bloque, aumentar la cantidad de transacciones empaquetadas en cada bloque, pero aumentará los requisitos del equipo de nodos y reducirá el grado de descentralización.

2. Fragmentación, se divide el libro de contabilidad de la blockchain en varias partes, siendo diferentes nodos responsables de distintos registros contables, lo que puede reducir la presión de cálculo en los nodos y el umbral de entrada, pero disminuirá la seguridad de toda la red.

Cambiar el protocolo de la capa principal de la red puede tener efectos negativos impredecibles; pequeñas vulnerabilidades de seguridad en la base pueden amenazar seriamente la seguridad de toda la red.

2.2 off-chain expansión

Concepto clave: solución de escalado que no modifica el protocolo de la red principal de capa uno existente.

Las soluciones de ampliación off-chain se pueden dividir en Layer2 y otras soluciones:

Capa2:

• Canal de estado
• cadena lateral
• Plasma
• Rollups( optimizados Rollup y Zero Knowledge Rollup)

Otros:

• Validium

3. Profundidad de la solución off-chain

3.1 Canales Estatales

3.1.1 Resumen

Los canales de estado establecen que los usuarios solo necesitan interactuar con la cadena principal cuando se abre, cierra o resuelve una disputa en el canal; las interacciones entre los usuarios se realizan off-chain, para reducir el tiempo y costo de las transacciones, logrando 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 administrado por un contrato inteligente de múltiples firmas que se ejecuta en la cadena principal, el cual controla los activos depositados en el canal, valida las actualizaciones de estado y arbitra las disputas entre los participantes. Después de que los participantes implementan el contrato en la red blockchain, depositan y bloquean fondos; una vez que ambas partes firman y confirman, el canal se abre oficialmente. El canal permite a los participantes realizar transacciones off-chain gratuitas sin límite de veces ( siempre que el valor neto de la transferencia no exceda el total de tokens depositados ). Los participantes envían actualizaciones de estado por turnos y esperan la confirmación de firma de la otra parte. Normalmente, las actualizaciones de estado acordadas por ambas partes no se suben a la cadena principal, solo se depende de la confirmación de la cadena principal en caso de disputas o al cerrar el canal. Al cerrar el canal, cualquiera de los participantes puede presentar una solicitud de transacción en la cadena principal; si obtiene la aprobación de todas las firmas, se ejecuta de inmediato, de lo contrario, debe esperar a que finalice el "período de desafío" para recibir los fondos restantes.

Los canales de estado pueden reducir significativamente la carga computacional de la red 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 publican el borrador del libro blanco de la red Lightning.

• 2015/11: Jeff Coleman resumió sistemáticamente el concepto de State Channel por primera vez y propuso que el Payment Channel de Bitcoin es un subcaso de State Channel.

• 2016/01: Joseph Poon y Thaddeus Dryja publican oficialmente el libro blanco de la Red Lightning de Bitcoin, proponiendo un esquema de escalado de Payment Channel.

• 2017/11: Se propuso la primera especificación de diseño de State Channel basada en el marco de Payment Channel, Sprites.

• 2018/06: Counterfactual presentó un diseño detallado de Canales de Estado Generalizados.

• 2018/10: Se propusieron los conceptos de State Channel Networks y Virtual Channels.

• 2019/02: El concepto de canales de estado se amplía a los canales N-Partido, Nitro es el primer protocolo basado en esta idea.

• 2019/10: Pisa amplió el concepto de Watchtowers para resolver el problema de la participación continua 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 abren un canal de estado depositando fondos desde una EOA a la dirección del contrato en cadena.

2. Alice y Bob pueden realizar transacciones ilimitadas off-chain, comunicándose entre sí mediante mensajes firmados criptográficamente. Ambas partes deben firmar cada transacción para evitar el doble gasto malicioso.

3. Si Alice desea cerrar el canal, debe enviar el estado final al contrato. Si Bob firma para aprobarlo, el contrato liberará los fondos bloqueados según el estado final. Si Bob no responde, el contrato liberará los fondos después de que termine el período de desafío.

En un escenario pesimista, si Bob no responde a la firma de actualización de estado de Alice en una ronda, Alice puede presentar un desafío al contrato con la última actualización de estado válida. El contrato permite a Bob responder presentando el siguiente estado dentro de un período de tiempo. Si Bob responde, ambas partes pueden continuar negociando; si no responde, el contrato cierra automáticamente el canal y devuelve los fondos a Alice.

3.1.4 Ventajas y desventajas

Ventajas:

• Confirmación instantánea
• Alta capacidad de procesamiento
• Baja comisión
• Buena privacidad

Desventajas:

• Disponibilidad baja
• Eficiencia de capital baja
• Difícil de manejar transacciones grandes
• No aplicable a contratos inteligentes complejos

3.1.5 Aplicación

Red Lightning de Bitcoin:

• Se publicó un borrador del libro blanco en febrero de 2015
• En enero de 2016 se publicó la versión oficial del libro blanco, se estableció Lightning Labs
• En marzo de 2018 se lanzó la primera versión de la red principal LND 0.4
• En junio de 2021, El Salvador adoptó Bitcoin como moneda de curso legal, en septiembre lanzó la billetera de Lightning Network Chivo.
• En 2022, varios intercambios apoyaron depósitos y retiros de la red Lightning.
• En noviembre de 2022, la red Lightning tenía 76,236 canales de pago, con un capital de 5049 BTC.

Desarrollo ecológico:

• Capa base: BTC red
• Infraestructura básica: soluciones de red Lightning, nodos y servicios de liquidez
• Aplicaciones de capa superior: servicios de pago y financieros, etc.

Red relámpago de Ethereum:

• Fundada en 2017, el fundador es un desarrollador principal de Ethereum.
• En octubre de 2017, la ICO recaudó más de 30 millones de dólares.
• El primer Raiden Light Client se lanzó en mayo de 2020
• A finales de 2021, múltiples intercambios deslistarán el token RDN.

Razones por las que no se ha adoptado ampliamente:

• La barrera de entrada es alta
• Aparecen tecnologías de escalado más avanzadas

Actualmente, el desarrollo ecológico es lento y se está transformando en una solución de escalado que funciona en la red Rollup L2 de Ethereum.

Celer Network:

• La esencia es aumentar la capa de incentivos de la red Lightning
• Construir DApps de interacción de alta frecuencia rápidas y de bajo costo a través de la tecnología de expansión off-chain y modelos económicos incentivadores.
• Aplicable a plataformas de esports y otros escenarios de alta frecuencia de interacción
• Fundado en 2018, emisión de tokens en marzo de 2019
• La red principal de Ethereum se lanzó en julio de 2019
• Actualmente se ha transformado en una plataforma de agregación de escalado L2 que soporta cadenas cruzadas.

3.1.6 Comparación de aplicaciones

Red Lightning de Bitcoin:

• La implementación de canal de estado más madura
• Amplia aplicación, ecosistema rico

Red relámpago de Ethereum:

• El desarrollo ecológico se ha estancado
• Transformación a la solución L2 Rollup

Celer Network:

• Se ha añadido el diseño de la capa de incentivos
• Se ha transformado en una plataforma agregadora L2跨链

3.2 Sidechains

3.2.1 Resumen

El concepto de cadena lateral fue propuesto por primera vez en el chat de desarrolladores de Bitcoin en 2012, y se publicó el primer artículo relacionado en 2014.

Las cadenas laterales son una forma de blockchain que surgió para acelerar las transacciones de Bitcoin, permitiendo el uso de contratos más complejos o mejorando los mecanismos de consenso. Los resultados de las transacciones de la cadena lateral se registrarán finalmente en el lado del validador. Este modelo está adjunto a la cadena principal y ayuda a resolver problemas de la cadena principal como infraestructura básica.

3.2.2 Línea de tiempo

• 2012/01: El concepto de cadenas laterales de Bitcoin se presentó en un chat.
• 2014/10: Publicación del artículo sobre cadenas laterales de Bitcoin
• 2017/04: Lanzamiento de la red de prueba de POA Network
• 2017/10: Se lanza Matic Network
• 2017/12: Lanzamiento de la mainnet de POA Network
• 2018/01: Lanzamiento de la red de pruebas de Skale
• 2018/10: Lanzamiento de la red de pruebas de xDai Chain
• 2020/06: Lanzamiento de la mainnet de Skale
• 2020/06: Lanzamiento de la mainnet de Matic PoS Chain
• 2021/02: Matic cambió su nombre a Polygon
• 2021/02: Se lanzó la cadena lateral Ronin de Axie Infinity
• 2021/12: fusión de xDai Chain con Gnosis Dao
• 2022/03: POA Network se fusionó con Gnosis Chain

3.2.3 Principios técnicos

Las cadenas laterales tienen principalmente dos formas de comunicarse con la cadena principal:

1. Anclaje Simétrico Bidireccional (: Los validadores de la cadena principal y de la cadena lateral registran en tiempo real el estado actual del otro. Al utilizar la tecnología SPV bidireccional, cuando el token de la cadena principal se envía a la cadena lateral, se genera un SPV-Locked Output, que solo puede ser desbloqueado por los validadores de la cadena lateral mediante prueba SPV.

Flujo principal:

• El usuario enviará activos a la dirección especial SPV-Locked Output
• Enviar prueba SPV a la cadena lateral después del período de confirmación.
• Esperar el período del concurso para evitar ataques de doble gasto
• Al completar, los usuarios pueden utilizar los activos empaquetados recién acuñados en la cadena lateral.

2. Anclaje descoordinado ) Anclaje asimétrico (: Los validadores de la cadena lateral monitorean en tiempo real la actividad de la cadena principal. Cuando la cadena principal transfiere fondos a la cadena lateral, esta puede registrar de manera proactiva, pero cuando la cadena lateral transfiere fondos a la cadena principal, se debe introducir el mecanismo de Certificadores. Los Certificadores registran información clave y verifican las transacciones devueltas por la cadena lateral a través de firmas agregadas.

En pocas palabras, el mecanismo de cadena lateral: Cadena lateral: la cadena principal bloquea los activos, la cadena lateral genera activos empaquetados Cadena principal: La cadena lateral destruye los activos empaquetados, la cadena principal desbloquea los activos

La seguridad de los activos de la cadena lateral depende del mecanismo de consenso de la cadena lateral. Si los activos generados en la cadena lateral no coinciden con los de la cadena principal, y luego se destruyen esos activos para solicitar el desbloqueo en la cadena principal, existe un riesgo de robo de fondos.

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

)## 3.2.4 Ventajas y desventajas

Ventajas:

• Alta flexibilidad
• Aliviar la carga de la cadena principal
• Alta capacidad de actualización
• Buena compatibilidad

Desventajas:

• Bajo grado de descentralización
• La seguridad es relativamente baja
• Se necesita confiar en los validador de la cadena lateral
• Transferencia entre cadenas