Cuando se trata de atención e innovación, no todos los componentes de la pila modular se crean de igual manera. Si bien históricamente ha habido muchos proyectos innovando en las capas de disponibilidad de datos (DA) y de secuenciación, las capas de ejecución y liquidación han sido comparativamente más descuidadas como parte de la pila modular hasta hace poco tiempo.

El espacio secuenciador compartido no solo tiene muchos proyectos compitiendo por el mercado — Espresso, Astria, Radio, Roma, y Madarapara nombrar algunos, pero también incluye proveedores de RaaS comoCalderayConduitquienes desarrollan secuenciadores compartidos para rollups que se basan en ellos. Estos proveedores de Gate como servicio son capaces de proporcionar un reparto de tarifas más favorable con sus rollups ya que su modelo de negocio subyacente no depende únicamente de los ingresos por secuenciación. Todos estos productos existen junto a los muchos rollups que optan simplemente por ejecutar su propio secuenciador y descentralizarse con el tiempo para capturar las tarifas que genera.

El mercado de secuenciación es único en comparación con el espacio DA, que básicamente opera como un oligopolio compuesto porCelestia, Disponible, y EigenDA. Esto hace que sea un mercado difícil para los nuevos participantes más pequeños más allá de los tres principales para interrumpir con éxito el espacio. Los proyectos aprovechan la opción “incumbente” — Ethereum — o optan por una de las capas establecidas de DA dependiendo del tipo de pila tecnológica y alineación que están buscando. Si bien el uso de una capa de DA es un gran ahorro de costos, externalizar la pieza del secuenciador no es una opción tan obvia (desde el punto de vista de la tarifa, no de la seguridad) — principalmente debido al costo de oportunidad de renunciar a las tarifas generadas. Muchos también argumentan que el DA se convertirá en una mercancía, pero hemos visto en cripto que los fosos de liquidez superfuertes combinados con tecnología subyacente única (difícil de replicar) hacen que sea mucho más difícil convertir en mercancía una capa en la pila. Independientemente de estos debates y dinámicas, hay muchos productos de DA y secuenciador en producción (en resumen, con parte de la pila modular, @maven11research/commoditise-your-complements">"hay varios competidores para cada servicio único."

Las capas de ejecución y liquidación (y por extensión de agregación) - que creo que han sido comparativamente poco exploradas - están comenzando a ser iteradas de nuevas formas que se alinean bien con el resto del stack modular.

Resumen sobre la relación entre la capa de ejecución y liquidación

La capa de ejecución y liquidación están estrechamente integradas, donde la capa de liquidación puede servir como el lugar donde se definen los resultados finales de la ejecución del estado. La capa de liquidación también puede agregar funcionalidad mejorada a los resultados de la capa de ejecución, lo que hace que la capa de ejecución sea más robusta y segura. En la práctica, esto puede significar muchas capacidades diferentes, por ejemplo, la capa de liquidación puede actuar como un entorno para que la capa de ejecución resuelva disputas de fraude, verifique pruebas y haga de puente entre otras capas de ejecución.

También vale la pena mencionar que hay equipos que permiten nativamente el desarrollo de entornos de ejecución con opiniones directamente dentro de su propio protocolo — un ejemplo de esto es Repyh Labs, que está construyendo un L1 llamado Delta. Esta es, por naturaleza, el diseño opuesto al stack modular, pero aún proporciona flexibilidad dentro de un entorno unificado y viene con ventajas de compatibilidad técnica, ya que los equipos no tienen que pasar tiempo integrando manualmente cada parte del stack modular. Los inconvenientes, por supuesto, son estar aislados desde un sentido de liquidez, no poder elegir capas modulares que se ajusten mejor a su diseño y ser demasiado caros.

Otros equipos optan por construir L1s extremadamente específicos para una funcionalidad central o aplicación. Un ejemplo es Hyperliquid, que ha construido un L1 específicamente para su aplicación nativa principal, una plataforma de trading perpetuo. Aunque sus usuarios necesitan hacer un puente desde Arbitrum, su arquitectura central no depende del Cosmos SDK u otros marcos, por lo que puede ser personalizado e hiper-optimizado de forma iterativapara su caso de uso principal.

Progreso de la capa de ejecución

El predecesor de esto (último ciclo, y todavía algo presente) fueron los alt-L1 de propósito general donde básicamente la única característica que superaba a Ethereum era el mayor rendimiento. Eso significaba que históricamente los proyectos básicamente tenían que optar por construir su propio alt L1 desde cero si querían mejoras de rendimiento sustanciales, en su mayoría porque la tecnología aún no estaba disponible en Eth en sí. Y históricamente, esto simplemente significaba incrustar mecanismos de eficiencia directamente en el protocolo de propósito general. En este ciclo, estas mejoras de rendimiento se logran a través de un diseño modular y en su mayoría se encuentran en la plataforma de contratos inteligentes más dominante que existe (Ethereum) - de esta manera, tanto los proyectos existentes como los nuevos pueden aprovechar la nueva infraestructura de capa de ejecución sin sacrificar la liquidez, seguridad y ventajas comunitarias de Ethereum.

En este momento, también estamos viendo más mezcla y combinación de diferentes VM (entornos de ejecución) como parte de una red compartida, lo que permite flexibilidad para los desarrolladores, así como una mejor personalización en la capa de ejecución.Capa N, por ejemplo, permite a los desarrolladores ejecutar nodos consolidados generalizados (por ejemplo, SolanaVM, MoveVM, etc. como entornos de ejecución) y nodos consolidados específicos de la aplicación (por ejemplo, perps dex, orderbook dex) sobre su máquina de estado compartida. También están trabajando para permitir la componibilidad completa y la liquidez compartida entre estas diferentes arquitecturas de máquinas virtuales, un problema de ingeniería en cadena históricamente difícil de resolver a escala. Cada aplicación en la capa N puede pasar mensajes de forma asincrónica entre sí sin demora en el lado del consenso, que normalmente ha sido el problema de "sobrecarga de comunicaciones" de la criptografía. Cada xVM también puede usar una arquitectura de base de datos diferente, ya sea RocksDB, LevelDB, o una base de datos (a)sync personalizada creada desde cero. La pieza de interoperabilidad funciona a través de un “sistema de instantáneas” (un algoritmo similar al Algoritmo Chandy-Lamport) donde las cadenas pueden hacer la transición de forma asincrónica a un nuevo bloque sin requerir que el sistema se detenga. En cuanto a la seguridad, se pueden enviar pruebas de fraude en el caso de que una transición de estado haya sido incorrecta. Con este diseño, su objetivo es minimizar el tiempo de ejecución mientras se maximiza el rendimiento general de la red.

Capa N

En línea con estos avances en personalización, Movement Labsaprovecha el lenguaje Move — originalmente diseñado por Facebook y utilizado en redes como Aptos y Sui — para su VM / ejecución. Move tiene ventajas estructurales en comparación con otros marcos, principalmente seguridad y flexibilidad/expresividad para desarrolladores, históricamente dos de los principales problemas al construir onchain utilizando lo que existe hoy. Es importante destacar que los desarrolladores también pueden simplemente escribe Solidity y despliega en Movimiento — para hacer esto posible, Movement creó un tiempo de ejecución EVM totalmente compatible con el bytecode que también funciona con la pila Move. Su rollup, M2, aprovecha la paralelización de BlockSTM que permite un rendimiento mucho mayor al tiempo que aún puede acceder al foso de liquidez de Ethereum (históricamente BlockSTM se ha utilizado únicamente en alt L1s como Aptos, que obviamente carecen de compatibilidad con EVM).

MegaETHtambién está impulsando el progreso en el espacio de ejecución, especialmente a través de su motor de paralelización y base de datos en memoria donde el secuenciador puede almacenar todo el estado en memoria. En el lado arquitectónico, aprovechan:

• Compilación de código nativo que permite que el L2 sea mucho más eficiente (si el contrato requiere más capacidad de cálculo, los programas pueden obtener una mejora masiva de velocidad; si no requiere mucha capacidad de cálculo, todavía hay una mejora de velocidad de ~2x+).
• Producción de bloques relativamente centralizada, pero validación y verificación descentralizadas de bloques.
• Sincronización eficiente del estado, donde los nodos completos no necesitan volver a ejecutar transacciones, pero sí necesitan estar al tanto del delta de estado para poder aplicarlo a su base de datos local.
• Estructura de actualización del árbol de Merkle (donde normalmente la actualización del árbol es intensiva en almacenamiento), donde su enfoque es una nueva estructura de datos de trie que es eficiente en memoria y disco. La computación en memoria les permite comprimir el estado de la cadena dentro de la memoria, por lo que cuando se ejecutan las transacciones, no tienen que ir al disco, solo a la memoria.

Otro diseño más que se ha explorado y se ha iterado recientemente como parte del conjunto modular es la agregación de pruebas, definida como un probador que crea una única prueba sucinta de múltiples pruebas sucintas. Primero veamos las capas de agregación en su conjunto y sus tendencias históricas y actuales en cripto.

Asignando valor a las capas de agregación

Históricamente, en mercados no criptográficos, los agregadores han obtenido una cuota de mercado más pequeña que las plataformas o mercados:

CJ Gustafson

Si bien no estoy seguro de si esto se aplica a las criptomonedas en todos los casos, definitivamente es cierto para los intercambios descentralizados, puentes y protocolos de préstamos.

Por ejemplo, la capitalización de mercado combinada de 1inch y 0x (dos agregadores de dex básicos) es de aproximadamente $1bb, una pequeña fracción de los ~$7.6bb de Uniswap. Esto también se aplica a los puentes: los agregadores de puentes como Li.Fi y Socket/Bungee parecen tener menos participación en el mercado en comparación con plataformas como Across. Mientras Socket soporta 15 puentes diferentes, en realidad tienen un volumen de puente total similar al de Across (Socket — $2.2bb, A través -$1.7bb), y Across solo representa apequeña fracción del volumen en Socket/Bungee recientemente.

En el espacio de préstamos, Yearn Financefue el primero de su tipo como un protocolo agregador de rendimiento de préstamos descentralizados, su capitalización de mercado es actualmente~$250mm. En comparación, productos de plataforma como Aave ( ~$1.4bb) y Compound (~$560mm) han comandado una valoración más alta y más relevancia con el tiempo.

Los mercados tradicionales funcionan de manera similar. Por ejemplo, ICE (Intercontinental Exchange) US and CME Groupcada uno tiene una capitalización de mercado de ~$75 mil millones, mientras que los "agregadores" como Charles Schwab y Robinhood tienen una capitalización de mercado de ~$132 mil millones y ~$15 mil millones, respectivamente. Dentro de Schwab, querutas a través de ICE y CMEentre muchos otros lugares, el volumen proporcional que fluye a través de ellos no es proporcional a esa parte de su capitalización de mercado. Robinhood tiene aproximadamente 119 contratos de opciones de 119mm por mes, mientras que los ICE están alrededor de ~35 mm— y los contratos de opciones ni siquiera son una parte central del modelo de negocio de Robinhood. A pesar de esto, ICE tiene un valor ~5 veces mayor que Robinhood en los mercados públicos. Por lo tanto, Schwab y Robinhood, que actúan como interfaces de agregación a nivel de aplicación para enrutamiento del flujo de órdenes de clientes a través de varios lugares, no tienen valoraciones tan altas como ICE y CME a pesar de sus volúmenes respectivos.

Nosotros como consumidores simplemente asignamos menos valor a los agregadores.

Esto puede no ser válido en cripto si las capas de agregación están integradas en un producto/plataforma/cadena. Si los agregadores están integrados directamente en la cadena, obviamente esa es una arquitectura diferente y una que me intriga ver cómo se desarrolla. Un ejemplo es AggLayer de Polygon, donde los desarrolladores pueden conectar fácilmente su L1 y L2 en una red que agrega pruebas y permite una capa de liquidez unificada a través de cadenas que utilizan el CDK.

AggLayer

Este modelo funciona de manera similar a Capa de interoperabilidad Nexus de Avail, que incluye un mecanismo de subasta de agregación de pruebas y secuenciador, lo que hace que su producto DA sea mucho más robusto. Al igual que AggLayer de Polygon, cada cadena o rollup que se integra con Avail se vuelve interoperable dentro del ecosistema existente de Avail. Además, Avail agrupa datos de transacciones ordenados de varias plataformas blockchain y rollups, incluidos Ethereum, todos los rollups de Ethereum, cadenas de Cosmos, rollups de Avail, rollups de Celestia y diferentes construcciones híbridas como Validiums, Optimiums y parachains de Polkadot, entre otros. Los desarrolladores de cualquier ecosistema pueden construir sin permisos en la capa DA de Avail utilizando Avail Nexus, que se puede utilizar para la agregación de pruebas y mensajería interecosistémica.

Avail Nexus

Nebrase enfoca específicamente en la agregación de pruebas y liquidación, donde pueden agregarse a través de diferentes sistemas de prueba, por ejemplo, agregando pruebas del sistema xyz y pruebas del sistema abc de tal manera que se tenga agg_xyzabc (en lugar de agregar dentro de los sistemas de prueba de manera que se tenga agg_xyz y agg_abc). Esta arquitectura utilizaUniPlonK, que estandariza el trabajo de los verificadores para familias de circuitos, lo que hace que la verificación de pruebas en diferentes circuitos PlonK sea mucho más eficiente y factible. En su núcleo, utiliza las propias pruebas de conocimiento cero (SNARKs recursivos) para escalar la pieza de verificación, que suele ser el cuello de botella en estos sistemas. Para los clientes, el proceso de liquidación de la “última milla” se hace mucho más fácil porque Nebra maneja toda la agregación y liquidación por lotes, donde los equipos solo necesitan cambiar una llamada de contrato de API.

AstriaEstá trabajando en diseños interesantes sobre cómo su secuenciador compartido puede trabajar con la agregación de pruebas también. Dejan el lado de la ejecución a los rollups mismos que ejecutan software de capa de ejecución sobre un espacio de nombres dado de un secuenciador compartido, esencialmente solo la "API de ejecución" que es una forma para que el rollup acepte datos de capa de secuenciación. También pueden agregar fácilmente soporte para pruebas de validez aquí para asegurar que un bloque no violó las reglas de la máquina de estado EVM.

Josh Bowen

Aquí, un producto como Astria sirve como el flujo #1 → #2 (txs no ordenadas → bloque ordenado), y la capa de ejecución / nodo de rollup es #2 → #3, mientras que un protocolo como Nebrasirve como la última milla #3 → #4 (bloque ejecutado → prueba concisa). Nebra (o Capa Aligned) también podría ser un quinto paso teórico donde las pruebas se agregan y luego se verifican después. Sovereign Labs también está trabajando en un concepto similar al último paso, donde la agregación de pruebas basada en el puente está en el corazón de su arquitectura.

Laboratorios Soberanos

En conjunto, algunas capas de aplicación son comenzando a poseer la infraestructura subyacente, en parte porque @maven11research"comoditizar sus complementos">permanecer solo como una aplicación de alto nivel puede tener problemas de incentivos y altos costos de adopción de usuarios si no controlan la plataforma subyacente. Por otro lado, a medida que los costos de infraestructura son continuamente reducidos por la competencia y los avances tecnológicos, el gasto para aplicaciones/cadenas de aplicaciones@maven11research"comoditizar sus complementos">integrarse con componentes modulares se está volviendo mucho más factible. Creo que esta dinámica es mucho más poderosa, al menos por ahora.

Con todas estas innovaciones — capa de ejecución, capa de liquidación, agregación — se hace mucho más posible lograr mayor eficiencia, integraciones más fáciles, interoperabilidad más fuerte y costos más bajos. Realmente, todo esto conduce a mejores aplicaciones para los usuarios y a una mejor experiencia de desarrollo para los creadores. Esta es una combinación ganadora que conduce a más innovación — y a una mayor velocidad de innovación — en general, y espero con interés ver qué se desarrolla.

Descargo de responsabilidad：

1. Este artículo ha sido reimpreso de [Gatebridgeharris]. Todos los derechos de autor pertenecen al autor original [BRIDGET HARRIS]. If there are objections to this reprint, please contact the Gate Learnequipo, y lo manejarán rápidamente.
2. Descargo de responsabilidad: Las opiniones expresadas en este artículo son únicamente del autor y no constituyen ningún consejo de inversión.
3. Las traducciones del artículo a otros idiomas son realizadas por el equipo de Gate Learn. A menos que se mencione, está prohibido copiar, distribuir o plagiar los artículos traducidos.