Introducción

Esta breve publicación describirá las compensaciones concretas de:

• L1 frente a L2
• Acumulados versus integrados
• Aplicación específica versus propósito general

Necesitamos una mejor comprensión de qué arquitecturas construir y cuándo. De lo contrario, seguiremos teniendo una mezcolanza de infraestructura confusa que ningún usuario podrá entender ni con la que podrá interactuar. Este es el error más común que veo:

Como se señaló en la publicación introductoria de Eclipse antes de su próximo lanzamiento en la red principal:

A menudo se presenta una falsa dicotomía entre la visión del rollup modular y la capacidad de tener una única cadena con escala masiva, ejecución paralelizada y estado compartido. "Modular" a menudo se combina con "específico de la aplicación", lo que le llevaría a creer que los paquetes acumulativos significan un mundo de muchas cadenas fragmentadas y de bajo rendimiento. Desafiamos esa idea.

Los rollups y L2 no son una mala experiencia de usuario. Los rollups fragmentados y los L2 son una mala experiencia de usuario. Los paquetes acumulativos y L2 diseñados correctamente deberían mejorar la UX.

Acumulados frente a integrados

Todas las cadenas pueden eventualmente adoptar la mejor tecnología (por ejemplo, DAS + ZK) si resulta útil. Como mencioné en mi último informe , ¿los rollups heredan la seguridad?, la distinción que nos queda entonces es aproximadamente la siguiente:

• “Acumulados” también conocidos como “Modular”: cree cadenas lógicamente separadas que publiquen datos en su cadena de host (capa DA). Reutilizan el consenso de la cadena anfitriona.
• “Integrado” también conocido como “Monolítico”: integra todo en un protocolo con su propio consenso. No publique datos en una cadena de host separada. (Incluso si la capa DA y la capa de ejecución son, en cierto sentido, piezas lógicamente separadas del protocolo compartido).

Solana y Eclipse representan caminos paralelos, como se muestra de manera similar en la Tesis Solana de Syncracy:

Como mencioné en mi reciente episodio de Uncommon Core con Hasu, ambos enfoques tendrán valor a largo plazo.

Solana adopta el enfoque de agrupar todo en un solo consenso. Busca una latencia mínima (los tiempos de ranura actualmente promedian ~400-500 ms con la esperanza de alcanzar los 200 ms en el futuro) mientras mantiene un gran conjunto de validadores (~2000). Este increíble logro requirió varios avances técnicos.

Sin embargo, estos dos objetivos (máxima descentralización + mínima latencia) están inherentemente en tensión. Es increíblemente desafiante mantener estable este conjunto de consenso mientras se ejecuta a la máxima velocidad y rendimiento. TowerBFT no tiene un análisis formal de seguridad o vida, y no está claro si la prueba de historial es actualmente útil y resistente en un modelo adversario o simplemente puede eliminarse. Por supuesto, la economía de un sistema de baja latencia también aumenta el incentivo para centralizar.

Eclipse adopta el enfoque de desagregar el consenso. Los rollups pueden tener un conjunto de secuenciadores más pequeños cuidadosamente seleccionados (potencialmente incluso ejecutados por un solo operador) para operar en un entorno controlado. Esto puede aumentar la confiabilidad y reducir aún más la latencia, ofreciendo un producto Web2 con los beneficios de los criptorieles. Code, una aplicación de pagos implementada como una especie de L2 en Solana que utiliza nonces duraderos, es similar en su deseo de realizar pagos instantáneos y confiables. Más allá de la excelente experiencia de usuario de la latencia casi instantánea, también es necesario llevar el límite inferior aún más para aplicaciones financieras de alto valor y baja latencia.

Luego, los paquetes acumulativos pueden publicar sus datos en otro conjunto de consenso descentralizado para una verificación más sólida en una escala de tiempo más lenta. Por ejemplo, Celestia tiene tiempos de bloqueo de 15 segundos con finalidad de un solo espacio, ¡lo que en realidad ni siquiera es tan diferente de Solana! Solana tiene confirmaciones de ~400 ms, luego se alcanza la finalidad después de 32 espacios (~12,8 s).

Aquí no hay almuerzo gratis. Existe una posible compensación entre las propiedades del conjunto de validadores en tiempo real (por ejemplo, Solana tiene muchos más validadores que los secuenciadores) frente a las garantías proporcionadas (por ejemplo, entorno resiliente controlado, latencia incluso menor, etc.). El nivel adecuado de compromiso dado (y en qué escala de tiempo) es un espectro. Quedan preguntas abiertas de ingeniería y la mejor opción probablemente variará según el caso de uso. No hace falta decir que el costo también es esencial aquí, por lo que se necesitarán capas DA escalables como Celestia (que utiliza Eclipse).

Obviamente, Eclipse no reemplazará a Solana. Cada uno hace diferentes concesiones y persigue un mercado diferente. Solana sigue siendo el corazón y el alma del desarrollo de SVM y, como resultado, es probable que se implementen muchas aplicaciones nuevas allí. Sin embargo, está claro que habrá más de una cadena SVM a largo plazo (Pyth incluso ya lo es). El futuro no es una sola cadena y SVM es simplemente una tecnología asombrosa. Eclipse está iniciando esa tendencia de exportarlo a L2, pero espero que otros se den cuenta del valor aquí y sigan su ejemplo.

L1 frente a L2

Estoy usando L1 y L2 aquí en el sentido más popular para incluir resúmenes, validiums, etc. Como se explica en los diferentes tipos de capa 2 de Vitalik:

Los puentes de validación bidireccionales son casi suficientes para convertir una cadena en validium. El principal ingrediente restante es el compromiso social de que si sucede algo excepcional en Ethereum que haga que el puente ya no funcione, la otra cadena se bifurcará en respuesta.

Lo que distingue a una L1 de una L2 es efectivamente cómo maneja las bifurcaciones. Un validium se revertiría si su L1 revierte un bloque, y se bifurcaría si su capa base se bifurcara. Para mejorar la L2, alguna forma de gobernanza de la L2 debe vivir en la L1 como un contrato puente que sea legible para la L1.

Ahora bien, ¿por qué usaríamos algo así? ¿Tiene sentido que una cadena delegue su elección de bifurcación a una L1 subyacente y se arraigue alrededor de su puente allí?

A pesar de la creencia común de que las guerras L1 han terminado, Ethereum ha ganado y todos los competidores de Ethereum quieren convertirse en L2 ahora ; los Ethereum L2 no son la mejor solución para todas las cadenas.

Los Ethereum L2 a menudo se consideran la forma más segura y escalable de construir una cadena. Sin embargo, estas propiedades de seguridad a menudo se malinterpretan profundamente, como se analizó en mi último informe. Simplemente publicar una prueba en Ethereum y delegar allí su regla de elección de bifurcación no hace que su cadena sea súper segura mágicamente.

El argumento de que todas las cadenas deben implementarse como Ethereum L2 por su propia seguridad suele ser incorrecto. Más bien, el principal beneficio de las L2 ha sido la capacidad de aprovechar los efectos de red de Ethereum (usuarios, liquidez, desarrolladores, herramientas, etc.). Es una estrategia de comercialización.

Luchar por la atención tiene sentido dado que la atención es el único recurso escaso en las criptomonedas. Naturalmente, las L2 llegan a estar al frente y al centro con los desarrolladores, usuarios, medios, etc. que más importan. Ser L2 solía ser suficiente para llamar esa atención.

Sin embargo, la atención que se recibe por ser L2 está disminuyendo. La lista de Ethereum L2 activos y futuros es ahora demasiado larga para que cualquier individuo pueda seguirla. Las cadenas que giran hacia las L2 no reciben el impulso de atención que obtuvieron las primeras (por ejemplo, Optimism y Arbitrum). Incluso la avalancha de zkEVM tan esperados está luchando por atraer usuarios, aplicaciones y valor.

Entonces, ser un L2 por sí solo ya no garantiza la atención de todos. Sin embargo, aún puede ofrecer una ventaja de producto frente a las cadenas independientes si puede atraer la atención de alguna otra manera. Por ejemplo, convertir un esquema piramidal en un cuadrado puede atraer ~700 mm a un multisig sin L2. Alternativamente, podrías construir el primer SVM L2 de Ethereum.

Suponiendo que tiene un producto que le interesa, consideremos ahora cómo ser un L2 puede ayudar a una cadena a acceder a la base de usuarios de Ethereum y ofrecer una mejor experiencia de producto. Lo haría principalmente aprovechando los activos nativos de Ethereum (por ejemplo, ETH) de manera favorable (por ejemplo, puentes con seguridad y/o UX atractivos).

El valor de esto depende en gran medida de dos supuestos básicos:

1.Que los activos de Ethereum existentes son importantes para el caso de uso determinado (por ejemplo, DeFi que depende de ETH)

Si su aplicación depende en gran medida de los activos del ecosistema Ethereum, entonces una arquitectura L2 puede ser valiosa. Si no le importan en absoluto los activos de Ethereum, ser un Ethereum L2 no es particularmente valioso. Los activos basados en Ethereum son claramente los más importantes en criptografía hoy en día, por lo que hoy hay un gran mercado al que atender.

Mirando hacia el futuro a nivel de la industria, la pregunta central aquí es ¿cuál será la nueva y valiosa creación estatal de las criptomonedas en el futuro?

• Si este estado futuro está cada vez más desconectado del estado actual nativo de Ethereum (por ejemplo, nuevo estado único, RWA, etc.), entonces el atractivo de las L2 puede verse disminuido.
• Si este estado futuro depende en gran medida del estado actual nativo de Ethereum (por ejemplo, el comercio de ETH), entonces los L2 pueden desempeñar un papel destacado.

El primer escenario parte de la opinión de que solo hemos visto una gota en el océano de lo que serán las criptomonedas, y no se debe sobreindexar lo que hay aquí hoy. El último escenario considera que el desarrollo y las aplicaciones criptográficas dependerán increíblemente de la ruta, por lo que el estado actual influirá en el resultado.

Ambas son ciertas hasta cierto punto, pero creo que cualquier visión optimista de las perspectivas a largo plazo de la industria se inclina hacia la primera. Habrá muchos estados nuevos y únicos sobre los cuales ni siquiera podemos razonar y que no estarán ligados al estado actual. El estado actual de las criptomonedas es una gota en el océano en comparación con el estado futuro esperado.

Por ejemplo, las “garantías de liquidación” comúnmente citadas de Ethereum significan poco para los activos del mundo real (RWA), como las monedas estables (por ejemplo, USDC) o las letras del tesoro tokenizadas. Se “liquidan” cuando el emisor (por ejemplo, Circle) así lo considera.

En este escenario, el atractivo de ser un Ethereum L2 puede disminuir como porcentaje de aplicaciones. A una nueva aplicación de pago basada en USDC no le importa si es un Ethereum L2 o no. Solo quieren la infraestructura más barata, rápida y confiable que les permita ofrecer a los usuarios la mejor experiencia de producto.

Históricamente, la creación de nuevos estados ha sido un obstáculo para Solana, aunque aquí vemos claramente que los vientos cambian. Muchos proyectos de infraestructura y DeFi conocidos en Solana ahora están lanzando tokens, y habrá más por venir. Esto está poniendo en marcha el volante Solana.

2.Que los puentes Ethereum ←→ L2 son preferibles a los puentes Ethereum ←→ L1 (por ejemplo, por razones de seguridad y/o UX)

Supongamos que la primera suposición se cumplió para un caso de uso determinado (es decir, los nativos de Ethereum son bastante valiosos para su aplicación). Entonces, debemos preguntarnos si una L2 puede exponer estos activos de una manera más favorable que una L1 separada. Digamos que un usuario tiene algo de ETH y quiere cambiarlo por USDC. ¿A dónde van?

Si bien la seguridad del puente a menudo se cita como motivación en este caso, este argumento parece tenue según la información disponible. Muchos de los puentes acumulativos más grandes ni siquiera tienen pruebas, tienen pruebas en la lista blanca, actualizaciones controladas por múltiples firmas o, literalmente, ni siquiera tienen una L2.

Esto se compara con la clásica conexión entre verificadores y consensos (p. ej., IBC). En la práctica, no ha habido fallas importantes en el quórum de validadores en tales escenarios. Las fallas de los puentes generalmente se han producido debido a hackeos y/o puentes múltiples comprometidos (a los que los L2 son igualmente susceptibles).

Si bien las mejoras de seguridad me resultan menos convincentes aquí, en mi opinión, el acceso conveniente a los usuarios y activos de Ethereum es un beneficio importante del puente L2 hoy en día. Los paquetes acumulativos como Base, Optimism y Arbitrum se parecen más a extensiones de Ethereum. Los usuarios mantienen las mismas billeteras y direcciones, el token de gas nativo es una versión canónica única de ETH, ETH domina DeFi como todos los pares comerciales, las aplicaciones sociales valoran los NFT en ETH y pagan a los creadores en ETH (por ejemplo, friend.tech). los depósitos en la L2 son instantáneos (porque se reorganizarían juntos), etc.

No se puede esperar que los usuarios razonen sobre qué puente usar, analicen los distintos supuestos de seguridad, obtengan uno de los varios tokens envueltos disponibles, adquieran el token nativo de la cadena para el gas, etc. Solo quieren unir su ETH, obtener ETH del otro lado y seguir usando L2 como usarían Ethereum o cualquier otro L2. Es por eso que Eclipse simplemente usará ETH como su token nativo utilizado para el gas. Forzar la introducción de un nuevo token de gas es perjudicial para la UX.

Entonces, ¿por qué Solana no puede ofrecer las mismas ventajas que un Ethereum L2? En realidad, esto se convierte más en una cuestión de ingeniería que en algo fundamental, y será más fácil con el tiempo. Esto es cierto para los tokens de gas, así como para otros desafíos de UX relacionados con simplemente no usar el EVM (que no es inherente a L1 frente a L2):

• Token de gas: los pagos de gas se pueden retirar de los usuarios, lo que les permite pagar con cualquier token de gas que elijan.
• Puente: Es probable que el puente se endurezca y estandarice más con el tiempo, lo que generará menos confusión por parte de los usuarios y fragmentación de la liquidez.
• Carteras: los Snaps recientemente presentados de MetaMask extienden el soporte de MetaMask a cadenas que no son EVM a través de integraciones de terceros integradas en la parte superior, como a través de MetaMask Snaps de Drift o Solflare.
• Experiencia del desarrollador: las barreras del idioma se romperán. Proyectos como Solang y Neon pueden ayudar a los desarrolladores de Solidity a construir sobre Solana, y proyectos como Stylus pueden ayudar a los desarrolladores de Rust a construir sobre Arbitrum.

En el futuro, incluso sería posible que ETH desempeñara un papel en Solana DeFi si los usuarios expresaran fuertes preferencias por ETH con la velocidad y escala de Solana. En la práctica, es mucho más probable que estos usuarios con activos nativos de Ethereum continúen usándolos dentro del ecosistema Ethereum L2 por las razones que hemos discutido, suponiendo que tengan acceso a L2 comparablemente escalables.

Aplicación específica versus propósito general

Independientemente de si una cadena es L1 o L2, existe una clara necesidad de aumentar el rendimiento de una sola cadena escalando la ejecución. Los rollups no deben implicar fragmentación. Unir muchas cadenas homogéneas bajo un secuenciador compartido con estado termina pareciendo una cadena paralelizada desde una perspectiva de escala con una experiencia de usuario más desafiante.

A menudo vemos que se cita el “espacio de bloques dedicado” como el motivo para implementar un paquete acumulativo específico de la aplicación. Sin embargo, esta idea errónea ha surgido en gran medida debido a las limitaciones innecesarias del EVM de un solo subproceso en los mercados de tarifas globales. Una SVM paralelizada con mercados de tarifas locales reduce en gran medida la necesidad de cadenas de aplicaciones. Alojar más aplicaciones en una infraestructura compartida reduce significativamente la complejidad de los desarrolladores y usuarios. La experiencia de usuario entre cadenas y la complejidad de los desarrolladores en un mundo de muchas cadenas es un riesgo existencial subestimado.

Esto no quiere decir que al final del día habrá literalmente una cadena. A grandes rasgos veo cuatro argumentos para desplegar tu propia cadena:

1. Escalabilidad y espacio de bloques dedicado: como se mencionó anteriormente, este no suele ser convincente. Una menta NFT no debería cerrar efectivamente el resto de la cadena, pero la respuesta generalmente no es crear otra cadena. Esto se soluciona mediante una máquina virtual paralelizada con los mercados de tarifas locales. Sin embargo, en la medida en que el ancho de banda de toda la red esté saturado, los mercados de tarifas locales no ayudarán (es decir, las tarifas de la cadena compartida aumentarán a nivel mundial). Entonces necesitas otra cadena.
2. Soberanía: la gobernanza en criptografía sigue siendo bastante deficiente, y tener su propia cadena para bifurcar puede ser un mecanismo de coordinación útil. Mi intuición es que se trata de una circunstancia muy rara, pero es difícil decirlo con certeza. Esto está en línea con el interés de MakerDAO en una cadena de aplicaciones.
3. Personalización: las personalizaciones a nivel de consenso pueden ser valiosas para ciertas aplicaciones (por ejemplo, dYdX v4), pero estos casos son empíricamente pocos y espaciados hasta la fecha. Incluso dYdX, el ejemplo brillante de una cadena de aplicaciones, "probablemente avanzará más hacia la ejecución generalizada en la cadena dYdX", según Antonio en su reciente episodio de Bell Curve. La necesidad de personalización completa que no se puede resolver en una cadena compartida generalmente ha faltado en la mayor parte de las criptomonedas. Casi todos los nuevos rollups siguen siendo simplemente bifurcaciones EVM estándar con nuevos tokens.
4. Captura de valor: podría decirse que este es un subconjunto de personalización, pero es bastante importante, por lo que lo dividiremos. Puede resultar más complicado internalizar el valor de una infraestructura compartida que no se haya creado pensando únicamente en su aplicación. Las cadenas de aplicaciones pueden facilitar la asignación de valor a las aplicaciones responsables. Sin embargo, este es un esfuerzo de ingeniería más que fundamental, y en Solana se están realizando investigaciones sobre cómo hacer exactamente esto. Además, tenga en cuenta que existe un costo general importante al implementar su propia cadena en comparación con la amortización de costos en una infraestructura compartida.

La principal motivación para lanzar una cadena de aplicaciones hoy en día es a menudo el impulso narrativo percibido y/o la utilidad simbólica para un proyecto en dificultades. La caída del mercado bajista y la correspondiente falta de crecimiento de las aplicaciones incentivaron el desarrollo y la financiación de una arquitectura demasiado complicada que dio lugar a nuevos proyectos necesarios para resolver complejidades autoinfligidas.

Lanzar su propia cadena hoy conlleva compensaciones dolorosas e innecesarias (complejidad, costo, peor experiencia de usuario, liquidez fragmentada, etc.) que la mayoría de las aplicaciones no pueden justificar por los beneficios incrementales. La infraestructura necesaria para que esta UX sea competitiva parece lejana. Esto no quiere decir que no haya razón para que existan cadenas de aplicaciones (ciertamente las existen). Más bien, hemos sobreindexado enormemente en esta dirección la narrativa como industria, por lo que la tendencia actual hacia la reagrupación es claramente beneficiosa dado el estado actual.

Conclusión

Solana ha ganado, con razón, mucho impulso en los últimos meses. Esta fuerte corrección ha sido en gran medida un reconocimiento del estado actual de la UX multicadena: está fragmentada y dolorosa. La UX del uso de aplicaciones Solana es simplemente increíble. Suave y rápido.

Los rollups y L2 han tenido mala reputación para UX, pero el verdadero problema es la fragmentación. Asociamos los rollups y L2 con el escalado horizontal fragmentado porque, en la práctica, la mayoría de ellos han bifurcado el EVM tal como está y utilizan un ancho de banda DA restringido. Terminan siendo costosos y complicados de usar.

Sin embargo, esto no es fundamental. El escalado vertical con una potente máquina virtual en una capa DA escalable soluciona estos problemas de UX y de costos. Es probable que se produzca cierto nivel de reagrupación de la pila tanto para L1 como para L2. Las L2 y los paquetes acumulativos deberían mejorar la UX si se usan correctamente. Ese debería ser su verdadero punto de venta.

Ambos enfoques tienen sus ventajas. Sólo tenemos que hacer un mejor trabajo preguntándonos primero "¿a qué mercado intenta dirigirse este producto?" y "¿cómo puede esta arquitectura resolver lo que necesito?" antes de comenzar a construir la siguiente L1, L2, L3...

Descargo de responsabilidad:

1. Este artículo se reimprime de [dba]. Todos los derechos de autor pertenecen al autor original [Jon Charbonneau]. 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.