Uno de los puntos que mencioné en mi publicación hace dos años y medio en “the Endgame”es que los diferentes futuros caminos de desarrollo para una blockchain, al menos tecnológicamente, parecen sorprendentemente similares. En ambos casos, tienes un número muy grande de transacciones onchain, y procesarlas requiere (i) una gran cantidad de cálculos y (ii) una gran cantidad de ancho de banda de datos. Los nodos regulares de Ethereum, como los 2 TB nodo de archivo rethcorriendo en la computadora que estoy usando para escribir este artículo, no son lo suficientemente potentes para verificar una cantidad tan grande de datos y cálculos directamente, incluso con un trabajo heroico de ingeniería de software y Árboles Verkle. En cambio, tanto en el “sharding L1” como en un centrado en rollup mundo, ZK-SNARKsse utilizan para verificar cálculos, y DASpara verificar la disponibilidad de datos. El DAS en ambos casos es el mismo. Los ZK-SNARKs en ambos casos son la misma tecnología, excepto en un caso son código de contrato inteligente y en el otro caso son una característica consagrada del protocolo. En un sentido técnico muy real, Ethereum está realizando fragmentación, y los rollups son fragmentos.

Esto plantea una pregunta natural: ¿cuál es la diferencia entre estos dos mundos? Una respuesta es que las consecuencias de los errores de código son diferentes: en un mundo de rollup, las monedas se pierden, y en un mundo de cadena de fragmentos, hay fallos de consenso. Pero espero que a medida que los protocolos se solidifiquen, y a medida que mejore la tecnología de verificación formal, la importancia de los errores disminuirá. Entonces, ¿cuáles son las diferencias entre las dos visiones que podemos esperar que perduren a largo plazo?

Diversidad de entornos de ejecución

Una de las ideas con las que jugamos brevemente en Ethereum en 2019 fueentornos de ejecución. Básicamente, Ethereum tendría diferentes “zonas” que podrían tener reglas diferentes sobre cómo funcionan las cuentas (incluyendo enfoques totalmente diferentes como UTXOs), cómo funciona la máquina virtual y otras características. Esto permitiría una diversidad de enfoques en partes de la pila donde sería difícil lograrlo si Ethereum intentara hacer todo por sí mismo.

Al final, terminamos abandonando algunos de los planes más ambiciosos y simplemente mantuvimos el EVM. Sin embargo, las capas 2 de Ethereum (incluidas las rollups, valdiums y Plasmas) terminaron sirviendo, argumentablemente, el papel de entornos de ejecución. Hoy en día, generalmente nos centramos en las capas 2 equivalentes al EVM, pero esto ignora la diversidad de muchos enfoques alternativos:

• Arbitrum Stylus, que añade una segunda máquina virtual basada en WASMjunto al EVM.
• Combustible, que utiliza una arquitectura basada en UTXO similar a Bitcoin (pero más completa en funciones).
• Azteca, que introduce un nuevo lenguaje y paradigma de programación diseñado en torno a contratos inteligentes de preservación de la privacidad basados en ZK-SNARK.

Arquitectura basada en UTXO. Fuente: documentación de Fuel.

Podríamos intentar convertir el EVM en un super-VM que cubra todos los paradigmas posibles, pero eso habría llevado a implementaciones mucho menos efectivas de cada uno de estos conceptos que permitir que plataformas como estas se especialicen.

Compensaciones de seguridad: escala y velocidad

Ethereum L1 ofrece una garantía de seguridad realmente sólida. Si algún dato está dentro de un bloque que se ha finalizado en L1, todo el consenso (incluido, en situaciones extremas, el consenso social) trabaja para asegurar que los datos no se editarán de una manera que vaya en contra de las reglas de la aplicación que colocó esos datos allí, que cualquier ejecución desencadenada por los datos no se revertirá y que los datos seguirán siendo accesibles. Para lograr estas garantías, Ethereum L1 está dispuesto a aceptar costos elevados. En el momento de escribir esto, las tarifas de transacción son relativamente bajas: las capas 2 cobran menos de un centavopor transacción, e incluso el L1 es menos de $1 para una transferencia básica de ETH. Estos costos pueden permanecer bajos en el futuro si la tecnología mejora lo suficientemente rápido como para que el espacio de bloque disponible crezca para satisfacer la demanda, pero puede que no lo hagan. E incluso $0.01 por transacción es demasiado alto para muchas aplicaciones no financieras, por ejemplo, redes sociales o juegos.

Pero las redes sociales y los juegos no requieren el mismo modelo de seguridad que L1. Está bien si alguien puede pagar un millón de dólares para revertir un registro de haber perdido una partida de ajedrez, o hacer que una de tus publicaciones en Twitter parezca que fue publicada tres días después de lo que realmente fue. Por lo tanto, estas aplicaciones no deberían tener que pagar los mismos costos de seguridad. Un enfoque centrado en L2 permite esto, al apoyar un espectro de enfoques de disponibilidad de datos desde rollupsaplasmaavalidiums.

Diferentes tipos de L2 para diferentes casos de uso. Lee másaquí.

Otro compromiso de seguridad surge en torno al problema de transferir activos de L2 a L2. En el límite (5-10 años en el futuro), espero que todos los rollups sean rollups ZK, y sistemas de prueba hiper eficientes como Binius y Círculo STARKsconbúsquedas, más capas de agregación de pruebas, permitirá a los L2s proporcionar raíces de estado finalizadas en cada espacio de tiempo. Por ahora, sin embargo, tenemos una mezcla complicada de rollups optimistas y rollups ZK con diversos marcos de tiempo de prueba. Si hubiéramos implementado el particionamiento de ejecución en 2021, el modelo de seguridad para mantener honestos a los fragmentos habría sido rollups optimistas, no ZK - y por lo tanto L1 habría tenido que gestionar el complejo sistémicológica a prueba de fraude en cadena y tiene un período de retiro de una semana para mover activos de fragmento a fragmento. Pero al igual que los errores de código, creo que este problema es en última instancia temporal.

Una tercera, y una vez más más duradera, dimensión del compromiso de seguridad es la velocidad de transacción. Ethereum tiene bloques cada 12 segundos, y no está dispuesto a ir mucho más rápido porque eso centralizaría en exceso la red. Sin embargo, muchos L2 están explorando tiempos de bloque de unos pocos cientos de milisegundos. 12 segundos ya no es tan malo: en promedio, un usuario que envía una transacción necesita esperar ~6-7 segundos para ser incluido en un bloque (no solo 6 debido a la posibilidad de que el siguiente bloque no los incluya). Esto es comparable a lo que tengo que esperar cuando realizo un pago con mi tarjeta de crédito. Pero muchas aplicaciones exigen una velocidad mucho mayor, y los L2 la proporcionan.

Para proporcionar esta mayor velocidad, las L2s dependen de mecanismos de preconfirmación: los validadores propios de la L2 firman digitalmente una promesa de incluir la transacción en un momento particular, y si la transacción no se incluye, pueden ser penalizados. Un mecanismo llamado StakeSuregeneraliza esto aún más.

L2 preconfirmaciones.

Ahora, podríamos intentar hacer todo esto en la capa 1. La capa 1 podría incorporar un sistema de “preconfirmación rápida” y “confirmación final lenta”. Podría incorporar diferentes fragmentos con diferentes niveles de seguridad. Sin embargo, esto añadiría mucha complejidad al protocolo. Además, hacer todo en la capa 1 supondría un riesgo sobrecargando el consenso, porque muchas de las aproximaciones de mayor escala o mayor rendimiento tienen mayores riesgos de centralización o requieren formas más fuertes de 'gobernanza', y si se realizan en L1, los efectos de esas demandas más fuertes se derramarían sobre el resto del protocolo. Al ofrecer estos compromisos a través de las capas 2, Ethereum puede evitar en su mayoría estos riesgos.

Los beneficios de las capas 2 en la organización y la cultura

Imagina que un país se divide en dos, y una mitad se vuelve capitalista y la otra se vuelve altamente dirigida por el gobierno (a diferencia de cuando esto sucede en realidad, suponga que en este experimento mental no es el resultado de ningún tipo de guerra traumática; más bien, un día se levanta una frontera mágicamente y eso es todo). En la parte capitalista, los restaurantes son dirigidos por diversas combinaciones de propiedad descentralizada, cadenas y franquicias. En la parte impulsada por el gobierno, son todas sucursales del gobierno, como estaciones de policía. El primer día, no cambiaría mucho. La gente sigue en gran medida sus hábitos existentes, y lo que funciona y lo que no funciona depende de realidades técnicas como la habilidad laboral y la infraestructura. Sin embargo, un año después, se esperarían ver grandes cambios, porque las estructuras diferentes de incentivos y control llevan a grandes cambios en el comportamiento, lo que afecta quién viene, quién se queda y quién se va, qué se construye, qué se mantiene y qué se deja pudrir.

Organización industrialla teoría abarca muchas de estas distinciones: habla no solo de las diferencias entre una economía dirigida por el gobierno y una economía capitalista, sino también entre una economía dominada por grandes franquicias y una economía donde, por ejemplo, cada supermercado es gestionado por un empresario independiente. Yo argumentaría que la diferencia entre un ecosistema centrado en la capa 1 y un ecosistema centrado en la capa 2 sigue líneas similares.

Una arquitectura de 'los desarrolladores principales lo manejan todo' que salió muy mal.

Yo expresaría el principal beneficio para Ethereum de ser un ecosistema centrado en la capa 2 de la siguiente manera:

Debido a que Ethereum es un ecosistema centrado en la capa 2, eres libre de construir de forma independiente un subecosistema que sea tuyo con tus características únicas, y al mismo tiempo sea parte de un Ethereum más grande.

Si estás construyendo solo un cliente de Ethereum, eres parte de un Ethereum más grande, y aunque tienes cierto margen para la creatividad, es mucho menor que lo disponible para las L2. Y si estás construyendo una cadena completamente independiente, tienes un margen máximo para la creatividad, pero pierdes los beneficios como la seguridad compartida y los efectos de red compartidos. Las L2 forman un feliz término medio.

Las capas 2 no solo crean una oportunidad técnica para experimentar con nuevos entornos de ejecución y compensaciones de seguridad para lograr escala, flexibilidad y velocidad: también crean un incentivo tanto para los desarrolladores para construir y mantenerlo, como para que la comunidad se forme en torno a él y lo apoye.

El hecho de que cada L2 esté aislado también significa que implementar nuevos enfoques es sin permiso: no es necesario convencer a todos los desarrolladores principales de que tu nuevo enfoque es "seguro" para el resto de la cadena. Si tu L2 falla, es responsabilidad tuya. Cualquiera puede trabajar en ideas totalmente extrañas (por ejemplo, El enfoque de Intmax hacia Plasma) y incluso si son completamente ignorados por los desarrolladores principales de Ethereum, pueden seguir construyendo y eventualmente implementar. Las características de L1 y las precompilaciones no son así, e incluso en Ethereum, lo que tiene éxito y lo que falla en el desarrollo de L1 a menudo termina dependiendo en gran medida de la política más de lo que nos gustaría. Independientemente de lo que teóricamente se podría construir, los incentivos distintos creados por un ecosistema centrado en L1 y un ecosistema centrado en L2 terminan influyendo fuertemente en lo que realmente se construye en la práctica, con qué nivel de calidad y en qué orden.

¿Qué desafíos enfrenta el ecosistema centrado en la capa 2 de Ethereum?

Una arquitectura de capa 1 + capa 2 que salió muy mal.Origen.

Hay un desafío clave para este tipo de enfoque centrado en la capa 2, y es un problema que los ecosistemas centrados en la capa 1 no tienen que enfrentar en la misma medida: la coordinación. En otras palabras, mientras Ethereum se expande, el desafío radica en preservar la propiedad fundamental de que todo siga sintiéndose como 'Ethereum', y tenga los efectos de red de ser Ethereum en lugar de ser N cadenas separadas. Hoy, la situación es subóptima en muchos aspectos:

• Mover tokens de una capa 2 a otra a menudo requiere plataformas de puente centralizadas, lo que complica las cosas para el usuario promedio. Si tienes monedas en Optimism, no puedes simplemente pegar la dirección de Arbitrum de alguien en tu billetera y enviarles fondos.
• El soporte de billetera de contrato inteligente entre cadenas no es genial, tanto para billeteras personales de contrato inteligente como para billeteras organizativas (incluidas las DAO). Si cambias tu clave en un L2, también necesitas cambiar tu clave en cada otro L2.
• La infraestructura de validación descentralizada a menudo es deficiente. Ethereum finalmente está comenzando a tener clientes ligeros decentes, como Helios. Sin embargo, no tiene sentido si toda la actividad se está produciendo en capas 2 que requieren sus propios RPC centralizados. En principio, una vez que tienes la cadena de encabezado de Ethereum, hacer clientes ligeros para L2s no es difícil; en la práctica, hay muy poco énfasis en ello.

Hay esfuerzos trabajando para mejorar los tres. Para el intercambio de tokens entre cadenas, el ERC-7683standard is an emerging option, and unlike existing “centralized bridges” it does not have any enshrined central operator, token or governance. For cross-chain accounts, the approach most wallets are taking is to use cross-chain replayable messages to update keys in the short term, and rollups de almacénen el largo plazo. Los clientes ligeros para L2s están empezando a surgir, por ejemplo. Beerus para Starknet. Además, las mejoras recientes en la experiencia del usuario a través de monederos de próxima generación ya han resuelto muchos problemas más básicos como eliminar la necesidad de que los usuarios cambien manualmente a la red correcta para acceder a una dapp.

Rabby mostrando una vista integrada de los saldos de activos en múltiples cadenas. ¡En los no tan lejanos y oscuros días pasados, las carteras no hacían esto!

Pero es importante reconocer que los ecosistemas centrados en la capa 2 nadan un poco contracorriente al intentar coordinarse. Las capas 2 individuales no tienen un incentivo económico natural para construir la infraestructura para coordinarse: las pequeñas no lo hacen, porque solo verían una pequeña parte del beneficio de sus contribuciones, y las grandes tampoco, porque se beneficiarían tanto o más al fortalecer sus propios efectos de red locales. Si cada capa 2 está optimizando por separado su parte individual, y nadie está pensando en cómo encaja cada pieza en el panorama general, obtenemos fracasos como la distopía urbanística en la imagen unos párrafos más arriba.

No afirmo tener soluciones mágicas perfectas para este problema. Lo mejor que puedo decir es que el ecosistema necesita reconocer más plenamente que la infraestructura cruzada L2 es un tipo de infraestructura de Ethereum, junto con los clientes L1, las herramientas de desarrollo y los lenguajes de programación, y debería ser valorada y financiada como tal. Tenemos Protocol Guild; tal vez necesitamos la Guild de Infraestructura Básica.

Conclusiones

"Las "capas 2" y el "fragmentado" a menudo se describen en el discurso público como dos estrategias opuestas sobre cómo escalar una cadena de bloques. Pero cuando se examina la tecnología subyacente, surge un rompecabezas: los enfoques subyacentes reales para escalar son exactamente iguales. Tienes algún tipo de fragmentación de datos. Tienes probadores de fraude o probadores ZK-SNARK. Tienes soluciones para la comunicación entre {rollup, shard}. La diferencia principal es: ¿quién es responsable de construir y actualizar esas piezas, y cuánta autonomía tienen?"

Un ecosistema centrado en la capa 2 es la fragmentación en un sentido técnico muy real, pero es una fragmentación en la que puedes crear tu propia fragmentación con tus propias reglas. Esto es poderoso y permite mucha creatividad e innovación independiente. Pero también tiene desafíos clave, particularmente en torno a la coordinación. Para que un ecosistema centrado en la capa 2 como Ethereum tenga éxito, debe comprender esos desafíos y abordarlos de frente, con el fin de obtener la mayor cantidad posible de beneficios de los ecosistemas centrados en la capa 1 y acercarse lo más posible a tener lo mejor de ambos mundos.

Descargo de responsabilidad：

1. Este artículo es reimpreso de [vitalik]，Reenvíe el Título Original '¿Cómo difieren realmente las capas 2 de la fragmentación de ejecución?', Si hay objeciones a esta reimpresión, por favor contacte al Gate Learnequipo, y ellos lo manejará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, está prohibido copiar, distribuir o plagiar los artículos traducidos.