Inception of Wasm

The web has come a long way since 1989. What began with simple, static pages has blossomed into a world of full-blown applications supporting billions of users.

Because web “apps” required dynamic interaction with elements in the HTML document, JavaScript was introduced. It gained widespread popularity and was for a while the only programming language used in the browser.

JavaScript as a standard was useful yet limiting. What if some developers didn’t know JavaScript? What if JavaScript wasn’t the best language for certain use cases?

Enter WebAssembly: a low-level, portable, binary format and compilation target for high-level programming languages. It’s efficient, secure and flexible.

The introduction of WebAssembly (Wasm) meant that JavaScript no longer needed to be the sole language of the web. Developers could write performant code in languages such as Rust, Go, C, C++, etc. and compile them into Wasm modules to be executed in the browser. This opened up new possibilities for high performance web applications like 3D graphics, video editing, gaming and more.

Wasm Popularity in Web2

Wasm’s story didn’t end in the browser. Over time it broke free from its origins and started powering the world’s most complex distributed applications.

Here are just some of the many ways in which Wasm has been used:

Ecommerce 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 across platforms.

2. Pinterest: Uses Wasm to curate dynamic user experiences.

Infra and Financial Tech:

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

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

Wasm has enabled innovation across many sectors. Between ecommerce, entertainment, software development, gaming, networking, and critical systems, Wasm's impact has been nothing short of transformative.

Wasm Popularity 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 over the past five years. Here are a few noteworthy examples:

• Cosmos for its L1 SDK

• NEAR for its sharded L1

• Polkadot for its L1 SDK

The “why” for Wasm popularity in web3 is not much different than in web2. Efficiency, standardization, security and of course flexibility with programming languages. Here’s the vision for the Internet Computer as stated by Dfinity technical lead (at the time) Andreas Rossberg - who is also the co-creator of Wasm.

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

Support for general-purpose languages not only creates a more intuitive experience for web3-native developers, but it can also enable millions of new developers to build onchain. Each of the above projects (plus several others like Tezos, EOS, etc.) knew Wasm execution was a powerful idea.

Wasm Challenges in Web3

So what happened? Why aren’t millions of developers building onchain? Why have we not reached mass adoption? Wait a minute - forget mass adoption - why isn’t Wasm even the most popular execution environment in our still-very-niche web3 world?

No one has articulated the crux of the problem better than EigenLayer’s 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.

Ethereum’s Wasm Experiment

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.

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 decided against Ewasm 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”.

A Permissionless Future

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.

This brings us to the present day. The rollup-centric roadmap is in full swing as Ethereum optimizes for credible neutrality, verifiability, security and data throughput while 1000s of (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 EVM and others will be Wasm. 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.

Where does Fluent fit in?

At Fluent, our mission is to bring Wasm execution on Ethereum to life.

We believe Wasm teams were onto something and we deeply align with Ethereum values. We think that ZK technology unlocks a new way to solve the problem and that 10x better developer experiences are needed to unlock access to secure blockspace.

If this resonates with you, come build with us!