
Da Shi Dai Engine WASM: Driving a New Paradigm for Smart Contracts and Cross-chain Interactions
TechFlow Selected TechFlow Selected

Da Shi Dai Engine WASM: Driving a New Paradigm for Smart Contracts and Cross-chain Interactions
Wasm's portability and high performance make it one of the key technologies in the blockchain field.
Author: Mike@Foresight Ventures
TL;DR
WebAssembly (abbreviated as Wasm) is a portable, high-performance binary instruction format that can run in web browsers. It is designed as a universal compilation target for multiple programming languages and can operate across different platforms.
Blockchain is a decentralized distributed ledger technology that ensures data security and trustworthiness through cryptography and consensus algorithms. Blockchain can be used to record transactions, store data, and execute smart contracts.
There are several relationships and application scenarios between Wasm and blockchain:
-
Smart Contracts: Wasm can serve as the execution environment for smart contracts, enabling them to run on various blockchain platforms. The high performance and portability of Wasm allow smart contracts to execute more efficiently and be used cross-platform.
-
Cross-chain Interaction: Wasm can enable cross-chain functionality. By compiling logic from different blockchains into Wasm code, identical logic can be executed across chains, enabling cross-chain data transfer and interaction.
-
Off-chain Computing: Wasm can perform computations outside the blockchain and submit results back to it. This maintains data security and verifiability while improving computational efficiency and flexibility.
-
Data Privacy: Wasm can help protect data privacy on blockchain. Sensitive data processing logic can be compiled into Wasm code and executed on-chain, preserving privacy while ensuring computational verifiability.
In summary, Wasm and blockchain can be combined to deliver more efficient, secure, and flexible blockchain applications and services. The portability and high performance of Wasm make it a key technology in the blockchain space.

1. What is WebAssembly?
WebAssembly is an efficient, lightweight instruction set standard developed by W3C (World Wide Web Consortium), hailed as a game-changer for the web and high-performance computing, supporting cross-browser execution. This means we can compile various programming languages—including C/C++, Go, Rust—into a unified binary format and use it in browsers at near-native speed, serving as an alternative to JavaScript.

WebAssembly, or WASM for short, is memory-safe and platform-independent, efficiently mapping to all types of CPU architectures. Its main advantages include:
-
Efficiency: WASM has a complete set of language features. As a compact and fast-loading binary format, its goal is to fully leverage hardware capabilities to achieve native-level execution speed.
-
Security: WASM runs in a memory-safe, sandboxed execution environment, which can even be implemented within existing JavaScript virtual machines. In web environments, WASM strictly adheres to same-origin and browser security policies. WASM has minimal interfaces at compile time, and most WASM applications cannot access the network (due to lack of socket support), currently only supporting local databases. Many security issues stem from illegal memory access during execution, which WASM avoids at compile time.
-
Compatibility: WASM is designed for the web to be versionless, feature-testable, and backward-compatible. WASM can be called by JavaScript, enter JavaScript contexts, and invoke browser functionalities like Web APIs. Beyond browsers, WASM can also run in non-web environments such as Node.js, Deno, and IoT devices. Unlike traditional approaches requiring multiple compilations, WASM needs only one compilation—truly plug-and-play.

Additionally: The web is the only truly universal platform, allowing your application to be accessed from any device. This enables maintaining a single codebase, simplifying updates and ensuring accessibility for all users. WASM supports both 64-bit and 32-bit integer operations, directly corresponding to CPU instructions. By eliminating floating-point arithmetic, determinism is easily achieved—a necessity for consensus algorithms. Supported by the LLVM compiler infrastructure project, WASM benefits from over a decade of LLVM compiler optimizations. WASM is continuously developed by major companies such as Google, Apple, Microsoft, Mozilla, and Meta, with their browsers' backends all supporting WASM compilation.
The beauty of WASM lies in its being like a magic engine—it can run anywhere without downloads or installations, thanks to its binary format. With just one click, web applications launch instantly when needed. It’s safer than downloading and running binary files directly because browsers have built-in security mechanisms preventing harmful code execution. Sharing web apps is equally simple—links are clickable strings that can be placed anywhere.

2. Why Do We Need WebAssembly?
2.1 Web2
Thanks to built-in browser features and the interactivity offered by the web, the web has evolved from static hypertext content and small scripts into a powerful and popular platform filled with impressive applications and functionalities. However, web applications are still primarily driven by the same scripting language—JavaScript—even though JavaScript was never originally designed for these advanced uses.
JavaScript started as a simple scripting language intended to add interactivity to lightweight hypertext documents on the web. It was designed to be easy to learn and write, not to be fast. Over the years, significant performance improvements in JavaScript parsing have led to notable speed gains.
As JavaScript became faster, the range of what could be done in browsers expanded dramatically. New APIs enabled interactive graphics, video streaming, offline browsing, and more. Increasingly, applications previously limited to native software began moving to the web. Today you can easily edit documents and send emails in your browser. Yet in certain domains, JavaScript's performance remains a bottleneck. Consider the software you use beyond browsers—games, video editing, 3D rendering, or music production. These applications require heavy computation and high performance. JavaScript struggles to meet these demands.
Replacing JavaScript entirely isn't practical—it might take decades, given how deeply entrenched it is across the internet. Moreover, many people continue improving JavaScript. While JavaScript has shortcomings in areas like null and == compared to other languages, these flaws aren’t severe enough to warrant abandoning the entire technology.

Thus, WebAssembly won’t replace JavaScript, but this doesn’t mean WASM won’t be widely adopted. In fact, WASM usage will likely grow. WASM brings strong computational power to the web—for tasks like image processing or gaming. With WASM, you could build a fully functional web-based Photoshop or a 3D game running at 60 FPS or higher in the browser. Games are particularly challenging because they involve simultaneous audio and video processing, physics simulation, and AI coordination. WASM’s ability to efficiently run games in browsers opens doors for bringing many other applications online.


The above diagram compares JavaScript and WASM workflows, showing that WASM is significantly more streamlined than JavaScript.
2.2 Web3
WASM VM
In 2018, discussions emerged within the Ethereum ecosystem about using a WASM VM as the smart contract virtual machine due to its superior performance over the EVM. Gavin Wood, creator of the EVM, acknowledged the feasibility of replacing EVM with WASM, and Vitalik Buterin indicated Ethereum 2.0 would upgrade to WASM-based contracts (eWASM) to better meet developer needs. Today, WASM-based contracts have begun taking shape.
2.3 How Was the EVM Designed? Why Is It Inefficient?
Excessive Architecture Size
Traditional computers typically process 32-bit or 64-bit inputs. The EVM differs—it’s a 256-bit machine, deliberately designed this way to handle Ethereum’s hash functions, which produce 256-bit outputs.
However, real-world machines executing EVM programs must break down 256-bit words into their native architecture, making the system highly inefficient and impractical.
Moreover, if you attempt to implement a complex algorithm like SHA256 using EVM’s basic OPCODES on Ethereum, good luck! To address the high gas costs of running complex programs via instruction sets, Ethereum introduced precompiles—special contracts compiled into the EVM that consume fixed gas. A notable example is the Ethereum hashing function, as implementing it directly in the VM would incur prohibitively high fees during contract calls.
Bloated Precompiles
The issue with precompiles is they continually increase the VM’s bloat and complexity without solving the core problem: the inefficient and crude design of the current instruction set and specifications.
What if we could define a new specification and instruction set that doesn’t rely on precompiles for complex programs, but instead efficiently implements them using basic instructions? This is where WASM comes in.
2.4 Comparison Between EVM and WASM VM
-
Speed: WASM aims to deliver faster execution than EVM. EVM may face efficiency issues when compiling and executing smart contracts, whereas WASM improves load speed and processing power by directly converting to compiled code.
-
Precompiles: EVM relies on precompiled contracts for efficient cryptographic computations, but this introduces risks of hard forks. WASM eliminates the need for precompiled contracts, allowing developers to create efficient, fast smart contracts.
-
Transaction Fees: Faster WASM virtual machines significantly boost transaction throughput, thereby greatly reducing contract deployment and transaction costs. WASM contracts effectively address Ethereum’s high fees and congestion issues.
-
Flexibility and Interoperability: WASM expands the range of languages available to smart contract developers, supporting any high-level language that compiles to WASM (such as Rust, C++, JavaScript). This means you can write smart contracts in any familiar language, including mature frameworks like Rust-based ink! or AssemblyScript-based Ask!.
The eWASM team is integrating WebAssembly into Ethereum to make its execution layer more efficient and simpler, positioning it as a fully decentralized computing platform. WASM has already been adopted as a standard by numerous other projects, including Dfinity and EOS, to strengthen their execution layers.
2.5 Stylus (Arbitrum)
The Stylus project enhances smart contract execution performance on Arbitrum, an Ethereum Layer-2 network, by introducing a WebAssembly (WASM) virtual machine. Contracts execute faster than Solidity, reducing gas costs. This makes building high-performance smart contracts on Arbitrum easier, currently supporting compilation from C, C++, and Rust.

Custom Precompile Support: Stylus also supports custom precompiles, allowing developers to deploy their own Rust or C++ precompiled modules onto the Arbitrum network. This enables introducing new cryptographic algorithms or specific functionalities on-chain without waiting for protocol upgrades. For instance, tensor computation precompiles could lower inference costs, benefiting on-chain machine learning.
Interoperability with EVM: Stylus integrates with the existing Ethereum ecosystem by achieving interoperability with the Ethereum Virtual Machine (EVM). This means Stylus contracts can interact with existing EVM contracts and share the same global state.
Reentrancy: Unlike Cosmos WASM, Stylus’ Rust SDK introduces reentrancy, allowing developers to manually enable it. This increases contract flexibility for interaction but requires careful state management to ensure security.
Given Arbitrum’s thriving ecosystem, Stylus represents one of the most meaningful WASM integrations to date and strengthens Arbitrum’s competitiveness in zkRollups.
2.6 Gear (Polkadot)
The Gear Protocol is developing technology deployable as a Polkadot parachain, serving as a tool for hosting smart contracts. Like Polkadot, Gear uses the Substrate framework, simplifying the creation of application-specific blockchains. Substrate offers extensive out-of-the-box functionality, enabling teams to focus on building custom engines atop the protocol.

Previously, launching a blockchain was costly, but Gear allows dApp developers to focus on their projects rather than building and operating an entire blockchain from scratch.
The core engine of the Gear Protocol is its smart contract module. In Gear, any smart contract is a WebAssembly program compiled from various languages such as Rust, C, and C++. For developers outside the crypto world, the entry barrier is low since they can build smart contracts in familiar environments. This makes experimenting with smart contract programming languages much easier.
Gear’s smart contract architecture uses the actor model under the hood and provides the following features:
-
Persistent memory for immutable programs
-
Asynchronous message processing
-
Minimal, intuitive, and sufficient API surface tailored for blockchain context
-
An actor communication proxy model between on-chain components enables greater composability and better compatibility with parallel code execution and sharding.
Each program has a fixed amount of memory, which Gear allows developers to control. Programs can only read and write within their own memory space, unable to access others'. Each program has independent memory, enabling parallel processing of information across Gear nodes.
2.7 CosmWasm (Cosmos)
CosmWasm is a modern, powerful Wasm-based smart contract platform that seamlessly integrates with the Cosmos-SDK. One of its key strengths is that CosmWasm contracts are natively integrated with IBC (Inter-Blockchain Communication), enabling developers and users to embrace a multi-chain future. Currently, only Rust is supported.

Advantages of CosmWasm
-
Security: Uses the Rust language to enhance smart contract security.
-
Cross-chain Compatibility: Supports IBC (Inter-Blockchain Communication) protocol within the Cosmos ecosystem.
-
Performance: In certain cases, CosmWasm demonstrates higher efficiency and lower transaction fees compared to traditional EVMs.
-
Developer-Friendly: Rust’s type safety and memory safety features reduce certain types of errors in smart contracts.
Challenges and Limitations
-
Learning Curve: Compared to more common smart contract languages like Solidity, Rust may present a steeper learning curve for beginners. CosmWASM needs broader language support to achieve mass adoption.
-
Ecosystem and Tooling Support: Although growing, CosmWasm’s development tools and ecosystem remain relatively limited compared to mature platforms like Ethereum.
-
Market Share and Awareness: Among smart contract platforms, CosmWasm may be less known than Ethereum or Binance Smart Chain, affecting its ability to attract developers and users.
-
Maintenance and Upgrade Challenges: Although CosmWasm supports contract upgrades, managing maintenance and upgrades remains complex and requires careful handling to avoid security vulnerabilities.
-
Compatibility Issues: Projects accustomed to EVM or other smart contract environments may face compatibility challenges when migrating to CosmWasm.
2.8 ZK-WASM
Beyond WASM virtual machines, a recent emerging technology is ZK-WASM. Delphinus Labs, its creator, has open-sourced ZK-WASM code on GitHub. ZK-WASM enables developers to verify the correctness of executed computations without re-execution. By leveraging ZK-WASM, developers can flexibly use various programming languages to build ZKP applications that seamlessly run in web browsers.

The concept of ZK-WASM stems from ZK-SNARKs, a hybrid of SNARGs and zero-knowledge proofs. Typically, using ZK-SNARKs requires writing programs in arithmetic circuit languages or circuit-friendly frameworks like Pinocchio, TinyRAM, Buffet/Pequin, Geppetto, xJsnark, ZoKrates, etc. This creates a barrier for existing programs trying to leverage ZK-SNARKs. Alternatively, instead of applying ZK-SNARKs at the source code level, they can be applied at the virtual machine bytecode level by building a ZK-SNARK-compatible VM. Delphinus Labs took the latter approach, embedding the entire WASM virtual machine into a ZK-SNARK circuit. This allows existing WASM applications to run directly on ZK-WASM without modifications. Thus, cloud providers can prove to any user that computations were honestly performed without revealing private information.

ZK-WASM enables diverse use cases, such as posting ZK proofs of browser-side operations to the blockchain, making web interactions with blockchains verifiable. Other examples include oracles, off-chain computing, automation, bridging Web2 and Web3, generating proofs for machine learning and data processing, and applications in gaming and social platforms. As adoption grows, zkWASM will expand Web3 possibilities and bring Web2 developers into this transformative landscape.
Through Delphinus Lab’s ZK-WASM implementation, developers can harness zero-knowledge proofs to enhance application security and privacy, paving the way for a more trustworthy and decentralized digital future.
3. Conclusion
The future of web performance and smart contract execution layers looks bright. Not only will dApps gain higher performance, but integrating WASM will also make smart contract development accessible to those familiar with robust mainstream languages like Rust and Go, rather than requiring them to learn intricacies of Solidity or other blockchain-specific languages to build useful applications on Ethereum. According to Evans Data Corporation, there are nearly 27 million developers worldwide. This number is steadily rising—growing about 3% last year—and is projected to exceed 28.7 million by 2024. In contrast, blockchain developers number fewer than 30,000, roughly one-thousandth of the total developer population. While this figure continues to grow steadily, learning new smart contract languages remains a barrier for developers entering blockchain.

But an increasing number of blockchains now support WebAssembly as compiled bytecode for smart contracts. WASM brings more than just efficiency, interoperability, and broad application scenarios to blockchain—it’s a key that liberates developers, lowering the entry barrier to blockchain development. Imagine a near future where Web2 developers wanting to explore blockchain can use their familiar Python, C++, or JavaScript to build large-scale applications on blockchain, maximizing the value of decentralized networks. Lowering barriers for creators (developers) first, then for users, paves the way toward mass adoption.
Join TechFlow official community to stay tuned
Telegram:https://t.me/TechFlowDaily
X (Twitter):https://x.com/TechFlowPost
X (Twitter) EN:https://x.com/BlockFlow_News














