Autor: Yiping, IOSG Ventures
El panorama de la Capa 2 está evolucionando rápidamente a medida que ZKRU como zkSync y StarkNet lanzan la red principal. Tradicionalmente, las OPRU como Arbitrum son las primeras en comercializar y, por lo tanto, tienen un ecosistema más sólido. Por el contrario, las ZKRU son avances tecnológicos que ofrecen un mayor rendimiento y tarifas más bajas.
En los últimos meses, una mayor actividad ha migrado de la Capa 1 a la Capa 2 en busca de transacciones más rápidas y económicas. El TVL de Ethereum ha caído de casi $40 mil millones a $20 mil millones durante el año pasado. Sin embargo, TVL para la Capa 2 presenta un panorama diferente, con un enorme crecimiento que indica que la adopción de la Capa 2 se está acelerando.
Arbitrum lidera el camino con más del 50% de participación de mercado de TVL de capa 2, aunque las ZKRU también se esfuerzan. La ventaja de Arbitrum de ser el primero en actuar le permite mantener su posición dominante.
El análisis del número de transacciones diarias muestra que las ZKRU como zkSync y StarkNet superan ligeramente a las OPRU en rendimiento. Sin embargo, la ventaja del ecosistema de Arbitrum se mantiene, a pesar de quedarse ligeramente atrás en el TPS diario.
Las OPRU existen desde hace más tiempo que las ZKRU. Sin embargo, las ZKRU están lanzando sus redes principales y atrayendo usuarios de otros ecosistemas. Como líder en el espacio OPRU, se espera que Arbitrum contrarreste el aumento de las ZKRU con sus nuevas actualizaciones.
Decisión: estilo
A medida que los desarrolladores optimicen la tecnología y los costos de conocimiento cero, es probable que las ZKRU sigan ganando participación de mercado debido a sus ventajas de escalabilidad. Sin embargo, los efectos de red de Arbitrum brindan la capacidad de permanecer sólido a pesar de las presiones competitivas. A través de soluciones innovadoras como Stylus, Arbitrum puede complementar su posición de liderazgo con capacidades técnicas únicas y continuar a la vanguardia de la carrera de Capa 2.
En resumen, Stylus es un nuevo y revolucionario entorno de contrato inteligente diseñado para Arbitrum que permite a los desarrolladores escribir programas eficientes e interoperables en lenguajes de programación como Rust, C++ y Solidity.
Abre la informática general a blockchain y da la bienvenida a los desarrolladores que utilizan diferentes pilas de tecnología.
WASM
Stylus funciona agregando una máquina virtual WebAssembly (WASM) que se ejecuta en paralelo con la máquina virtual Ethereum (EVM) existente. Los contratos inteligentes escritos en un lenguaje que se compila en WASM pueden ejecutarse de forma nativa 10 veces o más rápido que Solidity, lo que reduce significativamente los costos de gas. El EVM sigue siendo completamente funcional, por lo que los contratos de Solidity existentes siguen funcionando como lo hacen hoy. Dos máquinas virtuales funcionan sincrónicamente, lo que permite que los contratos escritos en diferentes lenguajes de programación se llamen entre sí y al mismo tiempo modifiquen el mismo estado subyacente de la cadena de bloques.
Precompilación personalizada
Además, Stylus también admite precompilaciones personalizadas.
Las precompilaciones son módulos de bajo nivel en Ethereum y Arbitrum que se utilizan para realizar funciones criptográficas o de utilidad específicas de manera muy eficiente. Por ejemplo, existen precompilaciones para la verificación de firmas ECDSA y el cálculo de hashes SHA256.
Agregar nuevas precompilaciones requiere que todos los validadores coordinen la actualización del EVM, por lo que la barrera de entrada es alta. Y con Stylus, los desarrolladores pueden implementar fácilmente sus propios precompiladores escritos en Rust o C++.
Por ejemplo, un equipo puede tomar una biblioteca criptográfica escrita en C e implementarla en Arbitrum sin modificaciones. Esto permitirá que estas primitivas criptográficas se ejecuten a velocidades nativas ultrarrápidas.
Otros contratos pueden llamar a este Stylus "precompilación" tal como llaman precompilación nativa para aprovechar esta tecnología criptográfica. Todas las mediciones de gas y pruebas de fraude funcionan automáticamente.
Esto permite al equipo crear prototipos de criptografía personalizada, curvas especiales basadas en emparejamiento y otras primitivas novedosas sin ningún soporte de cadena especial. Los investigadores de Ethereum pueden incluso obtener una ventaja en la iteración de propuestas EIP implementándolas como versiones precompiladas de Stylus en Arbitrum.
Al brindar a los desarrolladores la capacidad de introducir nuevas primitivas criptográficas de forma nativa en la cadena, Stylus amplía enormemente el alcance de lo que se puede construir. La precompilación ya no se limita a las funciones admitidas por EVM.
Cómo funciona el lápiz óptico
Antes de profundizar en el papel más amplio de WASM en el universo blockchain, es crucial comprender cómo Arbitrum orquesta la coexistencia de EVM y WASM. No se trata sólo de tener dos motores separados; es una relación sinérgica que potencia las fortalezas de ambos.
La arquitectura única de Arbitrum permite operaciones fluidas y sincronizadas entre EVM y WASM, gracias a su estado unificado, invocación entre VM y modelo económico compatible.
Los contratos inteligentes escritos en Solidity u otros lenguajes EVM se compilan en código de bytes EVM como de costumbre. Cuando se ejecutan, estos contratos se ejecutan en el EVM, tal como lo hacen hoy.
Para los lenguajes que se compilan en WASM, como Rust, C++ y C, el flujo de trabajo es:
Los desarrolladores utilizan compiladores WASM disponibles en el mercado, como Clang o Rustc, para compilar sus contratos inteligentes en WASM.
El código de bytes WASM se carga en la cadena Arbitrum en forma comprimida.
El propietario del contrato llama al método "compileProgram" precompilado "ArbWasm", que configura las herramientas de seguridad para WASM, lo calcula y lo compila en código nativo optimizado para el hardware del validador.
Cuando se llama a un contrato, se ejecuta en un tiempo de ejecución WASM como Wasmer, que es mucho más rápido que EVM, lo que ahorra tarifas de gas.
La medición WASM cobra gas antes de cada bloque básico en lugar de por código de operación como EVM. Esto es más eficiente y garantiza que el contrato no se salga de control.
EVM y WASM
Las dos máquinas virtuales (VM) se ejecutan sincrónicamente, lo que les permite llamarse entre sí mientras comparten el mismo estado global. Una transacción se puede ejecutar parcialmente en EVM y parcialmente en WASM, y los resultados se combinan sin problemas.
Espera, ¿cómo pueden dos máquinas virtuales funcionar sin problemas y sincronizadas?
Polkadot logra esto a través de XVM. A diferencia de Polkadot, WASM y EVM funcionan de forma fluida y sincrónica en Arbitrum por varias razones clave:
Estado único: ambas máquinas virtuales acceden a la misma estructura de datos subyacente y prueba de estado. Un contrato en una VM puede leer/escribir en la misma ubicación que un contrato en otra VM. Esto proporciona una vista unificada del estado de la cadena.
Llamadas entre VM: cuando una transacción interactúa con un contrato EVM, Geth la procesa y proporciona un resultado. Si el contrato EVM posteriormente llama a un programa WASM, WASM VM se hace cargo de calcular los resultados de esa parte.
Contexto compartido: la información del sistema, como datos de bloque, dirección del remitente, etc., está disponible para ambas máquinas virtuales. Un contrato WASM puede obtener el número de bloque al igual que un contrato Solidity.
Consenso único: los validadores ejecutan dos máquinas virtuales para validar las transacciones y llegar a un consenso sobre el estado correcto de la cadena. Las disputas invocarán el Sistema Uniforme de Prueba de Fraude.
Economía compatible: conceptos como la medición de gas se extienden a las máquinas virtuales individuales, lo que garantiza costos y recursos informáticos adecuados en cualquier entorno.
Para pruebas de fraude, el verificador divide las ejecuciones de EVM y WASM para identificar cualquier paso no válido si es necesario. La estructura de WASM permite que el sistema garantice la terminación y haga cumplir la validez de las pruebas.
Cadena de bloques |
Arbitrum no es la única plataforma que reconoce el potencial transformador de WebAssembly (WASM). Tanto Polkadot como Cosmos también han integrado WASM en sus ecosistemas, y cada plataforma ofrece un conjunto único de beneficios y características.
Polkadot permite a los usuarios desarrollar contratos inteligentes con WASM y admite dos lenguajes: AssemblyScript, un DSL integrado y Ink!, que es similar a Rust.
Cosmos, por otro lado, utiliza CosmWasm como tiempo de ejecución de contratos inteligentes, lo que permite a los desarrolladores escribir contratos en Rust.
Antes de profundizar en por qué la industria blockchain es tan receptiva a WASM, vale la pena comprender las ventajas específicas que destacan Cosmos y Polkadot:
Cosmos destaca las siguientes ventajas de WASM:
Compatibilidad con bibliotecas Rust
Comunidad de desarrolladores diversa
Seguridad mejorada, incluida la protección contra ataques de reentrada
Fácil de probar
rendimiento alto
El tiempo de ejecución WASM de Polkadot tiene estas características:
rendimiento alto
Interoperabilidad con EVM
Independiente de la plataforma
Tamaño binario compacto
Admite Rust y AssemblyScript (versión TypeScript)
Si bien Polkadot, Cosmos y Arbitrum comparten algunos beneficios comunes que ofrece WASM, cada plataforma también tiene sus propios atributos únicos.
La adopción generalizada de WASM por parte de estas importantes plataformas blockchain es un testimonio de su creciente importancia en la industria, por lo que es fundamental comprender por qué esta tecnología se está convirtiendo rápidamente en una piedra angular de la arquitectura blockchain moderna.
¿Por qué elegir WASM?
¿Qué es WASM?
Para comprender la sinergia entre blockchain y WebAssembly (WASM), primero se debe comprender qué es WASM y la fuerza impulsora detrás de su desarrollo.
WebAssembly es un formato de instrucción binaria que permite que el código se ejecute a una velocidad casi nativa dentro de un navegador web. Sirve como objetivo de compilación para una variedad de lenguajes de programación, incluidos C y Rust, y está diseñado para ser rápido, eficiente y seguro. WASM cierra eficazmente la brecha entre la programación basada en web y a nivel de sistema, mejorando así el rendimiento y la funcionalidad de la web.
"Web" en WebAssembly destaca su capacidad para ejecutarse dentro de un entorno JavaScript (que generalmente se encuentra en un navegador). En estas configuraciones, los desarrolladores tienen acceso completo a la API WASM y cuentan con soporte completo de API web, lo que les brinda un control considerable sobre el comportamiento web.
Historia WASM
Siguiendo el principio de "escribir una vez, ejecutar en cualquier lugar", WASM surgió como una poderosa solución a una serie de desafíos de larga data. A partir de 2016, muchos programas introducen nuevas funciones a través de lenguajes de dominio específico (DSL), que a menudo implican compensaciones entre mantenimiento, eficiencia y seguridad. Existe una necesidad creciente de una solución que pueda proporcionar nuevas funciones a innumerables servidores sin comprometer estos aspectos.
Se evaluaron las deficiencias de varias soluciones existentes:
- Máquina virtual del sistema
El inicio y el apagado frecuentes generan una sobrecarga excesiva
Falta de visibilidad del código para garantizar la seguridad.
Demasiado abstracto sobre los requisitos de rendimiento.
- contenedor
Falta de visibilidad del código para garantizar la seguridad.
Ineficiente debido a la abstracción de alto nivel
Las operaciones frecuentes generan importantes gastos generales
- Máquina virtual a nivel de lenguaje
Requiere modificaciones frecuentes para garantizar la seguridad.
Las máquinas virtuales integradas, como V8, consumen muchos recursos
Lenta adaptación del nuevo lenguaje al modelo de seguridad
todavía demasiado abstracto
- Arquitectura del conjunto de instrucciones (ISA)
Difícil hacer un sandbox efectivo
Los proyectos anteriores de Google se trasladaron a WASM
Falta de implementación madura
En 2018, el desarrollo de WASM cobró impulso y se centró en ejecutarse en varias arquitecturas, servidores, hardware integrado e incluso admitir múltiples idiomas. A diferencia de Java, WASM está diseñado sin comprometer la seguridad. En 2019, se introdujo un modelo de componentes para mejorar el módulo WASM, permitiendo la interoperabilidad en varios idiomas. Esto permite soluciones como escribir una biblioteca HTTP una vez y usarla en varios idiomas.
Hasta la fecha, WASM tiene una variedad de capacidades y se adopta cada vez más en escenarios nativos de la nube, incluida la cadena de bloques. Sus ventajas incluyen:
rendimiento alto
Tamaño binario compacto
Portabilidad multiplataforma
Admite múltiples lenguajes, como C/C++, Rust, AssemblyScript, etc.
Ejecutar en motor JavaScript
Potente sandbox con límites de memoria y CPU
Tiempos de inicio extremadamente rápidos, normalmente en milisegundos o menos
La comunidad WASM continúa trabajando para lograr una mayor integración y rendimiento en todos los idiomas.
Comprender la evolución histórica de WASM nos proporciona un contexto valioso para comprender sus funciones actuales y potenciales en una variedad de entornos, incluidos proyectos blockchain como Stylus. Estos antecedentes nos brindan una comprensión matizada al explorar los problemas y preocupaciones relacionados con la implementación de WASM en el ecosistema blockchain.
Preguntas y respuestas sobre el lápiz óptico
Soporte de idiomas
La evolución de WASM revela por qué Stylus es una incorporación interesante al ecosistema Arbitrum, pero también destaca algunas limitaciones y preocupaciones. Una de las preocupaciones es el soporte lingüístico. Si bien Stylus amplió la comunidad de desarrolladores de Arbitrum para incluir lenguajes como C++ y Rust, no logró adoptar lenguajes populares como JavaScript y Python.
Si bien existen proyectos preliminares destinados a llevar Python y JavaScript a WASM, estos esfuerzos aún no están listos para una adopción generalizada debido a desafíos con la recolección de basura y problemas de rendimiento.
Compatibilidad de idiomas
Actualmente, Stylus admite C/C++ y Rust SDK, integrándose perfectamente con cadenas de herramientas para estos lenguajes. Los desarrolladores pueden incluso integrar bibliotecas de terceros, como implementaciones criptográficas nativas, al crear contratos inteligentes. La principal limitación de hacer algo como esto son los costos de gas asociados.
Si bien el SDK de Rust aún está en su infancia, tanto el SDK de Rust como el de C carecen de algunas características. Por ejemplo, el SDK de C no admite funciones exportadas ABI y los modificadores aún no son compatibles con ninguno de los SDK.
Actualmente, no existe un entorno de prueba local de Stylus, pero los desarrolladores pueden ejecutar pruebas directamente dentro del SDK. Para implementar contratos inteligentes, testnet es actualmente la única opción y aún no admite la verificación de contratos inteligentes. Actualmente se están realizando esfuerzos para incorporar varios tokens ERC y **[Uniswap V2]** al ecosistema Stylus.
El dilema de la elección del idioma
Elegir entre lenguajes de dominio específico (DSL), DSL integrados (eDSL) y lenguajes de propósito general requiere un equilibrio entre control de bajo nivel y abstracción de alto nivel. Desarrollar un DSL completamente nuevo requiere inversiones significativas en el desarrollo de ecosistemas y cadenas de herramientas. Por el contrario, como subconjunto de un lenguaje de propósito general, eDSL permite una integración más sencilla con herramientas existentes y tiene una curva de aprendizaje más baja. Por ejemplo, sería beneficioso crear un eDSL en un lenguaje popular como JavaScript o Python.
Un lenguaje común requiere el uso de un SDK, que introduce herramientas adicionales, aumenta la verbosidad y hace que el código sea menos expresivo, junto con llamadas API y operaciones de objetos más largas.
Encontrar el equilibrio adecuado entre la elección del idioma y el desarrollo de eDSL puede ser la clave para atraer a una comunidad de desarrolladores más amplia y al mismo tiempo proporcionar herramientas fáciles de usar. Según los datos actuales, la principal comunidad de desarrolladores de criptomonedas todavía se concentra en Ethereum. Sin embargo, las plataformas que aprovechan Rust para contratos inteligentes, como Polkadot, Cosmos y Solana, también están ganando terreno y creciendo rápidamente entre sus comunidades de desarrolladores.
actuación
WASM mejora significativamente la velocidad de ejecución y reduce el tamaño de los paquetes. Si bien Stylus aún no se ha implementado en la red principal, los puntos de referencia de otras redes pueden servir como referencia útil. Los tiempos de ejecución observados son de 4 a 8 veces más rápidos y el tamaño compilado se reduce aproximadamente un 50 %.
Actualmente, Stylus tiene un límite de tamaño en sus contratos, limitado a aproximadamente 128 KB sin comprimir. Esta limitación dificulta la portabilidad de grandes contratos inteligentes de otros lenguajes como Solidity. En la base del código Stylus, este límite se describe a continuación:
Vale la pena señalar que WASM genera algunos gastos generales al iniciar y cerrar. Para operaciones ligeras, EVM puede ser más rentable que WASM.
Interoperabilidad con EVM
EVM y WASM comparten las mismas ranuras de almacenamiento y árboles de estado, lo que facilita la interoperabilidad de Stylus con EVM. Esto se logra a través de la API EVM implementada en WASM, utilizando el popular patrón Host I/O. Una lista completa de API de EVM compatibles demuestra que la interoperabilidad es totalmente compatible.
Contrato precompilado personalizado
Este aspecto es particularmente interesante porque representa un territorio inexplorado. Los contratos precompilados personalizados tienen el potencial de incorporar primitivas criptográficas adicionales a la cadena con menores costos de ejecución. También pueden reducir el costo de la inferencia al introducir cálculos tensoriales como contratos precompilados. Sin embargo, parece que no existe ningún código relacionado con contratos precompilados personalizados. Aunque existen contratos precompilados para componentes EVM, no se pueden intercambiar en caliente.
Es posible que esta característica aún esté en desarrollo, aprovechando las capacidades de WASM. El EVM puede llamar funciones escritas en WASM y luego compilarlas en código de máquina.
Funcionalidad reentrante
A diferencia de CosmWasm (que adopta un modelo Actor sin reentrada), Rust SDK de Stylus desactiva la reentrada como indicador de función de forma predeterminada. Los desarrolladores tienen la opción de habilitar esta función manualmente.
Activar la reentrada requerirá algunos ajustes de API. En particular, los desarrolladores deben tener cuidado cuando se trata de precauciones de seguridad, como actualizar las cachés de almacenamiento durante las llamadas.
Conocimiento
Stylus abre nuevos casos de uso que consumirían demasiado gas si se usara solo el EVM, como el cifrado de alto rendimiento, los juegos y la IA. También permite personalizar contratos precompilados, lo que permite a los desarrolladores agregar su propio cifrado y otras funciones básicas sin tener que esperar actualizaciones. En el pasado, hemos visto algunos ecosistemas que no son Ethereum adoptar WASM, como Cosmos y Polkadot. Esta es la primera vez que la comunidad Ethereum adopta WASM. En general, Stylus representa una evolución significativa en el desarrollo de contratos inteligentes y ayudará a Ethereum y Arbitrum a escalar mientras mantiene la interoperabilidad con todas las aplicaciones existentes.
La integración de Stylus en el SDK de Capa 2 de Arbitrum proporciona una mayor flexibilidad a los desarrolladores de Capa 3. Ahora pueden trasladar a la cadena cálculos intensivos que anteriormente excedían los límites de gas, abriendo nuevas posibilidades. Los desarrolladores ya no se limitan a Solidity, sino que también pueden elegir Rust o C++ si esos lenguajes se adaptan mejor a sus necesidades y experiencia. Los contratos precompilados personalizados permiten una migración fluida de funciones criptográficas, de utilidad y otras funciones auxiliares preferidas a la cadena para un rendimiento óptimo. Escribir lógica de bajo nivel directamente en un lenguaje adaptado a cada caso de uso conduce a un desarrollo más fluido. Los desarrolladores pueden centrarse en la funcionalidad principal del producto en lugar de recurrir a soluciones alternativas para evitar costos de gasolina. Al eliminar las restricciones de idioma y gas, Stylus permite a los desarrolladores de tercer nivel crear las experiencias de usuario más eficientes desde el principio, utilizando las herramientas adecuadas para su dominio.
Stylus también demuestra la capacidad de Arbitrum para innovar a escala e integrar nuevas máquinas virtuales. Ed Felten, cofundador y científico jefe de Arbitrum & Offchain Labs mencionó que Arbitrum se desarrolla en base a herramientas y lenguajes de programación populares en la industria. Pueden escribir pruebas más rápidamente y desarrollar nuevas funciones además de sus sistemas heredados. OP ha ido más allá en el camino de la ZKización y ha avanzado gradualmente hacia la idea del Rollup híbrido. Optimism está trabajando actualmente con Risc0 para utilizar Zeth para generar pruebas de conocimiento cero para OPRU. Al utilizar esta solución, Optimism no necesita realizar modificaciones adicionales en OPRU. Si estás interesado en Zeth, puedes leer lo que escribí antes [Twitter].
Tenemos muchas ganas de ver aplicaciones de IA en Arbitrum. Actualmente, realizar aprendizaje automático en cadena requiere mucho gas, lo que encarece el desarrollo. El aprendizaje automático de conocimiento cero puede reducir los costos, pero también introduce una complejidad adicional significativa para los desarrolladores. Si pudiéramos implementar operaciones tensoriales como contratos precompilados personalizados a través de Stylus y ejecutarlas de forma nativa a una fracción del costo, se abrirían nuevas posibilidades para el aprendizaje automático en cadena de alto rendimiento. Al permitir a los desarrolladores crear e implementar rápidamente algoritmos de aprendizaje automático como contratos precompilados fáciles de integrar en un lenguaje con el que están familiarizados, como Python, Arbitrum puede impulsar la próxima generación de innovación en IA en DeFi, GameFi y más. El rendimiento y la flexibilidad de Stylus nos permitirán centrarnos en arquitecturas de aprendizaje automático innovadoras en lugar de en la optimización del gas. Esperamos ver la creatividad de la comunidad aplicada a este paradigma emergente.
