Ethereum RISC-V roadmap and Arbitrum Stylus SDK developments

The division of instruction set architectures (ISA) dictates how builders interact with onchain execution. Delivery ISA (dISA) defines the format where smart contracts live, such as Wasm in Stylus. Proving ISA (pISA) determines the low-level instruction set used inside proving circuits. Execution ISA (eISA) governs the ISA that node software uses to execute the state transition function. A builder interacts almost entirely with the delivery layer. The delivery ISA does not need to match the proving ISA or the execution ISA. Wasm fits the delivery role because it compiles into whatever proving ISA or backend emerges in the future. While some researchers suggest replacing the EVM with RISC-V to increase scalability, this plan faces maintenance hurdles regarding precompiles and interpretation overhead. All RISC-V zk-VMs use precompiles for computationally intense operations like signatures and hashes. This means prover time will remain dominated by these precompiles. To gain advantages in maintenance and scalability, a system requires an architecture that runs contracts as executables without interpretation overhead. A researcher argues that maintenance of the out-of-EVM part of the execution client becomes easy if performance is good enough. However, a system requires a minimal MMU to prevent contracts from writing to kernel memory. Does a RISC-V architecture that relies on EVM precompiles truly escape the limitations of current prover performance?

Wasm performance gains

Wasm provides builders with predictable speed and structured execution. Stylus allows Wasm contracts to run alongside EVM contracts while sharing the same state tree. This configuration provides a 34.3% reduction in base computational overhead, lowering it from 35k to 23k. Wasm contracts compile to native machine code on ARM and x86 platforms, providing near-native execution speed without specialized hardware. RedStone uses this capability to process many feeds per transaction and handle structured datasets far larger than EVM-only oracles. RedStone manages data windows up to 1MB per block for specialized use cases. RedStone separates its architecture into three independent layers: aggregation, signing, and onchain verification. This modular structure allows for flexibility and makes it easy to integrate new data sources without altering how verification works. Wasm uses structured blocks instead of arbitrary jumps to improve safety and speed. This allows the virtual machine to validate programs in linear time and enables safe, deterministic injection of gas meters. You should note that Wasm contracts behave predictably because they avoid hazardous bytecode patterns.

SDK developments in October

The Arbitrum Stylus ecosystem moves toward production maturity through continuous SDK development. The AssemblyScript SDK recently completed milestones #8 and #9, expanding data modeling through advanced mapping support. These updates include dynamic type handling for strings and beta support for structs as mapping values. The AssemblyScript SDK also includes automated local testing using a Nitro dev node in Docker. The LocalNodeManager class handles the Docker container lifecycle and provides health checks with a 3-minute timeout. This testing environment returns a contract instance, wallet clients, and a cleanup function. The Rust SDK maintains ABI equivalence, which lets existing Solidity DEXs list Rust tokens without modification. The SDK includes macros like sol_storage! to handle storage layouts and sol_interface! to transform Solidity interface definitions into Rust structs and methods. An audit of the OffchainLabs/stylus-sdk-rs repository identified 36 issues, including 2 critical and 2 high severity findings, though most were resolved. The derive_solidity_error macro allows Rust enums to be used for error handling in contract methods by converting them to Solidity-compatible error messages. The AssemblyScript SDK expands its mapping system to support broader type combinations and dynamic data handling, which enables developers to implement complex onchain state patterns like registries, voting systems, and various DAO-style architectures.

Developer experience and limitations

Developer workflows encounter friction despite the expansion of language support. LimeChain reports that the lack of a compile command in the cargo-stylus CLI creates non-intuitive workflows. Developers must use the native cargo CLI for compilation and then use cargo-stylus for deployment. Setting up projects for both binary and library modes adds complexity to the development environment. Current development stacks also focus on single entrypoint programs, which complicates deployment for those with extensive EVM experience. Even compact and WASM-optimized crates have to be explicitly configured and stripped down to fit into the size requirements of Stylus programs. This requirement adds friction for developers accustomed to simpler deployment flows. Stylus contracts also require reactivation every 365 days or after a Stylus upgrade to remain callable. The maximum contract size reaches 96 KB, which is four times the 24 KB limit for Solidity contracts. The 365-day expiry and a minimum age of about 31 days before a contract can be kept alive are configurable chain parameters. Storage-heavy contracts gain little from porting because storage operations cost roughly the same as in the EVM.