El ecosistema blockchain es complejo y está en constante evolución, y recientemente ha logrado avances increíbles hacia la escalabilidad. Las cadenas de bloques modulares aportan una serie de beneficios clave, incluida una menor complejidad para los desarrolladores, una mayor escalabilidad y rendimiento, una mejor adaptabilidad y eficiencia financiera.

El ecosistema blockchain es complejo y está en constante evolución, y recientemente ha logrado avances increíbles hacia la escalabilidad. Para mantener este progreso, es importante aclarar los mitos sobre las cadenas de bloques modulares que surgen de vez en cuando.

Las cadenas de bloques modulares aportan una serie de beneficios clave a todo el ecosistema, incluida una menor complejidad para los desarrolladores, una mayor escalabilidad y rendimiento, una mejor adaptabilidad y eficiencia financiera. Están diseñados específicamente para que los componentes puedan trabajar juntos sin problemas, formando un sistema bien integrado.

Vamos a sumergirnos.

Mito 1: Los sistemas modulares aumentan la complejidad del desarrollador

Una idea errónea es que las cadenas de bloques modulares pueden aumentar la complejidad para los desarrolladores de aplicaciones debido a que múltiples componentes trabajan juntos.

Hecho: Los sistemas modulares reducen la complejidad y, a cambio, ofrecen ventajas cruciales a los desarrolladores.

De hecho, en un sistema modular, un desarrollador de contratos inteligentes que construye en una L2 de propósito general tiene exactamente la misma experiencia que un desarrollador de contratos inteligentes que construye en una cadena monolítica. Una vez que el contrato inteligente se implementa en una cadena EVM L2, los usuarios solo tienen que enviar sus transacciones a la cadena de bloques como lo habrían hecho si el contrato se hubiera implementado en una cadena monolítica. Cualquier aumento en la complejidad es manejado por el desarrollador de la cadena/rollup, no por el desarrollador de la aplicación, y le brinda al desarrollador de la aplicación varias ventajas a cambio, incluyendo flexibilidad, reducción de costos y más.

¿Qué pasa si el proyecto se implementa como un paquete acumulativo específico de una aplicación en lugar de uno de propósito general?

En un ecosistema modular, las complejidades subyacentes que se encuentran más abajo en la pila se pueden reducir para los desarrolladores de paquetes acumulativos al ofrecer plantillas de cadena preconfiguradas. Como ejemplo, si desea implementar un paquete acumulativo de aplicaciones hoy, puede ir a un proveedor de paquete acumulativo como servicio (RaaS) (consulte Caldera, Altlayer, Opside, Snapchain) y activarlo con un solo clic.

El proveedor de RaaS asume la complejidad y la ofrece como un servicio, como alojar una máquina virtual en DigitalOcean o implementar una aplicación web en Heroku. Un usuario avanzado aún puede ocuparse de toda la orquestación, lo que proporciona más capacidad de configuración, pero requiere un gran esfuerzo de configuración y mantenimiento.

Veamos una comparación entre un proyecto que decide implementar su propia cadena exclusiva en un entorno monolítico versus modular:

• Monolítico: si un proyecto se implementa como una 'cadena de aplicaciones' en el sentido Cosmos, entonces la complejidad (social y técnica) puede ser alta para los desarrolladores de aplicaciones, aunque tanto DA como Ejecución ocurren dentro del mismo sistema. Los desarrolladores tienen que iniciar su propia red de validadores, e interactuar con otras cadenas requiere confiar en las redes de validadores de esas cadenas.
• Modular: si el proyecto se implementa como un 'acumulado específico de la aplicación' en otra capa DA base como Avail, Ethereum o Celestia, los desarrolladores no tienen que preocuparse por poner en marcha la seguridad de la red y pueden centrarse simplemente en crear la aplicación. . Estos paquetes acumulativos aún heredan la seguridad de la capa base subyacente y, en cierto modo, esto es similar a cómo un desarrollador de software tradicional se concentraría en crear una aplicación sin preocuparse por la infraestructura subyacente.

Las rampas de entrada y salida CEX y fiat también serán fácilmente accesibles para los desarrolladores de aplicaciones en cadenas de bloques modulares. Cada ecosistema acumulativo importante en una cadena de bloques de Capa 1 (como Avail) tendrá al menos un paquete acumulativo especializado centrado en la liquidez, que tendrá:

• Conexiones CEX robustas
• Rampas de entrada y salida para Fiat
• Uniendo puentes hacia las principales capas de asentamiento
• DEX-es con gran liquidez

Este paquete acumulativo centrado en la liquidez (o Liquidity Hub) será fácilmente accesible desde otros paquetes acumulativos a través de un mecanismo de mensajería entre paquetes rápido y económico. Los ecosistemas acumulativos creados sobre una capa DA compartida se centrarán en una interoperabilidad perfecta entre los propios acumuladores, ya que no necesitan cruzar zonas de confianza.

Se ven buenos ejemplos tempranos de este modelo con Osmosis en el ecosistema Cosmos o AssetHub en el ecosistema Polkadot; estrictamente hablando, estos no son resúmenes, pero se puede ver el patrón general de diseño del ecosistema en el que otros convergen.

Mito 2: las cadenas modulares reducen el rendimiento

Existe la idea errónea de que separar la funcionalidad de una cadena de bloques monolítica en capas modulares reducirá el rendimiento, o al menos no lo mejorará.

Hecho: las cadenas de bloques modulares mejoran el rendimiento porque cada componente se puede optimizar por separado

Ahora vivimos en un mundo post-zk, donde las suposiciones que antes prevalecían sobre escalabilidad y seguridad ya no se sostienen. Hoy en día, la verificación de ejecución no requiere que TODOS los nodos de la red vuelvan a ejecutar todas las transacciones. En cambio, los probadores de conocimiento cero (ZK) que no son confiables pueden proporcionar pruebas de validez, que son mucho más baratas de verificar. Y los probadores de validez son increíblemente paralelizables.

Con Data Availability Sampling o, en resumen, DAS (implementado en Avail, Celestia), no necesita descargar todos los datos de la transacción para verificar la disponibilidad de datos (DA). Los clientes ligeros de DAS pueden muestrear aleatoriamente una pequeña fracción de todos los datos y obtener muy rápidamente garantías DA de alta probabilidad.

Esto es un orden de magnitud más rápido y económico que descargar TODOS los datos de CADA nodo de la red.

La combinación de DAS y pruebas de validez recursivas hace que las cadenas de bloques modulares sean extremadamente poderosas. Cualquier desarrollador de rollups puede crear una cadena completamente nueva, incluso con un secuenciador centralizado, y los usuarios aún pueden estar seguros de la seguridad de sus fondos, suponiendo que el protocolo rollup tenga opciones integradas para trampillas de escape y secuenciación basada.

Algunos beneficios adicionales que obtienes con esto son:

1. Este sistema es más escalable ya que incluso los nodos ligeros pueden obtener sólidas garantías de seguridad.
2. Es posible que el entorno de ejecución de EVM no sea ideal para todas las aplicaciones. En tal caso, la aplicación puede adaptar el entorno de ejecución a sus propias necesidades implementando cualquier otra máquina virtual como SVM (¡o incluso ninguna máquina virtual! - consulte Stackr Labs).

La modularidad no tiene nada que ver con las velocidades de ejecución. La máquina virtual Solana en un paquete acumulativo tendrá el mismo rendimiento que en una cadena de bloques monolítica. El verdadero beneficio de la modularidad es la optimización del flujo de trabajo de verificación. Y ni siquiera necesita tener pruebas de validez/zk. Los rollups optimistas o pesimistas también presentan las mismas características.

Las cadenas de bloques modulares son más que la suma de sus partes.

Mito 3. Las cadenas de bloques modulares aumentan los costos

Cuando se trabaja con cadenas de bloques modulares, puede haber preocupación por el aumento de costos, pero en realidad es todo lo contrario. Las cadenas monolíticas tienen costos ocultos y, en un mundo de múltiples cadenas, los usuarios pagan los costos de todas las cadenas.

Hecho: Las cadenas modulares eliminan el costo de la seguridad en múltiples cadenas al compartir una capa base.

Veamos algunos datos sobre los costos reales de operar varias redes blockchain. Los datos a continuación provienen de https://www.stakerewards.com/

Concéntrese en la columna del extremo derecho de la tabla anterior. Como es evidente, ¡los costos de iniciar y mantener una cadena de bloques son realmente altos!

Tenga en cuenta que las recompensas inflacionarias para los participantes que administran la red se pagan en última instancia desde el bolsillo del poseedor del token. Los poseedores de tokens subsidian el costo de funcionamiento de la red en ausencia de tarifas de transacción reales.

Siempre que alguien quiere flexibilidad en las reglas del protocolo de una cadena monolítica y quiere introducir un nuevo entorno de ejecución o una nueva precompilación, los defensores de las cadenas de bloques monolíticas esperan que construyan una nueva cadena de bloques iniciando una red de validación y un token desde cero.

Esto está limitando la innovación sin permiso que es el núcleo de esta industria.

Cuando se implementa un resumen en la misma capa DA, forma parte del MISMO libro mayor como un activo en la capa base. De hecho, el llamado 'libro mayor L2' es solo un subconjunto de las entradas de datos en el libro mayor L1. Como explica Jon en este artículo, hay millones de resúmenes dentro de cada capa DA. En términos simples, un resumen es simplemente CUALQUIER subconjunto de la capa DA base.

“Hay esencialmente infinitos rollups no descubiertos ocultos en los datos de Ethereum. Puede hacer un resumen para leer y calcular esos datos sin confianza como desee y luego, de manera demostrable, podrá comunicarlos. -Jon Charbonneau”

Sí, hay entidades específicamente enfocadas en mantener sus propios libros de contabilidad L2, pero todos estos libros de contabilidad son, en última instancia, solo los subconjuntos de los libros de contabilidad de la capa base. Es por eso que las L2 heredan las garantías de seguridad de la capa DA en la que están implementadas.

En una capa DA compartida, los poseedores de tokens de la capa base arrancan y mantienen la seguridad. El ecosistema acumulativo superior no necesita gestionar esto individualmente. Heredan la seguridad de la capa base.

Una idea compartida por algunos de que la modularización de las cadenas de bloques conduce a una menor liquidez en cada libro mayor es errónea y supone que las cadenas de bloques modulares no están integradas verticalmente. Este argumento valora la componibilidad sincrónica cuando la mayoría de las cosas son posibles mediante la componibilidad asincrónica. Incluso los mejores sistemas fintech tradicionales priorizan la componibilidad asincrónica. Esto es lo que permite a las cadenas Cosmos acceder al centro de liquidez en Osmosis (a través de IBC) y a los rollups Ethereum L2 para acceder a la liquidez en Ethereum (a través de un puente de confianza minimizada).

A medida que los sistemas modulares maduren, la mensajería asincrónica mediante agregación de pruebas recursivas será extremadamente económica, ya que la verificación de la prueba de validez del lado del cliente es posible mediante una combinación de verificadores de ejecución y una verificación DA eficiente a través de clientes ligeros.

Si le preocupan las múltiples transacciones de arbitraje en diferentes acumulaciones, no se limitan solo a cadenas de bloques modulares. Pueden ocurrir cálculos duplicados en los libros de contabilidad de activos incluso con múltiples protocolos DeFi en la misma capa. Si el precio ETH-USDC es de $1800 en Binance, $1600 en Aave y $1700 en Compound, esto requiere dos transacciones de arbitraje separadas para resolverse.

Las transacciones de arbitraje múltiple no son una función o consecuencia exclusiva de las cadenas de bloques modulares.

Mito 4: Los paquetes acumulativos de aplicaciones no ofrecen a los desarrolladores nada para experimentar o monetizar

Existe la idea errónea de que los paquetes acumulativos de aplicaciones no brindan a los desarrolladores nuevas vías de experimentación o monetización. La creencia es que las construcciones existentes en cadenas monolíticas brindan suficientes herramientas para realizar experimentaciones o generar ingresos.

Hecho: Los paquetes acumulativos modulares permiten una experimentación flexible que incluye oportunidades creativas de monetización y mucho más.

Los paquetes acumulativos modulares permiten a los desarrolladores trabajar en una variedad de entornos de ejecución, no solo fomentando la diversidad sino también presentando ventajas de ahorro de costos. En comparación con las cadenas monolíticas, con sus elevados gastos generales, los paquetes acumulativos de aplicaciones específicas suelen ser más económicos y optimizados, lo que elimina complejidades como la gestión de infraestructuras y indexadores.

Está bastante claro que las aplicaciones pueden capturar MEV (in-rollup y cross-chain) si implementan la aplicación como un paquete acumulativo específico de la aplicación. Existe la idea errónea de que se puede lograr lo mismo con cadenas de bloques monolíticas agregando algunos cambios lógicos al contrato inteligente implementado en una máquina de estado "monolítica" global.

Agregar algunos cambios lógicos al contrato inteligente implementado en una máquina de estado "monolítica" global puede lograr resultados similares. Pero la idea de adherirse a un modelo de estado global y una única máquina virtual para la ejecución no tiene mucho sentido cuando hay tanto potencial para entornos de ejecución arbitrarios con paquetes acumulativos de aplicaciones. Como se explicó anteriormente, algunas aplicaciones pueden adaptarse mejor a un entorno de ejecución completamente diferente al EVM o SVM estándar. Esto es posible con Modular Blockchains, y creemos que se requiere mucha más experimentación con entornos de ejecución, autenticación de libro mayor, acceso, modelos de estado personalizados, etc., para seguir impulsando la industria.

Tomando una analogía con las pilas de tecnología tradicionales, no existe un lenguaje de programación único ni una forma estándar de desarrollar aplicaciones web/móviles. ¿Por qué las cadenas de bloques deberían ser diferentes? ¡La diversidad de opciones y el fomento de la experimentación que abre nuevas oportunidades de monetización en cualquier industria se pueden lograr con paquetes acumulativos modulares!

Además de las oportunidades de ingresos, los “costos” de implementar y mantener una aplicación en una cadena monolítica pueden ser mucho más altos que simplemente implementar un paquete acumulativo específico de la aplicación. La mayoría de los desarrolladores de aplicaciones en una cadena monolítica necesitan administrar una gran cantidad de infraestructura, indexadores, proveedores de retransmisión de transacciones, proveedores de nodos completos RPC, etc.

Las estructuras modulares pueden abstraer esta complejidad al permitir que cadenas especializadas con la construcción adecuada (función de transición de estado personalizada, específica de la aplicación, estado personalizado; consulte Stackr Labs) eviten estos requisitos de administración de infraestructura, lo que a menudo es más barato que intentar arrancar todo. en una cadena monolítica usted mismo.

Ignorando todos estos beneficios, ¿realmente queremos limitar a los desarrolladores al status quo?

Mito 5: Las cadenas de bloques modulares no resuelven la congestión entre aplicaciones

La idea errónea es que las cadenas monolíticas tienen estructuras adecuadas para resolver la congestión entre aplicaciones, sin necesidad de dividirse en paquetes acumulativos específicos de aplicaciones.

Hecho: Los paradigmas más nuevos dentro de las cadenas modulares permiten mecanismos de tarifas mucho más eficientes

En la práctica, fijar el precio de cada recurso utilizando el mismo mercado global de tarifas impone limitaciones al rendimiento de todo el sistema. Si bien los mercados de tarifas localizados, como se ve en Solana y Aptos, alivian efectivamente la congestión a nivel de aplicaciones, no logran abordar la congestión entre aplicaciones.

Esto es precisamente lo que intentan resolver los desarrolladores de sistemas modulares. Al implementar una aplicación como un paquete acumulativo específico de la aplicación, los proyectos pueden obtener entornos de ejecución exclusivos y mercados de tarifas específicos de la aplicación.

¿Qué sucede cuando hay un aumento en los precios y una congestión en la capa base (ya sea directamente o a través de alguna otra L2)?

El paquete acumulativo específico de la aplicación puede seguir funcionando con normalidad y no verse afectado si simplemente retrasa la publicación de un lote de transacciones en la capa base durante dichos picos. Los usuarios de este paquete acumulativo de aplicaciones aún podrán obtener una finalidad suave, aunque la finalidad "dura" pueda retrasarse.

Los rollups en una capa base escalable centrada en la disponibilidad de datos como Avail mitigan esto en gran medida al poder escalar los tamaños de los bloques DA con la demanda de rollups.

En un ecosistema acumulativo que permite el paso de mensajes asincrónicos a través de agregación de pruebas recursiva, cada aplicación puede tener su propio rendimiento y precio de transacción. Pueden correr a su propio ritmo sin tener que preocuparse por la otra cadena con la que deben interactuar. El paso de mensajes asíncronos permite una inclusión verificable sin suposiciones de sincronicidad y, por lo tanto, permite a los usuarios una flexibilidad mucho mayor en términos de evitar el acceso al estado compartido en comparación con las cadenas monolíticas.

El paradigma asíncrono habilitado por la agregación de pruebas le permite colocar transacciones en cadenas individuales en diferentes momentos para evitar la congestión de cadenas individuales sin sacrificar la atomicidad o la componibilidad entre las aplicaciones. Esto proporciona un conjunto más completo de herramientas para expresar intenciones que tienen una capacidad de composición sincrónica extremadamente limitada entre aplicaciones en una cadena monolítica.

Mito 6: La modularidad carece de integración vertical y frena la innovación

Una idea errónea es que la modularidad no significa integración vertical. También se cree que la flexibilidad que ofrecen las cadenas modulares está sobrevalorada y no es necesario construir nada nuevo.

Hecho: Los sistemas modulares permiten la creatividad para construir los casos de uso del futuro

La verdad es que los sistemas modulares se pueden combinar para formar pilas integradas verticalmente, cuya complejidad se puede abstraer de los desarrolladores de aplicaciones.

La premisa de la innovación sin permiso es permitir a los desarrolladores de aplicaciones experimentar y proponer nuevas ideas mientras siguen absorbiendo alta seguridad de la pila en la que se implementan sus aplicaciones. Esta falta de permisos puede verse limitada si la aplicación se implementa en una L1 donde los costos de actualización son altos.

Los sistemas modulares reducen el costo de experimentar con nuevos entornos de ejecución, nuevos modelos de estado y nuevos mecanismos de acceso. Proporcionan acceso a tarifas más bajas y menor latencia. El acceso a DEX al contado, monedas estables y rampas de acceso fiduciarias se puede implementar fácilmente a través de uno o más paquetes acumulativos centrados en la liquidez o un centro de liquidez, como se mencionó anteriormente.

Sin experimentación, es imposible predecir los casos de uso que se pueden fomentar con una pila modular implementada correctamente. Cuando apareció Internet, la mejor suposición de Bill Gates sobre un caso de uso era ver grabaciones de partidos de béisbol. Esto simplemente demuestra lo difícil que es predecir la dirección que tomará una tecnología sin permitir que nadie innove en ella sin permiso.

Mito 7: Los rollups no pueden bifurcarse como las cadenas L1

Existe la idea errónea de que los paquetes acumulativos no pueden bifurcarse. Están atados al puente consagrado en la capa base y una bifurcación dura significaría que la capa base misma tiene que bifurcarse.

Hecho: Los roll-ups soberanos en cadenas modulares permiten una bifurcación continua y sin dependencia de la capa base.

Esta idea errónea surge de cómo se implementan hoy en día los paquetes acumulativos en Ethereum que combinan un puente a la capa base para los activos L1 junto con el mecanismo de verificación de estado. No debemos confundir el puente y la mecánica de verificación.

El resumen en sí ciertamente puede ser bifurcado, muy similar a cómo ocurren las bifurcaciones L1. El puente en sí es una construcción separada. Jon Charbonneau explica bastante bien en esta publicación por qué los rollups no son iguales a los puentes. Un rollup no está definido por el puente y, por lo tanto, la capacidad de bifurcación dura del puente en alguna otra cadena no debe equipararse con la capacidad de bifurcación dura del propio rollup.

Un resumen soberano en Avail puede verse como similar a cualquier cadena de bloques normal. Hay nodos completos del paquete acumulativo que se sincronizan con el nodo del paquete acumulativo. Lo que sucede de manera diferente aquí es que los datos de las transacciones acumuladas también se envían a Avail y los clientes ligeros de DA en Avail pueden luego muestrear aleatoriamente los datos y verificar la disponibilidad de los datos. Estos clientes ligeros también están integrados en el nodo acumulativo para facilitar este proceso. La principal diferencia en esta construcción frente a los rollups de tipo de capa de liquidación consagrados o estilo Ethereum es que los nodos acumulativos y los clientes ligeros verifican la cadena canónica sin depender de un mecanismo de verificación consagrado basado en contratos inteligentes.

Y si las personas aún no están convencidas de las discusiones teóricas al respecto, pueden consultar nuestro prototipo OpEVM , que es una cadena soberana y optimista construida sobre Avail con un conjunto de secuenciador descentralizado y una torre de vigilancia sin permiso. Puede bifurcarse fácilmente sin cambiar nada en Avail. También es bueno tener en cuenta que Avail no admite ningún contrato inteligente, por lo que el paquete acumulativo no tiene un puente consagrado que le otorgue soberanía.

Resumen

En la actualidad, las cadenas de bloques son una industria de nicho. Necesitamos más usuarios, mayor adopción y casos de uso ampliados de los que son posibles hoy en día.

Para llegar allí, necesitaremos reducir el costo de la experimentación y permitir que los usuarios y desarrolladores elijan con conocimiento de causa entre ecosistemas monolíticos o modulares. Esperamos que en este artículo haya aprendido más sobre el potencial escalable de los sistemas modulares y esté mejor equipado para tomar esa decisión usted mismo cuando lo necesite. Y con las herramientas adecuadas, estamos seguros de que creará innovaciones más allá de nuestra imaginación.

¡Que florezcan miles de rollups!

Descargo de responsabilidad:

1. Este artículo se reimprime de [Availproject]. Todos los derechos de autor pertenecen al autor original [Equipo Avail]. Si hay objeciones a esta reimpresión, comuníquese con el equipo de Gate Learn y ellos lo manejarán de inmediato.
2. Descargo de responsabilidad: los puntos de vista y opiniones expresados en este artículo son únicamente los del autor y no constituyen ningún consejo de inversión.
3. Las traducciones del artículo a otros idiomas están a cargo del equipo de Gate Learn. A menos que se mencione, está prohibido copiar, distribuir o plagiar los artículos traducidos.