- Tema
16k Popularidad
2k Popularidad
3k Popularidad
41k Popularidad
16k Popularidad
60k Popularidad
31k Popularidad
3k Popularidad
94k Popularidad
27k Popularidad
- Anclado
16k Popularidad
2k Popularidad
3k Popularidad
41k Popularidad
16k Popularidad
60k Popularidad
31k Popularidad
3k Popularidad
94k Popularidad
27k Popularidad
Análisis completo de la escalabilidad off-chain: la tecnología Layer 2 que supera la Unholy Trinity
Análisis profundo de la expansión off-chain
Autor: Cobo Ventures
1. La necesidad de escalar
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 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 cadena de bloques:
Descentralización: cualquier persona puede convertirse en un nodo y participar en la producción y validación del sistema blockchain. Cuantos más nodos haya, mayor será el grado de descentralización, lo que asegura que la red no esté bajo el control de un pequeño grupo de grandes participantes centralizados.
Seguridad: Cuanto mayor sea el costo para obtener el control del sistema blockchain, mayor será la seguridad, por lo que la cadena puede resistir un mayor porcentaje de ataques por parte de los participantes.
Escalabilidad: la capacidad de la blockchain para manejar grandes volúmenes de transacciones.
La primera bifurcación dura significativa de 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, donde un grupo, representado por Bitcoin ABC, apoya la ampliación del tamaño del bloque, mientras que el otro grupo, representado por Bitcoin Core, apoya la solución Segwit para optimizar la estructura de la cadena principal. El 1 de agosto de 2017, Bitcoin ABC lanzó su sistema cliente desarrollado de forma independiente de 8MB, lo que provocó la primera bifurcación dura significativa en la historia de Bitcoin y también dio lugar a la creación de la nueva moneda BCH.
Del mismo modo, 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 ha limitado el volumen de transacciones como lo ha hecho la red de Bitcoin al restringir el tamaño de los bloques, sino que ha cambiado indirectamente a establecer un límite en las tarifas de combustible que un solo bloque puede contener, pero el objetivo es lograr un Consensus Trustless y asegurar una amplia distribución de los 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 el CryptoKitties de 2017, el verano de DeFi, hasta el surgimiento posterior de aplicaciones on-chain como GameFi y NFT, la demanda del mercado por capacidad de procesamiento ha ido en aumento. Sin embargo, incluso Ethereum, que es Turing completo, solo puede manejar entre 15 y 45 transacciones por segundo ( TPS ). Esto ha llevado a un aumento continuo en los costos de transacción, a un tiempo de liquidación más largo y a que la mayoría de las Dapps no puedan soportar los costos operativos, lo que hace que toda la red sea lenta y cara para los usuarios. El problema de la escalabilidad de la blockchain necesita ser resuelto urgentemente. La solución ideal para la 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 transacción ( TPS ) sin sacrificar la descentralización y la seguridad.
2. Tipos de soluciones de escalabilidad
Utilizamos "si se cambia una capa de la red principal" como criterio para clasificar los planes de expansión en dos grandes categorías: expansión en cadena y expansión off-chain.
2.1 Expansión en cadena
Concepto clave: solución que logra un efecto de escalabilidad al cambiar 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 detendrá en ello, 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 los dispositivos de nodos de alto rendimiento, elevará el umbral de entrada para los nodos y reducirá el grado de "descentralización".
La opción dos es fragmentación, que divide el libro mayor de la blockchain en varias partes. Ya no es necesario que cada nodo participe en toda la contabilidad, sino que diferentes fragmentos, es decir, diferentes nodos, son responsables de diferentes contabilidades. El cálculo en paralelo puede procesar múltiples transacciones simultáneamente; esto puede reducir la presión de cálculo 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 puede reducir la "seguridad" de toda la red.
Cambiar el código de un protocolo de la red 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 realizar un fork o a interrumpir la actualización de reparaciones. 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, por lo que el equipo tardó 8 meses en realizar una reparación secreta, y solo después de solucionar la vulnerabilidad se hizo público este incidente.
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 escalado off-chain se pueden subdividir en Layer2 y otras soluciones:
3. Profundidad de las soluciones de escalado 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 el canal se abre, se cierra o se resuelve una disputa, 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 lograr que el número de transacciones no esté limitado.
El canal de estado es un protocolo P2P simple, adecuado para "aplicaciones basadas en turnos", por ejemplo, un juego de ajedrez para dos personas. Cada canal es gestionado por un contrato inteligente de múltiples firmas que funciona 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 ) con firma y marca 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 para confirmar, el canal se abre oficialmente. El canal permite transacciones gratuitas fuera de la cadena ilimitadas entre los participantes ( siempre que su valor neto de transferencia no supere el total de tokens depositados ). Los participantes envían actualizaciones de estado alternativamente a la otra parte, esperando la confirmación de firma de la otra parte. Una vez que la otra parte firma para confirmar, 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 sea necesario cerrar el canal, cualquiera de los participantes puede presentar una solicitud de transacción en la cadena principal, y si la solicitud de salida recibe la aprobación de firma unánime, se ejecutará inmediatamente en la cadena, es decir, el contrato inteligente distribuirá los fondos bloqueados restantes según el saldo de cada participante en el estado final del canal; si otros participantes no aprueban la firma, todos deberán esperar el final del "período de desafío" para recibir los fondos restantes.
En resumen, el esquema de canal de estado puede reducir significativamente la carga computacional de la cadena 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 whitepaper de la red Lightning.
En noviembre de 2015, Jeff Coleman resumió sistemáticamente el concepto de State Channel y propuso que el Payment Channel de Bitcoin es un subcaso dentro 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 el esquema de escalamiento de la red Lightning de Bitcoin Payment Channel( pago canal), el cual se utiliza únicamente para procesar pagos de transferencias en la red de Bitcoin.
En noviembre de 2017, se propuso la especificación de diseño Sprites relacionada con State Channel basada en el marco de Payment Channel.
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 Redes de Canales de Estado Generalizados presentó los conceptos de Redes de Canales de Estado y Canales Virtuales.
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.
3.1.3 Principios técnicos
El flujo de trabajo básico de los canales de estado es el siguiente:
Alice y Bob depositan fondos desde su EOA personal a la dirección del contrato en cadena, estos fondos se bloquean en el contrato hasta que se cierren los canales y el saldo se devuelva al usuario; después de que ambas partes firmen y confirmen, el canal de estado entre ellos se abre oficialmente.
Alice y Bob pueden realizar teóricamente 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 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.
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 de acuerdo con el estado final y los devolverá al usuario correspondiente. Si Bob no responde con la firma, el contrato liberará los fondos bloqueados y los devolverá al usuario correspondiente una vez finalizado el período de desafío.
3.1.4 Ventajas y desventajas
Ventajas:
Desventajas:
3.1.5 Aplicaciones
Las aplicaciones principales incluyen la red Lightning de Bitcoin, la red Lightning de Ethereum y Celer Network, entre otras.
Tomemos como ejemplo la red Lightning de Bitcoin:
El ecosistema de la red Lightning se compone de abajo hacia arriba: la red BTC en la capa base, la infraestructura central y diversas aplicaciones. Actualmente hay más de 100 aplicaciones, que abarcan múltiples categorías como pagos, billeteras, gestión de nodos, etc.
3.1.6 Comparación de aplicaciones
La red Lightning de Bitcoin, la red Lightning de Ethereum y Celer Network presentan algunas diferencias en términos de diseño, escenarios de aplicación y grado de desarrollo:
En general, la tecnología de canales de estado sigue en constante desarrollo y se espera que en el futuro se aplique de manera más amplia en escenarios como los pagos de bajo monto y alta frecuencia.
3.2 Cadenas laterales
3.2.1 Resumen
Las cadenas laterales son una forma de blockchain que apareció para acelerar las transacciones de Bitcoin, pudiendo utilizar contratos más complejos, o mejorar el mecanismo de consenso ( como PoS ), o ajustar los parámetros de bloque para que la cadena lateral cumpla con funciones específicas. El resultado de las transacciones de la cadena lateral se registrará finalmente en el lado del validador al ser transmitido de vuelta a la cadena principal. Este modelo de blockchain no es una nueva forma de blockchain, sino una infraestructura que se adjunta a la cadena principal y ayuda a resolver problemas de la cadena principal.
3.2.2 Línea de tiempo