WASM: The Future of Web3
--
WebAssembly, called WASM for short, is a relatively new sort of portable binary-code format that can run efficiently on modern browsers. The World Wide Web Consortium (W3C) released the code in 2017 with engineers from Google, Mozilla, and Apple participating.
WebAssembly’s original purpose was to enable high-performance apps on web pages. As WASM does not provide any Web-specific functionality, we can also apply it in other environments, such as blockchain and smart contract development.
WASM is frequently referred to as Ethereum Virtual Machine — EVM’s precursor — in the blockchain development environment. It can supply all the EVM’s features while also adding new ones.
How the Inefficiencies of EVMs Became the Starting Point for WASM
With the advent of EVM, the Ethereum virtual computer for executing/building smart contracts, the Ethereum Foundation took the development of dApps to the next level.
EVM is a stack-based state machine that translates EVM opcode into computational instructions that may be run on top of the blockchain. Dr. Gavin Wood, the co-founder of Ethereum and the founder Polkadot, created it.
Contract-oriented languages, such as Solidity or Vyper, can be used by developers to create applications that can be compiled down to EVM bytecode. The depth of EVM is 1024 items, and each item is a 256-bit word.
However, one serious issue with EVM remains — it is a hugely opinionated design. It derives from an already very opinionated design, which is the Bitcoin script design and there are various problems with this approach:
- Smart contract performance is limited to EVMs — 256-bit computation on 32/62-bit architecture, contract size limit on 24Kb (EIP-170)
- Solidity tooling is very primitive and still new compared to NPM or Cargo
- Complex logic cannot be implemented on EVM
- eWASM has a lot of overhead (IEE)
- Solidity and Vyper is a very unorthodox language to learn
- EVM dApps are stagnating due to lack of innovation
eWASM vs EVM
eWASM is one of several improvements that Ethereum made to facilitate the transition to Ethereum 2.0. Many people saw eWASM as a solution to the development of a fast, scalable, and flexible ecosystem, encouraging developers to design complicated smart contracts on top of Ethereum 2.0’s protocol. eWASM or Ethereum WebAssembly is Ethereum 2.0’s version of WebAssembly (WASM).
A wasm-based EVM can benefit from enhanced hardware features and a diverse ecosystem of tooling and language support. With such an EVM, smart contracts may theoretically be written in any language that compiles into WebAssembly.
When it comes to the eWASM team, they have stated the following as their unique design goals:
- As an eWASM contract, create an EVM transcompiler and a metering injector
- A detailed specification of the Ethereum interface, as well as the eWASM contract semantics and finer features
- Create a solc compiler eWASM backend
- Instruction and a library for developing smart contracts in C and Rust are provided
By integrating eWASM, Ethereum will join projects such as EOS, Tron, Cardano, and others that have either implemented or are considering adopting WASM.
It is vital to highlight that EVM-based transactions are not human-readable, which has a significant impact on the environment’s user experience.
EVM is not computationally or energetically sustainable. While it was built to be as efficient as possible, it still contains problems that make it inefficient in comparison to competitors such as Polkadot, NEAR, Solana, and Cosmos.
EVM has its own instruction set, memory space limitations, and stack depth constraints, which increases the likelihood of flaws and errors occurring. This makes writing secure smart contracts for EVM challenging. As we saw with the DAO hack in 2016, even minor errors in coding can be exploited by hackers motivated to exploit that weakness.
EVM has a stack size of 1024 and supports 256-bit words. The 1024 limit shows that the level of complexity for EVM smart contracts is designed to be limited.
As a result, EVM’s constraints make advanced use case design difficult for EVM developers.
The Future of Web3: WASM
WASM is a ubiquitous standard for doing native-level activities from within a browser context. Google, Microsoft, Mozilla, Apple, and others are leading the development.
You can run any hardware-intensive work, such as games, from the browser with near native-level performance thanks to the strength of WASM.
To make Web3 a reality, blockchain mass adoption is necessary, and WASM-based smart contracts are technically superior to EVM. WASM’s capacity to exceed EVM as a virtual machine for blockchains is clear: it is fast, efficient, and portable, with near-native speed:
- High performance: WASM allows good performance since it is designed to be as near to native machine code as feasible while remaining platform-independent.
- Small size: WASM generates binary files that are tiny in size. This is an excellent fit for the blockchain world because smaller binaries result in less transaction data and thus lower gas fees.
- General VM & bytecode: WASM was designed to be deployable in any browser and produce the same results. EVM, on the other hand, was created for a specific use case. As a result, more teams have been using WASM for various reasons and creating a wide range of tools and resources.
- Tooling and support: As previously stated, the community has been developing tools and resources for WASM that are available to developers.
- Efficient JIT execution: WASM natively supports 64 and 32-bit integer operations, allowing for efficient JIT execution. This is useful when executing 64-bit operations since it eliminates the need to decompose and simulate instructions. WASM, on the other hand, provides all numeric instructions with 64-bit capability that map one-to-one to CPU instructions.
- Minimalistic: The formal specifications of a use case can easily fit on a single page.
- Deterministic execution: WASM can easily be made deterministic by removing floating point operations, which is necessary for consensus algorithms.
- Supporting popular programming languages: WASM supports C, C++, C#, Assembly Script, RUST, avoiding developers to learn single-use case languages like Solidity.
A Future Perspective
The transition between EVM and WASM will happen gradually. While WASM receives substantial support and integration, unlike EVM, it is not designed to communicate with the blockchain. Currently, it is witnessing a low level of adoption by Web3 developers since EVM is the most commonly used virtual machine and lacks tools.
Currently, there are only a handful of blockchain networks natively supporting WASM and hence, a small number of WASM-based dApps. To work with and unlock the full potential of WASM native dApps, Web3 tools developed in WASM are required. As a result, infrastructure providers must reinstall their services in WASM in order to connect with WASM smart contracts.
Another aspect that underscores the need to open Web3 for Web2 developers, in addition to the scarcity of Web2 developers compared to Web3 developers, is the level of expertise that WebAssembly developers have with the tools.
Learning new programming languages is particularly difficult when you have been used to writing code in a specific structure for years.
Unlike Web3 blockchain developers, Web2 developers’ talents are directly related to innovation and user focus, and it is precisely this revolution that the crypto economy requires and that WASM adoption aspires to lead.
Be among the first to build on Wasm0
Join the waitlist → typeform.com/wasm0
