La reciente actualización de Arbitrum presenta la actualización Stylus VM, que cuenta con varias mejoras:

• Soporte de idiomas ampliado
• Reducción de costos y uso de memoria.
• Precompiladores personalizables
• Compatibilidad EVM

Estas mejoras surgen de la integración de WASM, reconocido por sus numerosos beneficios dentro de entornos nativos de la nube. En las secciones siguientes se cubrirán más detalles sobre el papel de WASM.

Pioneros

Arbitrum ha introducido WASM en su cadena, pero no es la plataforma inaugural para hacerlo. Polkadot permitió anteriormente la creación de contratos inteligentes WASM. Ofrece dos lenguajes para esto: un script ensamblador similar a un DSL integrado y un lenguaje inspirado en Rust llamado ink.

De manera similar, Cosmos utiliza CosmWasm para la ejecución de contratos inteligentes. Los desarrolladores pueden crear contratos inteligentes utilizando Rust aquí.

Antes de explorar la afinidad que tiene blockchain por WASM, revisemos los motivos de Cosmos y Polkadot para elegir WASM.

Cosmos promociona WASM por estas ventajas:

• Compatibilidad de la biblioteca Rust
• Una amplia comunidad de desarrolladores
• Seguridad mejorada, incluida la prevención de ataques de reentrada
• Procedimientos de prueba simplificados
• Rendimiento superior

El tiempo de ejecución WASM de Polkadot presenta características como:

• Actuación excepcional
• Interoperabilidad EVM
• Independencia de la plataforma de hardware y software
• Tamaño compacto
• Soporte para Rust y Assembly Script, similar a Typecript

Polkadot, Cosmos y Arbitrum comparten varios beneficios inducidos por WASM. Sin embargo, Arbitrum tiene ofertas distintivas que discutiremos más adelante, junto con detalles de Cosmos.

ERA M

Profundicemos en qué es WASM y las motivaciones detrás de él.

¿Qué es WASM?

WebAssembly (WASM) es un formato de instrucción binaria. Permite que el código se ejecute a velocidades comparables a las de las aplicaciones nativas, específicamente en los navegadores web. Como destino de compilación para lenguajes como C y Rust, está optimizado para brindar velocidad, eficiencia y seguridad. WASM mejora significativamente el rendimiento web y amplía las funcionalidades web.

WASM está estrechamente vinculado a la web, ya que opera dentro de entornos JavaScript como los navegadores. Dentro de estos entornos, los desarrolladores tienen acceso completo a las API WASM, así como soporte completo de API web. Este control permite a los desarrolladores ajustar las interacciones web.

La evolución de WASM

El concepto de WASM gira en torno al ideal de escribir código una vez para ejecutarlo en cualquier lugar.

En 2016, los programas introdujeron con frecuencia nuevas funciones a través de lenguajes específicos de dominio (DSL). La creación de un DSL implicó equilibrar el mantenimiento, la eficiencia y la seguridad. La industria buscaba un método para implementar funciones en numerosos servidores sin comprometer estos aspectos.

Se examinaron varias soluciones, cada una con su propio conjunto de desafíos:

• Las máquinas virtuales del sistema tenían problemas con los gastos generales, la falta de visibilidad del código por motivos de seguridad y eran demasiado abstractas para un alto rendimiento.
• Los contenedores también carecían de visibilidad del código y eran igualmente abstractos, con una sobrecarga significativa.
• Las máquinas virtuales a nivel de lenguaje requerían modificaciones frecuentes por motivos de seguridad, generaban gastos generales debido a las máquinas virtuales integradas como V8 y tardaban en adoptar nuevos lenguajes para adaptarse a los modelos de seguridad.
• Las arquitecturas de conjuntos de instrucciones (ISA) eran difíciles de modificar para lograr un espacio aislado eficiente y carecían de implementaciones maduras.

WASM surgió como una solución. Comenzó el desarrollo de compiladores WASM y, en 2018, se amplió el concepto de compatibilidad de código universal entre diversas arquitecturas y dispositivos. A diferencia de Java, el objetivo no era comprometer la seguridad.

En 2019, se introdujo el modelo de componentes, elevando los módulos WASM para la interoperabilidad en varios idiomas. Esta innovación permitió, por ejemplo, la creación de una biblioteca HTTP universal aplicable en diferentes idiomas, abordando cuestiones complejas de manera innovadora.

WASM hoy

WASM cuenta con una variedad de características impresionantes:

• Alto rendimiento : el código WASM se ejecuta de manera eficiente y rápida.
• Tamaño compacto : el formato binario de WASM garantiza un tamaño reducido.
• Portabilidad : permite que el mismo código de bytes funcione en cualquier tiempo de ejecución compatible con WASM.
• Soporte de idiomas : WASM admite una amplia gama de lenguajes, desde C/C++ y Rust hasta Go y Swift, entre otros.
• Compatibilidad con motores JavaScript : WASM funciona perfectamente con motores JS.
• Sandboxing : un sandbox robusto y predeterminado restringe el acceso a la memoria y a la CPU para evitar interferencias externas.
• Inicio rápido : los módulos WASM normalmente arrancan en milisegundos.

La comunidad WASM está mejorando activamente la integración y el rendimiento en diferentes lenguajes de programación.

Aguja

Explorar el potencial de WASM y su uso en blockchains nos lleva de regreso a las limitaciones de Arbitrum Stylus.

Funcionamiento del lápiz

Aquí hay un desglose simplificado de cómo funciona Stylus:

1. Los desarrolladores utilizan compiladores WASM estándar, como Clang o Rustc, para compilar sus contratos inteligentes en WASM.
2. Luego, el código de bytes WASM resultante se carga en la cadena Arbitrum en un estado comprimido.
3. A través del método compileProgram de la precompilación ArbWasm , el código de bytes se instrumenta para seguridad, medición de gas y se compila en código nativo adaptado al hardware del validador. Este paso es crucial para mejorar el rendimiento y la seguridad.
4. Tras la invocación, el contrato se ejecuta en un tiempo de ejecución WASM, como Wasmer, que es significativamente más rápido y eficiente en cuanto a gas que el EVM.

El tercer paso aparentemente adicional es, de hecho, vital. La conversión de código WASM a código de máquina nativo acelera las velocidades de ejecución. Además, esta fase de compilación adicional ayuda a evitar "bombas de compilación".

Una "bomba de compilación" es un código malicioso diseñado para agotar los recursos del sistema durante la compilación, lo que puede provocar que el compilador se bloquee o se detenga. Esto actúa como un ataque de denegación de servicio destinado a obstaculizar el proceso de desarrollo de software.

Preocupaciones sobre el lápiz óptico

Ayuda de idioma

Stylus ha ampliado la comunidad de desarrolladores de Arbitrum para incluir C++ y Rust. Sin embargo, todavía tiene que abarcar a las comunidades de desarrolladores más predominantes de la actualidad. Facilita la ejecución de contratos inteligentes en navegadores, pero aún no es compatible con JavaScript y Python.

Hay proyectos en las primeras etapas que intentan unir Python y JavaScript con WASM. Sin embargo, estos no están listos para una adopción generalizada debido a las complejidades de la recolección de basura y los problemas de rendimiento.

Compatibilidad de idiomas

Stylus actualmente admite C/C++ y Rust a través de sus SDK. Estos SDK son compatibles con las herramientas de los respectivos idiomas. También permiten la integración de bibliotecas de terceros, como la criptografía nativa. La principal limitación es el costo del gas asociado con estas bibliotecas.

El SDK de Rust se encuentra en su fase incipiente y carece de algunas funcionalidades. El C SDK no admite funciones de exportación con ABI. Además, ninguno de los SDK admite el uso de modificadores.

Por ahora, Stylus no tiene un entorno de prueba local. Se anima a los desarrolladores a realizar pruebas dentro de los SDK. La testnet es la única opción para ejecutar contratos inteligentes en Stylus. Sin embargo, la testnet aún no ha implementado la verificación de contratos inteligentes.

Se está trabajando en la portabilidad de varios tokens y plataformas ERC como Uniswap V2 a Stylus.

Elección de idioma

Elegir entre un lenguaje de dominio específico (DSL), un DSL integrado (eDSL) o un lenguaje de programación general es un desafío. Los desarrolladores deben sopesar los beneficios de trabajar "cerca del metal" para el control frente a la facilidad de uso que ofrecen las abstracciones de nivel superior, que pueden limitar la flexibilidad.

La creación de un nuevo DSL requiere tiempo para desarrollar sus cadenas de herramientas y su ecosistema. Un eDSL, como subconjunto de un lenguaje de programación general, mantiene la misma semántica y sintaxis. Permite a los desarrolladores utilizar lenguajes y herramientas existentes, lo que puede simplificar el proceso de aprendizaje. Un eDSL también ofrece una mejor interoperabilidad con código de propósito general. Por ejemplo, un eDSL para JavaScript o Python sería estratégico para involucrar a las comunidades de desarrolladores más grandes.

Los lenguajes de programación generales requieren el uso de un SDK para el desarrollo. Esto agrega capas de herramientas, aumenta la verbosidad y reduce la expresividad. También puede dar lugar a largas llamadas API y operaciones de objetos complejas.

Elegir el idioma correcto y crear un eDSL podría ser un compromiso ideal. Podría atraer desarrolladores de comunidades populares y ofrecer herramientas fáciles de usar. Los datos actuales muestran que la comunidad Ethereum sigue siendo la más grande entre los desarrolladores de criptomonedas. Sin embargo, ecosistemas como Polkadot, Cosmos y Solana, que utilizan Rust para contratos inteligentes, también están atrayendo a un número significativo de desarrolladores y están experimentando un rápido crecimiento.

Actuación

WASM tiene el potencial de mejorar significativamente la velocidad de ejecución y reducir el tamaño del paquete. Aunque Stylus no se ha implementado en la red principal, los puntos de referencia de otras redes sirven como referencia útil.

Estos puntos de referencia indican que los tiempos de ejecución se pueden reducir de 4 a 8 veces y el tamaño compilado se puede reducir a la mitad.

Stylus impone un límite en el tamaño de los contratos, que es de aproximadamente 128 KB sin comprimir. Esta restricción dificulta la migración de contratos inteligentes muy grandes de lenguajes como Solidity a Stylus. Esta limitación es evidente en el código base de Stylus:

 // arbos/programs/programs.go const MaxWasmSize = 128 * 1024 // Maximum WASM size allowed const initialFreePages = 2 // Number of initial free pages const initialPageGas = 1000 // Gas cost for an initial page const initialPageRamp = 620674314 // Adjusts for a target size cost const initialPageLimit = 128 // Maximum number of pages allowed const initialInkPrice = 10000 // Ink price per EVM gas const initialCallScalar = 8 // Scalar for call cost

Es importante tener en cuenta que WASM genera algunos gastos generales al iniciar y cerrar. Para operaciones muy ligeras, EVM podría ser más rentable que WASM.

Interoperabilidad EVM-WASM

EVM y WASM utilizan las mismas ranuras de almacenamiento y árbol de estado. Stylus logra interoperabilidad con EVM mediante la implementación de API de EVM dentro de WASM. Esta integración utiliza el modo Host I/O ampliamente adoptado en WASM. A continuación se muestra la lista completa de las API de EVM compatibles con WASM, lo que indica un soporte de interoperabilidad integral.

 read_args write_result storage_load_bytes32 storage_store_bytes32 call_contract delegate_call_contract static_call_contract do_call create1 create2 do_create read_return_data return_data_size emit_log account_balance account_codehash evm_gas_left evm_ink_left block_basefee block_coinbase block_gas_limit block_number block_timestamp chainid contract_address msg_reentrant msg_sender msg_value native_keccak256 tx_gas_price tx_ink_price tx_prigin memoery_grow console_log_text console_log console_tee

Precompilaciones personalizadas

Las precompilaciones personalizadas son un concepto innovador. Tienen el potencial de integrar primitivas criptográficas avanzadas en cadena con costos de ejecución reducidos. Por ejemplo, los cálculos tensoriales podrían precompilarse para reducir los costos del aprendizaje automático en cadena. Sin embargo, no hay evidencia de funcionalidad de precompilación personalizada en el código base actual. Si bien existen precompilaciones para EVM, no están diseñadas para ser intercambiables.

Es probable que estas funciones todavía se estén desarrollando, aprovechando las capacidades de WASM. Esto permitiría a EVM llamar a funciones escritas en WASM, que luego se compilan en código de máquina.

Reentrada

A diferencia del modelo de actor de CosmWasm, que no admite la reentrada, el SDK Rust de Stylus incluye la reentrada como característica opcional. De forma predeterminada, esta función está desactivada. Los desarrolladores tienen la opción de habilitar la reentrada en sus contratos.

La activación de la reentrada afecta la API, ya que los desarrolladores deben asegurarse de borrar el caché de almacenamiento durante las llamadas y considerar otras medidas de seguridad. Esta precaución es esencial para evitar posibles vulnerabilidades asociadas con las llamadas reentrantes.

Conclusión

WASM está ganando popularidad en el dominio nativo de la nube, y muchas cadenas de bloques lo adoptan para la ejecución de contratos inteligentes. Aunque Arbitrum no es pionero en esta integración, su implementación podría tener un gran impacto. WASM no está posicionado para reformar completamente el panorama de blockchain ni reemplazar a EVM. Sin embargo, podría aumentar la ventaja de Arbitrum frente a los emergentes zk-rollups. El término "EVM+" de Arbitrum describe acertadamente este escenario. EVM sienta las bases para las plataformas de contratos inteligentes y WASM podría proporcionar un impulso adicional de rendimiento para Arbitrum.