Los costos ocultos de los sistemas modulares

Nota del editor: Esta publicación es un sucesor espiritual de La escalabilidad técnica crea escalabilidad social. Haga clic aquí para leerla.

En los últimos dos años, el debate sobre la escala se ha reducido y centrado en la cuestión central de modularidad frente a integración.

(Tenga en cuenta que el discurso en criptomonedas a menudo combina sistemas "monolíticos" e "integrados". Hay una rica historia de debate en tecnología en los últimos 40 años sobre sistemas integrados frente a sistemas modulares en cada capa de la pila. La encarnación criptográfica de este diálogo debe enmarcarse a través de la misma lente; esto está lejos de ser un nuevo debate).

Al pensar en modularidad frente a integración, la decisión de diseño más importante que puede tomar una cadena es a cuánta complejidad exponer la pila para los desarrolladores de aplicaciones. Los clientes de cadenas de bloques son desarrolladores de aplicaciones, por lo que las decisiones de diseño deben considerarse en última instancia para ellos.

Hoy en día, la modularidad es en gran medida aclamada como la principal forma en que las cadenas de bloques escalarán. En esta publicación, cuestionaré ese supuesto desde los primeros principios, sacaré a la luz los mitos culturales y los costos ocultos de los sistemas modulares, y compartiré las conclusiones que he desarrollado en los últimos seis años de contemplar este debate.

Los sistemas modulares aumentan la complejidad de los desarrolladores

Por mucho, el mayor costo oculto de los sistemas modulares es la complejidad del desarrollador.

Los sistemas modulares aumentan sustancialmente la complejidad que los desarrolladores de aplicaciones deben gestionar, tanto en el contexto de sus propias aplicaciones (complejidad técnica) como en el contexto de la interfaz con otras aplicaciones y piezas de estado (complejidad social).

En el contexto de los sistemas de criptomonedas, las cadenas de bloques modulares que vemos hoy en día permiten teóricamente más especialización, pero a expensas de crear nueva complejidad. Esta complejidad, tanto técnica como social, está siendo enviada a la pila de los desarrolladores de aplicaciones, lo que en última instancia hace que sea más difícil de construir.

Por ejemplo, considere el OP stack, que parece ser el marco modular líder a partir de agosto de 2023. El OP stack obliga a los desarrolladores a optar por una Ley de cadenas (que acarrean mucha complejidad social, como sugiere el nombre), o a bifurcar y administrar el OP stack de forma independiente. Ambas opciones crean enormes cantidades de complejidad descendente para los constructores. Si se desvían y siguen su propia ruta, ¿van a recibir soporte técnico de otros actores del ecosistema (CEX, rampas de acceso fiat, etc.) que tienen que incurrir en costos para cumplir con un nuevo estándar técnico? Si opta por la Ley de las cadenas, ¿qué reglas y restricciones se impone hoy y, lo que es más importante, mañana?

Fuente: El modelo OSI

Los sistemas operativos modernos (OS) son sistemas grandes y complejos que comprenden cientos de subsistemas. Los sistemas operativos modernos manejan las capas 2-6 en la imagen de arriba. Ese es el ejemplo por excelencia de la integración de componentes modulares para gestionar la complejidad que se expone en la pila a los desarrolladores de aplicaciones. Los desarrolladores de aplicaciones no quieren lidiar con nada por debajo de la capa 7, y esa es precisamente la razón por la que existen los sistemas operativos: los sistemas operativos administran la complejidad de las capas siguientes para que los desarrolladores de aplicaciones no tengan que hacerlo. Por lo tanto, la modularidad en sí misma no debe ser el objetivo, sino más bien un medio para un fin.

Todos los principales sistemas de software en el mundo de hoy en día (backends en la nube, sistemas operativos, motores de bases de datos, motores de juegos, etc.) están altamente integrados y simultáneamente compuestos de muchos subsistemas modulares. Los sistemas de software tienden a integrar las horas extras para maximizar el rendimiento y minimizar la complejidad de los desarrolladores. Las cadenas de bloques no son diferentes.

(A un costado, el avance principal de Ethereum estaba reduciendo la complejidad que surgió de la era de las bifurcaciones de Bitcoin en 2011-2014. Los defensores de los modelos modulares con frecuencia destacan el modelo de interconexión de sistemas abiertos (OSI) para argumentar que la disponibilidad de datos (DA) y la ejecución deben separarse; sin embargo, este argumento es ampliamente malinterpretado. Una comprensión correcta de primer orden de los problemas en cuestión conduce a la conclusión opuesta: el uso de OSI como análogo es un argumento a favor de los sistemas integrados en lugar de los modulares.)

Las cadenas modulares no ejecutan código más rápido

Por diseño, la definición común de "cadenas modulares" es la separación de disponibilidad de datos (DA) y ejecución: un conjunto de nodos realiza DA, mientras que otro conjunto (o conjuntos) realiza la ejecución. Los conjuntos de nodos no tienen que tener ninguna superposición en absoluto, pero pueden tenerla.

En la práctica, separar DA y ejecución no mejora inherentemente el rendimiento de ninguno de los dos; al final del día, alguna pieza de hardware en algún lugar del mundo tiene que realizar DA, y alguna pieza de hardware en algún lugar tiene que realizar la ejecución. Separar esas funciones no aumenta el rendimiento de ninguna de las dos. Sin embargo, la separación puede reducir el costo de la computación, pero solo al centralizar la ejecución.

Una vez más, vale la pena reiterar esto: independientemente de la arquitectura modular frente a la integrada, alguna pieza de hardware en algún lugar tiene que hacer el trabajo, y empujar DA y ejecución para separar piezas de hardware no acelera intrínsecamente ni aumenta la capacidad total del sistema.

Algunos argumentan que la modularidad permite la proliferación de muchos EVM para ejecutarse en paralelo como roll-ups, lo que permite la ejecución para escalar horizontalmente. Si bien esto es teóricamente correcto, este comentario en realidad destaca las limitaciones del EVM como un procesador de un solo hilo en lugar de abordar la premisa fundamental de separar DA y ejecución en el contexto de escalar el rendimiento total del sistema.

La modularidad por sí sola no aumenta el rendimiento.

La modularidad aumenta los costos de transacción para los usuarios

Por definición, cada L1 y L2 es un libro de contabilidad de activos distinto con su propio estado. Esas piezas de estado separadas pueden comunicarse, aunque con más latencia y con más complejidad de desarrolladores y usuarios (es decir, a través de puentes, como LayerZero y Wormhole)).

Cuantos más libros de contabilidad de activos haya, más fragmentos de todas las cuentas será el estado global. Esto es unilateralmente terrible para las cadenas y los usuarios en muchos frentes. El estado fragmentado resulta en

1. Menos liquidez y, por lo tanto, mayores diferenciales para los tomadores
2. Más consumo total de gas (ya que una transacción de cadena cruzada por definición requiere al menos dos transacciones en al menos dos libros de contabilidad de activos).
3. Más cálculos duplicados en los libros de contabilidad de activos (lo que reduce el rendimiento total del sistema): cuando el precio de ETH-USDC se mueve en Binance o Coinbase, las oportunidades de arbitraje están disponibles en cada grupo de ETH-USDC en todos los libros de contabilidad de activos. (Puede imaginar fácilmente un mundo en el que hay más de 10 transacciones en varios libros de contabilidad de activos cada vez que el precio de ETH-USDC se mueve en Binance o Coinbase. Mantener los precios en línea como resultado de un estado fragmentado es un uso extremadamente ineficiente del espacio de bloques).

Es importante reconocer que la creación de más libros de contabilidad de activos complica explícitamente los costos a lo largo de todas estas dimensiones, especialmente en lo que respecta a DeFi.

La entrada principal a DeFi es el estado en cadena (también conocido como quién es el propietario de qué activos). A medida que los equipos lanzan cadenas de aplicaciones / roll-ups, naturalmente fragmentarán el estado, lo que es estrictamente malo para DeFi, tanto en términos de administración de la complejidad para los desarrolladores de aplicaciones (puentes, billeteras, latencia, MEV de cadena cruzada, etc.) como para los usuarios (diferenciales más amplios, tiempos de liquidación más largos).

DeFi funciona mejor cuando los activos se emiten en un solo libro de contabilidad de activos y el comercio se produce dentro de una sola máquina de estado. Cuantos más libros de contabilidad de activos, más complejidad deben gestionar los desarrolladores de aplicaciones y más costos deben soportar los usuarios.

Los roll ups de aplicaciones no crean nuevas oportunidades de monetización para los desarrolladores

Los defensores de las cadenas de aplicaciones / rollups argumentan que los incentivos llevarán a los desarrolladores de aplicaciones a construir roll ups en lugar de en un L1 o L2 para que puedan capturar MEV de nuevo a sus propios tokens. Sin embargo, este pensamiento es defectuoso porque ejecutar un roll-up de aplicaciones no es la única manera de capturar MEV de nuevo a un token de capa de aplicación y, en la mayoría de los casos, no la manera óptima. Los tokens de capa de aplicación pueden capturar MEV de nuevo a sus propios tokens simplemente codificando la lógica en contratos inteligentes en una cadena de propósito general. Consideremos algunos ejemplos:

1. Liquidaciones — Si los DAO compuestos o de Aave quieren capturar alguna parte del MEV que va a los bots de liquidación, pueden actualizar sus respectivos contratos para pagar un cierto porcentaje de la tarifa que actualmente va al liquidador para dirigirse al DAO. Una nueva cadena / roll up no es necesaria.
2. Oracles — Los tokens de Oracle pueden capturar MEV al ofrecer back-running como servicio. Además de una actualización de precios, un oráculo puede agrupar cualquier transacción arbitraria en cadena que se garantice que se ejecutará inmediatamente después de la actualización de precios. Como tal, los oráculos pueden capturar MEV al ofrecer back-running como servicio a los buscadores, constructores de bloques, etc.
3. NFT mints — La generación de monedas de NFT están plagadas de bots de scalping. Esto puede mitigarse fácilmente simplemente codificando una reparticipación de ganancias en disminución. Por ejemplo, si alguien intenta revender su NFT dentro de las dos semanas de una NFT mint, el 100% de los ingresos pueden volver a capturarse al creador de la moneda o DAO. El porcentaje puede variar con el tiempo.

No hay una respuesta universal para capturar MEV a un token de capa de aplicación. Sin embargo, pensándolo un poco, los desarrolladores de aplicaciones pueden capturar fácilmente MEV de nuevo a sus propios tokens en cadenas de propósito general. Lanzar una cadena completamente nueva es simplemente innecesario, crea complejidad técnica y social adicional para que los desarrolladores la administren y crea más desafíos de billetera y liquidez para los usuarios.

Los roll ups de aplicaciones no abordan la congestión entre aplicaciones

Muchos han argumentado que las cadenas de aplicaciones / roll ups garantizan que una aplicación determinada no se vea afectada por un pico de gas causado por otra actividad en cadena, como una popular NFT mint. Esta opinión es parcialmente correcta, pero en su mayor parte incorrecta.

La razón por la que esto ha sido un problema históricamente es principalmente una función de la naturaleza de un solo hilo de EVM, en lugar de a raíz de la falta de separación de DA y ejecución. Todos los L2 pagan tarifas al L1, y las tarifas de L1 pueden aumentar en cualquier momento. Durante el frenesí de monedas de meme a principios de este año, las tarifas de negociación en Arbitrum y Optimism superaron los $ 10. Más recientemente, las tarifas en Optimism aumentaron a raíz del lanzamiento de Worldcoin.

La única solución para los picos de tarifas es tanto: 1) maximizar el DA de L1 y 2) hacer que los mercados de tarifas sean lo más granulares posibles:

Si los recursos del L1 están restringidos, los picos de uso en varios L2 se filtrarán hasta el L1, lo que impondrá mayores costos en todos los demás L2. Por lo tanto, la cadena de aplicaciones / roll ups no son inmunes a los picos de gas.

La coexistencia de muchos EVM L2 es solo una forma rudimentaria de tratar de localizar los mercados de tarifas. Es mejor que poner todo en un solo EVM L1, pero no aborda el problema central desde los primeros principios. Cuando reconoce que la solución es localizar los mercados de tarifas, el punto final lógico son los mercados de tarifas por pieza de estado (en lugar de los mercados de tarifas por L2).

Otras cadenas ya han llegado a esta conclusión. Tanto Solana como Aptos localizan naturalmente los mercados de tarifas. Esto requirió una tonelada de trabajo de ingeniería durante muchos años para sus respectivos entornos de ejecución. La mayoría de los defensores de los módulos subestiman gravemente la importancia y la dificultad de resolver los problemas de ingeniería difíciles que hacen posibles los mercados de tarifas hiperlocales.

Fuente: https://blog.labeleven.dev/why-solana

Al lanzar muchos libros de contabilidad de activos, los desarrolladores están aumentando naturalmente la complejidad técnica y social sin desbloquear ganancias de rendimiento reales, incluso en momentos en que otras aplicaciones están impulsando un mayor volumen.

La flexibilidad está sobrevalorada

Los defensores de la cadena modular argumentan que las arquitecturas modulares son más flexibles. Esta declaración es obviamente cierta. Pero no está claro que sea relevante.

Durante seis años he estado tratando de encontrar desarrolladores de aplicaciones que necesiten flexibilidad significativa que los L1 de propósito general no pueden proporcionar. Pero hasta ahora, fuera de tres casos de uso muy específicos, no ha habido una articulación clara de por qué la flexibilidad es importante, ni cómo ayuda directamente con el escalado. Los tres casos de uso específicos que he identificado en los que la flexibilidad es importante son:

• Aplicaciones que aprovechan el estado "caliente". El estado caliente es un estado que es necesario para la coordinación en tiempo real de algún conjunto de acciones, pero en última instancia no se compromete permanentemente en cadena. Algunos ejemplos de estado caliente:
  • Órdenes de límite en un DEX, como dYdX y Sei (muchas órdenes de límite se cancelan en última instancia).
  • Coordinación en tiempo real y reconocimiento de la entrega de flujo de órdenes en dFlow (dFlow es un protocolo para facilitar un mercado de flujo de órdenes descentralizado entre creadores de mercado y billeteras).
  • Oráculos como Pyth, que es un oráculo de baja latencia. Pyth está en vivo como una cadena SVM independiente. Pyth produce tantos datos, que el equipo central de Pyth decidió que sería mejor enviar actualizaciones de precios de alta frecuencia a una cadena independiente, y luego unir los precios a otras cadenas según sea necesario utilizando Wormhole.
• Cadenas que modifican el consenso. Los mejores ejemplos de esto son Osmosis (en el que todas las transacciones se cifran antes de enviarse a los validadores), y Thorchain (que prioriza las transacciones dentro de un bloque en función de las tarifas pagadas).
• Infraestructura que necesita aprovechar los esquemas de firma de umbral (TSS) de alguna manera. Algunos ejemplos de esto son Sommelier, Thorchain, Osmosis, Wormhole, y Web3Auth.

Todos los ejemplos enumerados anteriormente, a excepción de Pyth y Wormhole, se construyen utilizando el SDK de Cosmos y se ejecutan como cadenas independientes. Esto dice mucho sobre la calidad y extensibilidad del SDK de Cosmos para los tres casos de uso: sistemas de estado caliente, modificación de consenso y esquema de firma de umbral (TSS).

Sin embargo, la mayoría de los elementos identificados en las tres secciones anteriores no son aplicaciones. Son infraestructuras.

Pyth y dFlow no son aplicaciones, son infraestructura. Sommelier (la cadena, no el front-end del optimizador de rendimiento), Wormhole, Sei y Web3Auth no son aplicaciones, son infraestructura. De aquellas que son aplicaciones orientadas al usuario, todas son de un tipo específico: un DEX (dYdX, Osmosis, Thorchain).

He estado preguntando a los defensores de Cosmos y Polkadot durante seis años sobre los casos de uso que se desbloquean a partir de la flexibilidad que proporcionan. Creo que hay suficientes datos para inferir algunas cosas:

En primer lugar, los ejemplos de infraestructura no deben existir como roll ups porque producen demasiados datos de bajo valor (por ejemplo, estado caliente, y todo el sentido del estado caliente es que los datos no se comprometen de nuevo al L1), o porque realizan alguna función que es intencionalmente ortogonal a las actualizaciones de estado en un libro de contabilidad de activos (por ejemplo, todos los casos de uso de TSS).

En segundo lugar, el único tipo de aplicación que he visto cambiar significativamente el diseño del sistema central es un DEX. Esto tiene sentido porque los DEX están plagados de MEV, y porque las cadenas de propósito general por definición no pueden igualar la latencia de los CEX. El consenso es fundamental para la calidad de ejecución del comercio y el MEV, y por lo tanto, naturalmente hay muchas oportunidades para la innovación en los DEX basados en hacer cambios en el consenso. Sin embargo, como se señaló anteriormente en este ensayo, la entrada principal en un DEX spot son los activos que se comercializan. Los DEX compiten por activos y, por lo tanto, por los emisores de activos. En este marco, es poco probable que las cadenas DEX independientes tengan éxito, porque la variable principal en la que piensan los emisores de activos en el momento de la emisión de activos no es el MEV relacionado con el DEX, sino la funcionalidad de contrato inteligente de propósito general y la incorporación de esa funcionalidad en la aplicación respectiva del desarrollador de aplicaciones.

Sin embargo, este encuadre de los DEX que compiten por los emisores de activos es en su mayoría irrelevante para los DEX de derivados, que dependen principalmente de los colaterales del USDC y los precios de los oráculos, y también que inherentemente deben bloquear los activos del usuario para garantizar las posiciones de los derivados. Como tal, en la medida en que las cadenas DEX independientes tengan sentido, es más probable que funcionen para DEX centrados en derivados como dYdX y Sei.

(Nota: Si está construyendo un nuevo tipo de infraestructura que no está capturada por las categorías anteriores, o una aplicación orientada al consumidor que realmente requiere más flexibilidad de lo que los L1 integrados de propósito general pueden soportar, ¡comuníquese con nosotros! Ha tomado seis años destilar lo anterior, y estoy seguro de que esta lista está incompleta.)

Por el contrario, consideremos las aplicaciones que existen hoy en día en L1 integrados de propósito general. Algunos ejemplos: Juegos; Audius; Sistemas DeSoc como Farcaster y Lens; Protocolos DePIN como Helium, Hivemapper, Render Network, DIMO, y Daylight; Sound, intercambios NFT y muchos más. Ninguno de estos se beneficia particularmente de la flexibilidad que viene con la modificación del consenso. Todos tienen un conjunto de requisitos bastante simple, obvio y común de sus respectivos libros de contabilidad de activos: tarifas bajas, baja latencia, acceso a DEX puntuales, acceso a monedas estables y acceso a rampas fiat-on como CEX.

Creo que tenemos suficientes datos ahora para decir con cierto grado de confianza que la gran mayoría de las aplicaciones orientadas al usuario tienen el mismo conjunto común de requisitos que se enumeran en el párrafo anterior. Si bien algunas aplicaciones pueden optimizar para otras variables en el margen con personalizaciones en la pila, las compensaciones que vienen con esas personalizaciones generalmente no valen la pena (más puente, menos soporte de billetera, menos soporte de proveedor de índices / consultas, menor fiat directo en rampas, etc.).

El lanzamiento de nuevos libros de contabilidad de activos es una forma de lograr flexibilidad, pero rara vez agrega valor, y casi siempre crea complejidad técnica y social con ganancias mínimas para los desarrolladores de aplicaciones.

No es necesario rehacer para escalar DA

También escuchará a los defensores de los módulos hablar sobre reiniciar en el contexto de la escala. Este es el argumento más especulativo que hacen los defensores de la cadena modular, pero vale la pena abordarlo.

Establece aproximadamente que debido a la recreación (por ejemplo, a través de sistemas como EigenLayer), el ecosistema de criptomonedas en su conjunto puede reiniciar ETH un número infinito de veces para alimentar un número infinito de capas de DA (por ejemplo, EigenDA) y capas de ejecución. Por lo tanto, la escalabilidad se resuelve en todos los aspectos al tiempo que garantiza la acumulación de valor para ETH.

Aunque hay una tremenda cantidad de incertidumbre entre el status quo y ese futuro teórico, demos por sentado que todos los sumidores en capas funcionan como se anuncia.

El DA de Ethereum hoy es de aproximadamente ~ 83 KB/s. Con EIP 4844 a finales de este año, que aproximadamente se duplica a ~ 166 KB/s. EigenDA agrega 10 MB/s adicionales, aunque con un conjunto diferente de sumpciones de seguridad (no todos los ETH se reiniciarán en EigenDA).

Por el contrario, Solana hoy ofrece un DA de aproximadamente 125 MB/s (32,000 fragmentos por bloque, 1,280 bytes por fragmento, 2.5 bloques por segundo). Solana es mucho más eficiente que Ethereum y EigenDA debido a su Protocolo de propagación de bloques de turbina, que ha estado en producción durante 3 años. Además, el DA de Solana escala con el tiempo con Ley de Nielsen, que continúa sin disminuir (a diferencia de la Ley de Moore, que para fines prácticos murió por la computación de un solo hilo hace una década)).

Hay muchas maneras de escalar DA con reinicio y modularidad, pero estos mecanismos son simplemente innecesarios hoy en día e introducen una complejidad técnica y social significativa.

Construir Para Desarrolladores De Aplicaciones

Después de contemplar esto durante años, he llegado a la conclusión de que la modularidad no debe ser un objetivo en sí mismo.

Las cadenas de bloques deben servir a sus clientes, es decir, los desarrolladores de aplicaciones, y como tal, las cadenas de bloques deben abstraer la complejidad a nivel de infraestructura para que los emprendedores puedan centrarse en construir aplicaciones de clase mundial.

Los bloques de construcción modulares son grandes. Pero la clave para construir tecnologías ganadoras es averiguar qué piezas de la pila integrar y qué piezas dejar para los demás. Y tal como están ahora, las cadenas que integran DA y ejecución ofrecen inherentemente experiencias de usuario final y desarrollador más simples, y en última instancia proporcionarán un mejor sustrato para las aplicaciones mejores en clase.

Gracias a Alana Levin, Tarun Chitra, Karthik Senthil, Mert Mumtaz, [Ceteris](https: //twitter.com/ceterispar1bus "Ceteris"), Jon Charbonneau, John Robert Reed, y Ani Pai por proporcionar comentarios sobre esta publicación.