Kyle Samani, socio de Multicoin Capital, explica 7 razones por las que las cadenas de bloques modulares están sobrevaloradas.
Escrito por: Kyle Samani, socio, Multicoin Capital
Compilado por: Luffy, Foresight News
En los últimos dos años, el debate sobre la escalabilidad de blockchain se ha centrado en el tema central del "debate entre modularidad e integración".
Tenga en cuenta que las discusiones sobre criptomonedas a menudo combinan sistemas "únicos" e "integrados". El debate técnico sobre sistemas integrados versus sistemas modulares se remonta a 40 años. Esta conversación en el espacio de las criptomonedas debería enmarcarse a través del mismo lente que la historia, y esto está lejos de ser un debate nuevo.
Al considerar la modularidad frente a la integración, la decisión de diseño más importante que puede tomar una cadena de bloques es hasta qué punto la complejidad de la pila está expuesta a los desarrolladores de aplicaciones. Los clientes de blockchain son desarrolladores de aplicaciones, por lo que las decisiones de diseño finales deben tener en cuenta su perspectiva.
Hoy en día, la modularidad es ampliamente aclamada como la principal forma en que escalan las cadenas de bloques. En este artículo, desafiaré esta suposición desde los primeros principios, descubriré los mitos culturales y los costos ocultos de los sistemas modulares y compartiré las conclusiones que he extraído al reflexionar sobre este debate durante los últimos seis años.
Los sistemas modulares aumentan la complejidad del desarrollo
Con diferencia, el mayor coste oculto de los sistemas modulares es la complejidad añadida del proceso de desarrollo.
Los sistemas modulares aumentan enormemente 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 las interacciones con otras aplicaciones (complejidad social).
En el contexto de las criptomonedas, las cadenas de bloques modulares permiten teóricamente una mayor especialización, pero a costa de crear nueva complejidad. Esta complejidad (tanto de naturaleza técnica como social) se está transmitiendo a los desarrolladores de aplicaciones, lo que en última instancia dificulta la creación de aplicaciones.
Por ejemplo, considere la pila OP. Por ahora, parece ser el marco modular más popular. OP Stack obliga a los desarrolladores a elegir entre adoptar la Ley de Cadenas (que conlleva mucha complejidad social) o bifurcarlas y administrarlas por separado. Ambas opciones crean una complejidad posterior significativa para los constructores. Si decide bifurcarse, ¿recibirá soporte técnico de otros participantes del ecosistema (CEX, fiat on-ramp, etc.) que deben incurrir en costos para cumplir con los nuevos estándares tecnológicos? Si eliges seguir la Ley de las Cadenas, ¿qué reglas y limitaciones te impondrán hoy y mañana?
Fuente: modelo OSI
Los sistemas operativos (SO) modernos son sistemas grandes y complejos que contienen cientos de subsistemas. Los sistemas operativos modernos manejan las capas 2 a 6 en el diagrama anterior. Este es un ejemplo clásico de integración de componentes modulares para gestionar la complejidad de la pila expuesta a los desarrolladores de aplicaciones. Los desarrolladores de aplicaciones no quieren lidiar con nada por debajo de la capa 7, razón por la cual existen los sistemas operativos: el sistema operativo gestiona la complejidad de las capas inferiores para que los desarrolladores de aplicaciones puedan concentrarse en la capa 7. Por tanto, la modularidad no debería ser un objetivo en sí mismo, sino un medio para alcanzar un fin.
Todos los principales sistemas de software del mundo actual (backends en la nube, sistemas operativos, motores de bases de datos, motores de juegos, etc.) están altamente integrados y compuestos por muchos subsistemas modulares. Los sistemas de software tienden a estar altamente integrados para maximizar el rendimiento y reducir la complejidad del desarrollo. Lo mismo ocurre con la cadena de bloques.
Ethereum, por cierto, está reduciendo la complejidad que surgió durante la era de la bifurcación de Bitcoin de 2011-2014. Los defensores de la modularidad a menudo enfatizan el modelo de interconexión de sistemas abiertos (OSI), argumentando que la disponibilidad de datos (DA) y la ejecución deben separarse; sin embargo, este argumento es ampliamente mal entendido; Una comprensión adecuada del tema que nos ocupa lleva a la conclusión opuesta: el argumento de que OSI es un sistema integrado y no un sistema modular.
Las cadenas modulares no pueden ejecutar código más rápido
Por diseño, una definición común de "cadena modular" es la separación de la disponibilidad de datos (DA) y la ejecución: un conjunto de nodos es responsable de la DA, mientras que otro conjunto (o conjuntos) de nodos son responsables de la ejecución. Las colecciones de nodos no tienen por qué superponerse, pero pueden hacerlo.
En la práctica, separar DA y la ejecución no mejora inherentemente el rendimiento de ninguno de los dos; más bien, algún hardware en algún lugar del mundo debe realizar DA y algún hardware en algún lugar debe implementar la ejecución; Separar estas funciones no mejora el desempeño de ninguna de ellas. Si bien la separación puede reducir los costos computacionales, solo puede reducirse centralizando la ejecución.
Para reiterar: independientemente de la arquitectura modular o integrada, algún hardware tiene que hacer el trabajo en algún lugar, y separar DA y la ejecución en hardware separado no acelera ni aumenta inherentemente la capacidad general del sistema.
Algunos argumentan que la modularidad permite que múltiples EVM se ejecuten en paralelo de forma acumulativa, lo que permite que la ejecución escale horizontalmente. Si bien esto es teóricamente correcto, esta visión en realidad enfatiza las limitaciones del EVM como procesador de un solo subproceso en lugar de la premisa básica de separar DA y ejecución en el contexto de escalar el rendimiento general del sistema.
La modularidad por sí sola no mejora el rendimiento.
La modularidad aumenta los costos de transacción para los usuarios
Por definición, cada L1 y L2 es un libro de activos independiente con su propio estado. Estas partes separadas del estado pueden comunicarse, aunque con latencias de transacción más largas y más complejidad para los desarrolladores y usuarios (a través de puentes entre cadenas como LayerZero y Wormhole).
Cuantos más libros de contabilidad de activos haya, más fragmentado se vuelve el estado global de todas las cuentas. Esto es terrible tanto para las cadenas como para los usuarios de múltiples cadenas. La fragmentación del Estado puede traer una serie de consecuencias:
Liquidez reducida, lo que resulta en un mayor deslizamiento comercial;
Más consumo total de gas (las transacciones entre cadenas requieren al menos dos transacciones en al menos dos libros de contabilidad de activos);
Mayor conteo doble en los libros de contabilidad de activos (reduciendo así el rendimiento general del sistema): cuando el precio de ETH-USDC se mueve en Binance o Coinbase, surgirán oportunidades de arbitraje en cada grupo de ETH-USDC en todos los libros de contabilidad de activos (puede fácilmente imaginar un mundo donde cada vez que el precio ETH-USDC cambia en Binance o Coinbase, hay más de 10 transacciones en los distintos libros de contabilidad de activos. Mantener los precios consistentes en un estado fragmentado es extremadamente bajo en el uso eficiente del espacio de bloque.
Es importante darse cuenta de que la creación de más libros de contabilidad de activos aumenta significativamente los costos en todas estas dimensiones, especialmente las asociadas con DeFi.
El insumo principal de DeFi es el estado en la cadena (es decir, quién posee qué activos). Cuando los equipos lanzan cadenas/rollups de aplicaciones, naturalmente crean fragmentación de estado, lo cual es muy perjudicial para DeFi, tanto para los desarrolladores que administran la complejidad de la aplicación (puentes, billeteras, retrasos, MEV entre cadenas, etc.) como para los usuarios ( Deslizamientos, retrasos en las liquidaciones).
La condición más ideal para DeFi es que los activos se emitan en un único libro de contabilidad de activos y se negocien dentro de una única máquina de estado. Cuanto mayor sea el libro de activos, más complejidad deben gestionar los desarrolladores de aplicaciones y mayor el costo que deben soportar los usuarios.
App Rollup no creará nuevas oportunidades de monetización para los desarrolladores
Los defensores de AppChain/Rollup creen que los incentivos llevarán a los desarrolladores de aplicaciones a desarrollar Rollups en lugar de construir sobre L1 o L2 para que las aplicaciones puedan capturar el valor MEV por sí mismas. Sin embargo, esta idea es errónea porque ejecutar un paquete acumulativo de aplicaciones no es la única forma de capturar MEV nuevamente en tokens de la capa de aplicación y no es la mejor manera en la mayoría de los casos. Los tokens de la capa de aplicación pueden capturar MEV nuevamente en sus propios tokens simplemente codificando la lógica en contratos inteligentes en la cadena común. Consideremos algunos ejemplos:
Liquidación: si Compound o Aave DAO quieren capturar una parte del MEV que fluye hacia el robot de liquidación, pueden simplemente actualizar sus respectivos contratos para que una parte de las tarifas que actualmente fluyen hacia el liquidador se paguen a su propio DAO, sin necesidad. para una nueva cadena/Rollup.
Oracle: los tokens de Oracle pueden capturar MEV proporcionando servicios de respaldo. Además de las actualizaciones de precios, Oracles también puede agrupar cualquier transacción arbitraria en cadena que esté garantizada para ejecutarse inmediatamente después de una actualización de precios. Por lo tanto, los oráculos pueden capturar MEV proporcionando servicios de respaldo a buscadores, constructores de bloques, etc.
Acuñación de NFT: La acuñación de NFT está plagada de robots de especulación. Esto puede mitigarse fácilmente simplemente codificando la reasignación de ganancias decrecientes. Por ejemplo, si alguien intenta revender su NFT dentro de las dos semanas posteriores a su acuñación, el 100% de las ganancias volverá al emisor o a la DAO. Este porcentaje puede cambiar con el tiempo.
No existe una respuesta universal para capturar MEV en tokens de la capa de aplicación. Sin embargo, con un poco de reflexión, los desarrolladores de aplicaciones pueden capturar fácilmente MEV en sus propios tokens en la cadena universal. Lanzar una cadena completamente nueva es simplemente innecesario y traería complejidad técnica y social adicional a los desarrolladores, así como más preocupaciones de billetera y liquidez para los usuarios.
El paquete acumulativo de aplicaciones no puede resolver problemas de congestión entre aplicaciones
Muchos creen que Application Chain/Rollup garantiza que las aplicaciones no se vean afectadas por picos de gas causados por otras actividades en la cadena, como la popular acuñación de NFT. Esta opinión es en parte cierta, pero en gran medida errónea.
Este es un problema histórico y la causa principal es la naturaleza de un solo subproceso de EVM, no porque no haya separación entre DA y ejecución. Todos los L2 pagan una tarifa a L1 y las tarifas de L1 se pueden aumentar en cualquier momento. Durante la locura de las memecoins a principios de este año, las tarifas de transacción en Arbitrum y Optimism superaron brevemente los 10 dólares. Las tarifas del optimismo también se han disparado recientemente tras el lanzamiento de Worldcoin.
Las únicas soluciones para abordar los aumentos de tarifas son: 1) maximizar L1 DA, 2) refinar el mercado de tarifas tanto como sea posible:
Si L1 tiene recursos limitados, los picos de uso en L2 individuales se trasladarán a L1, lo que impondrá costos más altos a todos los demás L2. Por lo tanto, la cadena de aplicaciones/rollup no es inmune a los picos de gas.
La coexistencia de numerosos EVM L2 es sólo una forma burda de probar el mercado de tarifas de localización. Es mejor que poner el mercado de tarifas en un único EVM L1, pero no resuelve el problema central. Cuando se da cuenta de que la solución es un mercado de tarifas localizado, el punto final lógico es un mercado de tarifas por estado (en lugar de un mercado de tarifas por L2).
Otras cadenas ya han llegado a esta conclusión. Solana y Aptos localizan naturalmente los mercados de tarifas. Esto requirió un extenso trabajo de ingeniería durante muchos años para los respectivos entornos de ejecución. La mayoría de los defensores de la modularidad subestiman gravemente la importancia y la dificultad de diseñar mercados de tarifas locales.
Al lanzar múltiples cadenas, los desarrolladores no obtienen ganancias reales de rendimiento. Cuando hay aplicaciones que generan un mayor volumen de transacciones, los costos de todas las cadenas L2 se ven afectados.
La flexibilidad está sobrevalorada
Los defensores de las cadenas modulares argumentan que la arquitectura modular es más flexible. Esta afirmación es evidentemente cierta, pero ¿realmente importa?
Durante seis años he estado tratando de encontrar desarrolladores de aplicaciones para quienes una L1 genérica no pudiera proporcionar una flexibilidad significativa. Pero hasta ahora, aparte de tres casos de uso muy específicos, nadie ha podido explicar por qué la flexibilidad es importante y cómo ayuda directamente a escalar. Tres casos de uso específicos en los que considero que la flexibilidad es importante son:
Aplicaciones que aprovechan el estado "caliente". El estado caliente es un estado necesario para coordinar algún conjunto de operaciones en tiempo real, pero solo se enviará a la cadena temporalmente y no existirá para siempre. Algunos ejemplos de estados térmicos:
Órdenes limitadas en DEX como dYdX y Sei (muchas órdenes limitadas terminan cancelándose).
El flujo de órdenes se coordina e identifica en tiempo real en dFlow, un protocolo que facilita un mercado de flujo de órdenes descentralizado entre los creadores de mercado y las billeteras.
Oráculos como Pyth, que es un oráculo de baja latencia. Pyth se ejecuta como una cadena SVM independiente. Pyth genera tantos datos que el equipo central de Pyth decidió que era mejor enviar actualizaciones de precios de alta frecuencia a una cadena independiente y luego usar Wormhole para conectar los precios con otras cadenas según fuera necesario.
Modificar la cadena de consenso. Los mejores ejemplos son Osmosis (donde todas las transacciones se cifran antes de enviarlas a los validadores) y Thorchain (donde las transacciones dentro de un bloque se priorizan según las tarifas pagadas).
Se requiere una infraestructura que aproveche el esquema de firma umbral (TSS) de alguna manera. Algunos ejemplos de esto son Sommelier, Thorchain, Osmosis, Wormhole y Web3Auth.
Con la excepción de Pyth y Wormhole, todos los ejemplos enumerados anteriormente se crean utilizando el SDK de Cosmos y se ejecutan como cadenas independientes. Esto dice mucho sobre la idoneidad y escalabilidad del SDK de Cosmos para los tres casos de uso: estados calientes, modificaciones de consenso y sistemas de esquema de firma de umbral (TSS).
Sin embargo, la mayoría de los proyectos en los tres casos de uso anteriores no son aplicaciones, son infraestructura.
Pyth y dFlow no son aplicaciones, son infraestructura. Sommelier, Wormhole, Sei y Web3Auth no son aplicaciones, son infraestructura. Entre ellas, sólo hay un tipo específico de aplicación orientada al usuario: DEX (dYdX, Osmosis, Thorchain).
Durante seis años, he estado preguntando a los partidarios de Cosmos y Polkadot sobre los casos de uso que resultan de la flexibilidad que ofrecen. Creo que hay suficientes datos para hacer algunas inferencias:
En primer lugar, los ejemplos de infraestructura no deberían existir como Rollups porque producen demasiados datos de bajo valor (como estados calientes, y el objetivo de los estados calientes es que los datos no se envían de nuevo a L1), o porque no algo intencionalmente inconsistente con los activos en el libro mayor con la funcionalidad relacionada con la actualización de estado (por ejemplo, todos los casos de uso de TSS).
En segundo lugar, la única aplicación que he visto que podría beneficiarse de cambiar el diseño del sistema central es un DEX. Porque DEX está inundado de MEV y las cadenas universales no pueden igualar la latencia de CEX. El consenso es la base para la calidad de ejecución de las transacciones y MEV, por lo que los cambios basados en el consenso traerán naturalmente muchas oportunidades de innovación a DEX. Sin embargo, como se mencionó anteriormente en este artículo, la entrada principal para un DEX al contado es el activo que se comercializa. Los DEX compiten por los activos y, por tanto, por los emisores de activos. Bajo este marco, es poco probable que las cadenas DEX independientes tengan éxito porque el problema principal que los emisores de activos consideran al emitir activos no es el MEV relacionado con DEX, sino la funcionalidad general de los contratos inteligentes y la incorporación de esta funcionalidad en las respectivas aplicaciones de los desarrolladores.
Sin embargo, los DEX de derivados no necesitan competir por los emisores de activos. Dependen principalmente de garantías como el USDC y los precios de Oracle, y esencialmente deben bloquear los activos de los usuarios para garantizar las posiciones de derivados. Entonces, en el sentido de cadenas DEX independientes, es más probable que funcionen para DEX centrados en derivados como dYdX y Sei.
Consideremos las aplicaciones L1 integradas comunes que existen hoy en día, que incluyen: juegos, sistemas DeSoc (como Farcaster y Lens), protocolos DePIN (como Helium, Hivemapper, Render Network, DIMO y Daylight), sonido, intercambios NFT y más. . Ninguno de estos se beneficia particularmente de la flexibilidad que aporta la modificación del consenso; sus respectivos libros de contabilidad de activos tienen un conjunto de requisitos bastante simple, obvio y común: tarifas bajas, baja latencia, acceso a DEX al contado, acceso a monedas estables y acceso a fiat. canales, como CEX.
Creo que ahora tenemos suficientes datos para decir, hasta cierto punto, que la gran mayoría de las aplicaciones orientadas al usuario tienen los mismos requisitos generales enumerados en el párrafo anterior. Si bien algunas aplicaciones pueden optimizar otras variables en el margen con características personalizadas en la pila, las compensaciones que vienen con estas personalizaciones generalmente no valen la pena (más puentes, menos soporte de billetera, menos soporte de programas de indexación/consulta, reducción de moneda legal). canales, etc).
La implementación de nuevos libros de contabilidad de activos es una forma de lograr flexibilidad, pero rara vez agrega valor y casi siempre introduce complejidad técnica y social con pocos beneficios finales para los desarrolladores de aplicaciones.
La DA extendida no requiere volver a hipotecar
También escuchará a los defensores modulares hablar sobre la rehipotecación en el contexto del escalamiento. Este es el argumento más especulativo de los defensores de las cadenas modulares, pero vale la pena discutirlo.
A grandes rasgos afirma que, debido al re-stake (por ejemplo, a través de sistemas como EigenLayer), todo el ecosistema criptográfico puede volver a apostar ETH una cantidad infinita de veces, potenciando un número ilimitado de capas DA (por ejemplo, EigenDA) y capas de ejecución. Por lo tanto, la escalabilidad se resuelve desde todos los aspectos garantizando al mismo tiempo la apreciación del valor de ETH.
A pesar de la enorme incertidumbre entre la situación actual y el futuro teórico, damos por sentado que todos los supuestos de estratificación funcionan como se anuncia.
El DA de Ethereum actualmente ronda los 83 KB/s. Con la introducción de EIP-4844 a finales de este año, esa velocidad puede aproximadamente duplicarse a aproximadamente 166 KB/s. EigenDA puede agregar 10 MB/s adicionales, pero requiere un conjunto diferente de supuestos de seguridad (no todo el ETH tendrá una nueva garantía para EigenDA).
En comparación, Solana ofrece actualmente 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. Además, el DA de Solana se expande con el tiempo según la ley de Nelson.
Hay muchas formas de ampliar la DA mediante la rehipoteca y la modularización, pero estos mecanismos simplemente no son necesarios hoy en día e introducen importantes complejidades técnicas y sociales.
Creado para desarrolladores de aplicaciones
Después de años de pensarlo, llegué a la conclusión de que la modularidad no debería ser un objetivo en sí mismo.
Blockchain debe servir a sus clientes (es decir, desarrolladores de aplicaciones); por lo tanto, blockchain debe abstraer la complejidad a nivel de infraestructura para que los desarrolladores puedan centrarse en crear aplicaciones de clase mundial.
La modularidad es genial. Pero la clave para construir una tecnología ganadora es determinar qué partes de la pila deben integrarse y cuáles deben dejarse a otros. Por ahora, la integración de DA y las cadenas de ejecución proporciona inherentemente una experiencia más sencilla para el usuario final y el desarrollador y, en última instancia, proporcionará una mejor base para las mejores aplicaciones de su clase.
Enlace original
Este artículo ha sido reimpreso de Foresight News con autorización.
Este artículo Socio multicoin de una institución de capital de riesgo: por qué la cadena de bloques modular está sobrevalorada apareció por primera vez en Zombit.