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

El espacio de secuenciador compartido no solo tiene muchos proyectos compitiendo por la cuota de mercado — Espresso, Astria, Radio, Roma, y Madarapara nombrar algunos — pero también incluye proveedores de RaaS como Caldera y Conduitquienes desarrollan secuenciadores compartidos para rollups que se basan en ellos. Estos proveedores de RaaS pueden ofrecer 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 muchos rollups que optan 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 de DA, que básicamente opera como un oligopolio compuesto por Celestia, 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 elección del "incumbente" - Ethereum - u optan por una de las capas de DA establecidas según el tipo de tecnología y alineación que están buscando. Si bien usar una capa de DA es un gran ahorro de costos, externalizar la pieza del secuenciador no es una elección tan obvia (desde el punto de vista de las tarifas, 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 un producto básico, pero hemos visto en el cripto que los fosos de liquidez súper fuertes combinados con una tecnología subyacente única (difícil de replicar) hacen que sea mucho más difícil commoditizar una capa en el stack. Independientemente de estos debates y dinámicas, hay muchos productos de DA y secuenciadores en producción (en resumen, con parte del stack 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 iterarse de nuevas maneras que se alinean bien con el resto del conjunto modular.

Recap on execution + settlement layer relationship

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. Esto es, por naturaleza, el diseño opuesto del 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 perder tiempo integrando manualmente cada parte del stack modular. Los inconvenientes, por supuesto, son estar aislado de un sentido de liquidez, no poder elegir capas modulares que se ajusten mejor a su diseño y ser demasiado caro.

Otros equipos optan por construir L1s extremadamente específicas para una funcionalidad principal o aplicación. Un ejemplo es Hyperliquid, que ha construido un L1 diseñado específicamente para su aplicación nativa principal, una plataforma de trading perpetuals. Aunque sus usuarios necesitan hacer un puente desde Arbitrum, su arquitectura central no depende del Cosmos SDK u otros marcos, por lo que puede serpersonalizado 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 aún algo presente) fueron las alt-L1 de propósito general donde básicamente la única característica que superaba a Ethereum era una mayor capacidad de procesamiento. Eso significaba que históricamente, los proyectos básicamente tenían que optar por construir su propia alt L1 desde cero si querían mejoras sustanciales de rendimiento, en su mayoría porque la tecnología aún no estaba lista en Eth mismo. Y históricamente, esto simplemente significaba incrustar nativamente 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.

Ahora mismo, también estamos viendo más mezcla y combinación de diferentes MV (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)síncrona personalizada hecha 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 necesidad de que el sistema se detenga. En cuanto a la seguridad, se pueden presentar pruebas de fraude en caso de que una transición de estado sea incorrecta. Con este diseño, su objetivo es minimizar el tiempo de ejecución al mismo tiempo que 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 en cadena utilizando lo que existe hoy. Es importante destacar que los desarrolladores también pueden simplemente escribe Solidity y despliega en MovementPara 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 manteniendo la capacidad de 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 la capa de ejecución, especialmente a través de su motor de paralelización y su 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 es más intensivo en cómputo, los programas pueden obtener una mejora masiva de velocidad, si no es muy intensivo en cómputo, 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 de árbol de Merkle (donde normalmente la actualización del árbol es intensiva en almacenamiento), donde su enfoque es una nueva estructura de datos de árbol 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.

Un diseño más que se ha explorado e iterado recientemente como parte del stack modular es la agregación de pruebas, definida como un probador que crea una única prueba sucinta de múltiples pruebas sucintas. Primero, echemos un vistazo a 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 ganado 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, es definitivamente cierto para los exchanges descentralizados, las bridges y los protocolos de préstamos.

Por ejemplo, la capitalización de mercado combinada de 1 pulgada y 0x (dos agregadores de dex básicos) es de aproximadamente $1 mil millones, una pequeña fracción de los ~$7.6 mil millones de Uniswap. Esto también se aplica a los puentes: agregadores de puentes como Li.Fi y Socket/Bungee parecen tener menos participación en el mercado en comparación con plataformas como Across. Si bien Socket admite 15 puentes diferentes, de hecho, tienen un volumen total de puente similar a Across (Socket — $2.2bb, A través —$1.7bb) y Across solo representa una pequeñ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 de agregador de rendimiento de préstamos descentralizado - su capitalización de mercado es actualmente~$250mm. En comparación, productos de plataforma como Aave ( ~$1.4bb) y compuesto (~$560mmhan comandado una valoración más alta y más relevancia con el tiempo.

Los mercados Tradfi operan de manera similar. Por ejemplo, ICE(Intercontinental Exchange) US yCME Groupcada uno tiene una capitalización de mercado de aproximadamente $75 mil millones, mientras que los "agregadores" como Charles Schwab y Robinhood tienen una capitalización de mercado de aproximadamente $132 mil millones y aproximadamente $15 mil millones, respectivamente. Dentro de Schwab, que rutas a través de ICE y CMEentre muchos otros lugares, el volumen proporcional que pasa por ellos no es proporcional a esa parte de su capitalización de mercado. Robinhood tiene aproximadamente Contratos de opciones de 119 mm por mes, mientras que los de ICE están alrededor ~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. Entonces, 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 mantenerse en cripto si las capas de agregación están incrustadas en un producto/plataforma/cadena. Si los agregadores están integrados estrechamente 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 en todas las cadenas que utilizan el CDK.

AggLayer

Este modelo funciona de manera similar a Capa de interoperabilidad Nexus de Avail, que incluye un mecanismo de agregación de pruebas y subasta de secuenciadores, 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 recopila 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 permiso en la capa DA de Avail mientras usan Avail Nexus, que se puede utilizar para la agregación de pruebas y mensajería entre ecosistemas.

Avail Nexus

Nebrase centra específicamente en la agregación y liquidación de pruebas, 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 tengas agg_xyzabc (en lugar de agregar dentro de sistemas de prueba de manera que tendrías agg_xyz y agg_abc). Esta arquitectura utiliza UniPlonK, 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 'última milla' se vuelve mucho más sencillo porque Nebra maneja toda la agregación y liquidación por lotes, donde los equipos solo necesitan cambiar una llamada de contrato de API.

Astria está trabajando en diseños interesantes sobre cómo su secuenciador compartido puede funcionar 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, básicamente 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 garantizar que un bloque no haya violado las reglas de la máquina de estado EVM.

Josh Bowen

Aquí, un producto como Astria sirve como el flujo #1 → #2 (transacciones desordenadas → bloque ordenado), y la capa de ejecución / nodo rollup es #2 → #3, mientras que un protocolo como Nebrasirve como el último paso #3 → #4 (bloque ejecutado → prueba sucinta). Nebra (oCapa alineada) también podría ser un quinto paso teórico donde las pruebas se agregan y luego se verifican después. Sovereign Labs 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 quedarse 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 base 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 que las aplicaciones/cadenas de aplicaciones se integren 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 más eficiencia, integraciones más fáciles, mayor interoperabilidad y costos más bajos. Realmente, lo que todo esto está llevando es a mejores aplicaciones para los usuarios y una mejor experiencia de desarrollo para los constructores. Esta es una combinación ganadora que conduce a más innovación, y una velocidad de innovación más rápida, en general, y estoy deseando ver qué se desarrolla.

Descargo de responsabilidad：

1. Este artículo es reimpreso de [Bridget Harris]. 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 resolverán rápidamente.
2. Descargo de responsabilidad: Las opiniones expresadas en este artículo son únicamente las 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 lo contrario, está prohibido copiar, distribuir o plagiar los artículos traducidos.