A lo largo de los años, la teoría de la cadena de aplicaciones se ha implementado de diversas formas. La necesidad de modularidad ha aumentado con el tiempo, a medida que los desarrolladores de blockchain se dan cuenta de que sus plataformas se pueden escalar de manera más eficiente subcontratando parte del trabajo involucrado en la ejecución de dApps.
Inicialmente reservadas solo para cadenas soberanas, a menudo construidas utilizando Interchain Stack, la evolución de las cadenas de aplicaciones ahora incluye cadenas de consumidores que alquilan seguridad desde Cosmos Hub, así como paquetes acumulativos que dependen de cadenas de capa 1 para realizar algunos trabajos de liquidación y puente, como brillantemente. Estos cambios conllevan diferentes supuestos de seguridad y cuestiones que deben abordarse. Celestia pretende resolver un problema especial llamado disponibilidad de datos, pero antes de explicar cómo se relaciona este problema con su proyecto, intentemos comprender la última palabra de moda en Web3: modularidad.
El trabajo realizado por las cadenas de una sola capa 1, incluidas las cadenas Ethereum y soberanas #Cosmos , se puede dividir aproximadamente en 4 capas:
La capa de ejecución procesa transacciones y es responsable de actualizar el estado de la cadena. Por ejemplo: actualice el saldo de su billetera cuando un amigo le envíe tokens.
La capa puente de liquidación es responsable de completar la transacción, o más bien, de confirmar más allá de toda duda razonable que la transacción es válida. Esto se aplica particularmente al resumen, que cubriremos más adelante. Recientemente, la capa de liquidación se ha visto más comúnmente como una capa puente, que proporciona una forma para que los Rollups se comuniquen con la red blockchain más amplia, mientras que la liquidación en sí se ha convertido en un tema más controvertido. En redes normales como Cosmos AppChain, la liquidación es gratuita porque la capa de consenso valida efectivamente cada transacción antes de que llegue a la capa de ejecución.
La capa de consenso es donde varias partes acuerdan qué contiene un bloque y cómo deben ordenarse sus transacciones.
La capa de disponibilidad de datos es responsable de garantizar que todos tengan acceso a las transacciones correctas que se han enviado a la red. Como explicaremos más adelante, la capa de liquidación necesita acceso a estas transacciones para verificar que la capa de ejecución sea honesta.
En el contexto de una cadena basada en Cosmos SDK (que tiene su propio conjunto de validadores y se ejecuta como una cadena de aplicaciones soberana), la capa de consenso es básicamente responsable de la disponibilidad de datos y la liquidación final de las transacciones. Sin embargo, para lanzar una cadena soberana es necesario tener un conjunto de validadores y un token de prueba de participación, a menos que elija una solución de seguridad compartida como Interchain Security. Además de las complejidades legales y operativas de lanzar una cadena con un token, también hay que tener en cuenta consideraciones de escalabilidad.
Escalado eficiente mediante agregación
A medida que la web crece, el trilema de la escalabilidad se vuelve más evidente. A primera vista, puede parecer que blockchain debe hacer sacrificios en términos de seguridad de la red, grado de descentralización o cantidad de transacciones que puede procesar por segundo. Para las cadenas en su conjunto, la mejora de una se ha producido tradicionalmente a expensas de la otra. Sin embargo, a través del trabajo realizado en protocolos modulares, podemos ver que algunos componentes de este trilema son específicos de cada capa de la pila modular.
Por ejemplo: una capa de ejecución que acepta transacciones y las procesa en cambios de estado requiere un rendimiento rápido. Podría decirse que es irrelevante si es descentralizado y seguro, siempre y cuando haya suficientes capas de liquidación, consenso y disponibilidad de datos descentralizadas y seguras para garantizar y verificar que se estén ejecutando las transacciones correctas. Un cierto grado de descentralización en la capa de ejecución contribuye a la vitalidad de la red, pero no es esencial para prevenir cualquier forma de mala conducta. En otras palabras, no afecta ninguna suposición de confianza sobre la red.
Con una pila de blockchain modular, los desarrolladores pueden subcontratar la mayor parte del trabajo necesario para operar una blockchain. Los desarrolladores de aplicaciones son totalmente responsables de la capa de ejecución, lo que aumenta la escalabilidad y reduce significativamente el tiempo de desarrollo. Básicamente, esta es la razón por la que los paquetes acumulativos son tan efectivos y populares en este momento. El rollup, a menudo denominado Capa 2, permite que uno o más servidores ejecuten transacciones fuera de la cadena sin esperar a que un algoritmo de consenso lento acuerde el contenido de un bloque. Esto puede parecer inseguro, pero podrían hacerlo sin incurrir en riesgos significativos al proporcionar pruebas de validez computacionalmente costosas en el caso de la llamada agregación de conocimiento cero (ZK), o al proporcionar una ventana de tiempo en la que los nodos donde los operadores pueden presentar pruebas. del fracaso como evidencia de que alguien actuó de manera inapropiada, como es el caso de la agregación optimista. Sin embargo, en este marco surge un nuevo problema: la cuestión de la disponibilidad de datos.
¿Qué es un problema de disponibilidad de datos?
Cuando un usuario envía una transacción en el resumen, el mensaje se envía directamente al secuenciador, que generalmente es solo una computadora muy rápida que agrupa estas transacciones a través de un proceso fuera de la cadena. Después de comprimirlo a un tamaño más pequeño, el lote se envía a una capa de liquidación como Ethereum. Debido a la gran demanda de espacio de bloque en estas redes, esta es una solución mucho más económica que publicar transacciones individuales directamente en la capa de liquidación. Actualmente, la mayoría de las agregaciones emplean un único secuenciador (es decir, una entidad que realiza la clasificación), aunque se están explorando secuenciadores compartidos. En general, esto es seguro porque los usuarios pueden garantizar que la ejecución de una transacción es válida mediante una prueba de validez o una prueba de falla que se puede verificar en la capa de liquidación. Sin embargo, la agregación no ofrece garantía de que el secuenciador sea honesto acerca de las transacciones enviadas y envíe los mismos datos a todos.
Ésta es la naturaleza del problema de disponibilidad de datos. La capa de liquidación, o cualquier nodo completo que observe la red, tiene la tarea de inspeccionar el trabajo realizado por la agregación, y para ello se requieren datos de transacciones. De forma predeterminada, la agregación no puede probar de manera fácil y económica que el secuenciador procesó todas las transacciones entrantes en un bloque, o que todas las transacciones que se agregaron al bloque son de dominio público. Como resultado, los secuenciadores pueden censurar los datos de transacciones enviados por los usuarios o, peor aún, impedir que sean verificados por la capa de liquidación.
Aunque técnicamente este tipo de censura también podría ocurrir en una cadena de bloques normal, es prácticamente imposible debido a la gran cantidad de validadores en una red de prueba de participación y al hecho de que solo uno de ellos debe ser honesto. Pero lo más importante es que la capa de liquidación no requiere datos para la verificación porque la transacción ya se ha liquidado mediante el proceso de consenso.
#Celestia ¿Cómo solucionar este problema?
#Celestia es una cadena de bloques de capa 1 creada con Cosmos SDK, que proporciona disponibilidad de datos como un servicio de agregación. Lo más común es que la red Celestia reciba todas las transacciones de usuario entrantes del secuenciador, aunque también puede ser el primer destinatario de estas transacciones antes de que ingresen al paquete acumulativo para su ejecución, dependiendo de la configuración del paquete acumulativo. Usemos un ejemplo para explicarlo desde una perspectiva de transacción. Supondremos una red ficticia llamada Roll Protocol, que está construida como un paquete acumulativo optimista basado en Cosmos SDK.
Digamos que estás usando Keplr para enviar algunos tokens $ROLL a tu amigo a través del protocolo Roll. Una vez enviada, la transacción de envío se transmite primero al secuenciador de Roll Protocol.
El secuenciador es una computadora que ejecuta un proceso fuera de la cadena del protocolo Roll, que ahora analiza todas las transacciones y las prueba con el estado actual del protocolo Roll para ver si son realmente válidas. Para el mensaje que envías, verifica si contiene una dirección de destinatario válida, si tienes suficientes tokens $ROLL para enviárselos a tu amigo, etc.
Luego, las transacciones válidas se recopilan en un bloque y el secuenciador las ejecuta, lo que significa que se realizan cambios en su almacenamiento. Los saldos de su billetera y la de su amigo se actualizarán para reflejar las monedas que se intercambian.
Luego, el secuenciador comparte este bloque que contiene las transacciones con Celestia y lo coloca bajo el espacio de nombres "Roll Protocol", que en realidad es solo una etiqueta que facilita la separación de los datos. Luego, los validadores de la red Celestia acuerdan el contenido del bloque, que se finaliza en la red y se distribuye a todos los nodos.
Al mismo tiempo, el secuenciador convierte todas las transacciones exitosas que forman parte de un bloque en un lote y las envía a la capa de liquidación, que generalmente es solo un contrato inteligente en una cadena de capa 1 como Ethereum. La capa de liquidación es la cadena de bloques a la que se envía una prueba de falla si alguien descubre que una transacción en particular no es válida (por ejemplo, en realidad no tienes los fondos para enviar algunas monedas a tu amigo). ¿Pero quién hace este trabajo?
Otros nodos completos ejecutados por dApps independientes (como DEX) también ejecutarán transacciones al mismo tiempo que se ejecuta el secuenciador. Esto les permite mantenerse actualizados y brindarle actualizaciones sobre su saldo, por ejemplo. Es más, pueden comprobar con antelación si alguna transacción no es válida. Si es así, se presenta una prueba del incumplimiento a la capa de liquidación.
Quizás recuerde que la agregación optimista tiene una ventana de tiempo antes de que se liquide una operación. Siempre que confíe en la entidad que opera el nodo completo, hacer que esos nodos completos verifiquen la validez por adelantado puede ayudar a los usuarios a ver las transacciones como "finales" antes de que se cierre la ventana de optimismo. A este sistema lo llamamos "confianza minimizada" porque solo necesita confiar verdaderamente en que la red contiene al menos uno de los muchos nodos honestos para saltarse la ventana de tiempo optimista.
Para probar si el secuenciador se está comportando mal, los nodos completos, así como la capa de liquidación, necesitarán acceder a algunos datos publicados en Celestia, ya que el secuenciador puede haber ejecutado transacciones no válidas. Afortunadamente, la red Celestia publicó un bloque que contiene todas las transacciones entrantes de Roll Protocol que se incluyeron previamente en el lote, por lo que estamos seguros de que tenemos la información que necesitamos para demostrar la integridad del ordenante en caso de que surja la necesidad.
Vale la pena señalar que a Celestia no le importa lo que contenga cada transacción. De hecho, ni siquiera puede entender estas transacciones porque no existe un entorno de ejecución en Celestia que utilice el mismo lenguaje. Al separar estas preocupaciones a través de esta pila modular, el ordenante puede centrarse en ejecutar transacciones rápidamente, la capa de liquidación puede centrarse en la seguridad y proporcionar capacidades de puente, y la capa de consenso y disponibilidad de datos puede centrarse en la descentralización. Esto mejora enormemente la escalabilidad y la optimización al garantizar que cada subcomponente responsable de la operación de la red esté altamente especializado.
Aunque nuestro ejemplo utiliza paquetes acumulativos basados en Cosmos SDK, no se excluyen los paquetes acumulativos compatibles con EVM. Celestia también opera como una capa de disponibilidad de datos para el ecosistema EVM y podría decirse que es mucho más barata que alternativas como EIP-4844 (también conocida como Danksharding) en Ethereum.
Comparación de agregación y cadenas soberanas
Existen muchos beneficios al crear paquetes acumulativos y utilizar la red Celestia. Si ya está desarrollando interchain, puede continuar usando las herramientas y el software con el que está familiarizado mientras aumenta el rendimiento del protocolo, eliminando la necesidad de validadores en la red y, potencialmente, incluso lanzando sin un token si es necesario. Veamos algunas de las diferencias entre crear paquetes acumulativos y cadenas de aplicaciones soberanas:
Escalabilidad y eficiencia: los paquetes acumulativos que utilizan Celestia generalmente brindan mayor escalabilidad y eficiencia en comparación con las cadenas soberanas de Cosmos SDK. Esto se debe a que los rollups mueven la mayor parte del procesamiento de transacciones a la Capa 2, lo que permite procesar más transacciones más rápido, mientras que las cadenas soberanas se ven obstaculizadas por el algoritmo de consenso. Si su aplicación requiere una gran cantidad de transacciones, un resumen puede ser más adecuado que una cadena soberana. En este caso, tu aplicación necesitará gastar tokens en la capa de liquidación, lo que puede resultar costoso dependiendo de la cadena que elijas, aunque Celestia reduce la cantidad de datos a publicar.
Vida y descentralización: los rollups normalmente se ejecutan utilizando un único secuenciador. Se están realizando investigaciones para construir secuenciadores compartidos eficientes, pero este trabajo aún está a la vanguardia y puede reducir la eficiencia de la agrupación. Actualmente, la descentralización a nivel de ejecución en realidad no existe. Por lo tanto, si el secuenciador se desconecta, existe un mayor riesgo de que la redundancia y la vitalidad del resumen se vean afectadas. Se pueden diseñar mecanismos redundantes, pero los desarrolladores de paquetes acumulativos heredan la complejidad de la infraestructura que normalmente comparten los validadores en una cadena de bloques soberana.
Seguridad: los rollups utilizan la seguridad de la capa de liquidación subyacente, mientras que la cadena soberana necesita garantizar la seguridad de su propia red. Si elige utilizar una cadena soberana de Cosmos SDK, querrá asegurarse de tener un conjunto grande y diverso de validadores para proteger su red, así como una capitalización de mercado lo suficientemente grande (en caso de que use pruebas) para apostar su fichas. Los rollups le permiten heredar la seguridad de la capa de liquidación, lo que puede resultar útil si implementar algunos de los requisitos de su cadena de aplicaciones por sí mismo resulta complicado.
Complejidad: crear un sistema Rollup puede ser más complejo que crear una cadena soberana utilizando el SDK de Cosmos. Esto se debe a la necesidad de gestionar las interacciones entre el resumen, Celestia y la capa de liquidación. Si su equipo no tiene experiencia en agregación o no quiere lidiar con la complejidad adicional, una cadena soberana puede ser una mejor opción. Sin embargo, el uso del marco Rollkit facilita mucho el proceso de desarrollo, lo que le permite crear paquetes acumulativos con relativa facilidad.
Interoperabilidad: las cadenas de Cosmos SDK se benefician del protocolo Inter-Blockchain Communication (IBC), que permite que diferentes cadenas interoperen. Si bien los paquetes acumulativos pueden interactuar con otras cadenas, los detalles dependerán de la implementación específica y pueden ser más complejos. En la mayoría de los casos, la agregación utiliza una capa de asentamiento como centro puente.