a version of this blog is originally published here.

co-authored by: @0xDinoEggs

The Inception of Wasm

Evolution of web content

The web has come a long way in history.

From simple static pages to dynamic and interactive websites, there was always a need for more sophisticated content to be available and rendered on different operating systems and devices.

This, of course, meant interacting with and accessing various elements within the HTML document, and hence JavaScript was introduced. Although initially created for an accessible entry point in building dynamic websites, it faced various challenges such as:

1. Slower Performance: JavaScript's interpretation overhead slowed down web applications.

2. Limited Optimization: Despite efforts like JIT compilation, optimization remained a challenge.

3. Handling Complexity: Complex applications struggled to meet high-demanding scenarios consistently.

This gap gave rise to the need for a technology that could bridge the performance divide. This tech came in the form of WebAssembly, short for Wasm, an open standard developed by the W3C community and supported by all major browsers.

Wasm is a low-level portable binary format that provides a compilation target for high-level languages such as C, C++, and Rust. It eliminates the need for JavaScript to be the sole language of the web, enabling developers to write performance-critical code in other languages and compile them into Wasm modules that can be executed in the browser. This opened up new possibilities for web applications that require high performance, such as 3D graphics, video editing, and gaming.

Wasm’s Impact on Web2

Wasm stands as the cornerstone of a profound evolution within Web2, breaking free from its origins as a browser-based technology to now powering world’s most complex distributed applications.

A plethora of innovative use cases has emerged, demonstrating the profound impact of Wasm on web experiences in distinct categories:

E-commerce and Backend Optimization:

1. Shopify: Uses Wasm to optimize backend operations for speed and efficiency.

Design and Collaboration Tools:

1. Figma: Transitioned from asm.js to WebAssembly resulting in a threefold performance surge.

2. AutoCAD's Migration: Similar to Figma, AutoCAD adopted Wasm to navigate the additional challenge of intricate Windows OS dependencies.

Multimedia and Entertainment:

1. Netflix: Employs Wasm to create immersive video interactions, enhancing user engagement and entertainment.

Software Development and Tools:

1. Adobe: Invests heavily in WebAssembly, expanding the possibilities of software development in a browser environment.

2. Microsoft: Integrates Wasm into Azure Functions, Visual Studio Code, and Edge, shaping modern development tools.

Gaming and Interactive Experiences:

1. Unity: Uses Wasm to craft high-performance games that transcend platforms.

2. Pinterest: Taps into Wasm to curate dynamic, captivating user experiences.

Infra and Financial Tech:

1. Cloudflare: Employs Wasm to supercharge network performance, optimizing content delivery.

2. Visa: Uses Wasm to secure payment processing and protect sensitive user data.

In concert, WebAssembly has touched various sectors, infusing innovation across the board. Whether in e-commerce, entertainment, software development, gaming, networking, or critical systems, Wasm's impact has been transformative, opening up horizons for the web 2 experience.

Wasm in Web3

Fast forward to web3, where Wasm has also been very desirable. It has been adopted as the execution environment for many of the top blockchain projects (including Parity, Cosmos and NEAR) over the past five years.

The “why” for Wasm’s popularity in web3 is not much different than in web2. It offers efficiency, standardization, security, determinism, and of course, flexibility with programming languages.

“Our vision is that developers may program from the Internet Computer in any language they would like.”

- Andreas Rossberg, Technical Lead at Dfinity and Co-creator of Wasm

Supporting general-purpose languages not only creates a better experience for web3-native developers, but also enables millions of new developers to build on-chain. Each of the above projects recognized the power of Wasm execution, but let's address the elephant in the room, shall we?

Wasm Challenges in Web3

Despite its potential, onchain development hasn't gained the traction it deserves. It's puzzling why millions of developers aren't already building on the blockchain. And even in the still-niche web3 world, it's surprising that Wasm isn't the most widely used execution environment.

No one has articulated the crux of the problem better than Sreeram Kannan. Historically, to innovate on execution environments (as well as any other core infrastructure), you had to spin up a decentralized trust network. You had to get a set of validators and you had to get a bunch of capital committed.

This is VERY hard to do in a sustainable way. Bootstrapping a truly decentralized and permissionless trust network (that isn’t subsidized by VCs or easy money seekers) is akin to starting a revolution, a very different skillset than engineering distributed systems.

“Creating a decentrallized trust network is like finding a unicorn. Decentralized trust is not a common property. It is emergent out of social consensus which takes years to build”. — Sreeram Kannan

The reality is that very few blockchain projects - even projects with impressive technical innovations - have been able to bootstrap sustainable trust networks. One could argue that only two blockchains have done this so far: Bitcoin and Ethereum. This has made it hard for new execution environments like Wasm to reach escape velocity.

What happened to Ethereum’s eWasm plan?

A natural question to ask is “if Wasm execution is so desirable, why haven’t Bitcoin and Ethereum adopted it?”

For Bitcoin, the answer is simple. Bitcoin’s trust network makes a few key promises, one of them being “no hard forks”. This immediately rules out replacing Bitcoin’s limited scripting environment with a more programmable Wasm environment.

For Ethereum, we’ll need to walk down memory lane, but TLDR is: Ethereum Foundation planned to adopt Wasm and then pivoted.

Ethereum flavored Wasm (Ewasm) was originally proposed in 2015 and considered for a number of years. To be clear, Ewasm was “a restricted subset of Wasm to be used for contracts in Ethereum.” Goals of the Ewasm project included an EVM transcompiler, a VM implementation, a metering injector and more. To get a better sense for the thinking behind Ewasm, check out the following resources:

• Rationale and benefits

• Comparisons with other VMs

• Progression over 3.5 years

So wen Ewasm?

The Ethereum Foundation eventually retired the Ewasm project and stayed with EVM execution. While there were certainly challenges around backwards compatibility and execution sharding, the decision was part of a much broader strategic pivot.

The pivot was explored by Vitalik Buterin and Casey Detrio, then later formalized as “a rollup-centric Ethereum roadmap”.

Why pivot?

The Ethereum community didn’t phrase it this way at the time, but they had recognized the power of modular blockchain architecture and how it enabled permissionless innovation at higher layers of the stack. They knew this was a better approach.

What’s up, then?

This brings us to present day. The rollup-centric roadmap is in full swing as Ethereum optimizes for credible neutrality, verifiability, security and data throughput while 1000 (rollup) flowers bloom.

Rather than one execution sharding experiment, anyone in the world can customize a rollup, however they want for any use case they want. Some rollups will be L2s and others will be L3s. Some rollups will use fraud proofs and others will use ZK proofs. Some will succeed and some will fail. But they’ll all be permissionless to try.