I've implemented nearly a hundred smart contracts with Solidity during my short blockchain career, but I'm ready to drop Solidity right now if I think about WebAssembly on the blockchain.
Interested to learn more? Let's take a look at what WASM can do for blockchains!
🧵👇🏻
1/
Before we jump in:
If you don't exactly know what WebAssembly is, this thread might help you understand the basics first. 👇🏻
The blockchain world is currently divided. There are many languages one can use to develop smart contracts on different blockchains.
3/
The Ethereum Virtual Machine has its bytecode that is a target for Solidity, and Vyper, for example.
Neo and its VM support Python, JavaScript, C#, etc.
Tezos has Michelson that can be a compile target for Python, LIGO (OCaml, ReasonML), etc...
4/
This list could go on and on. What we can take away from this is:
Many languages are supported but often not a single one that all blockchains can agree upon.
Developers usually try to settle on a few languages, not many. This hinders adoption and portability.
5/
There is often no native way to get smart contracts from one chain to another.
Bridges between a few blockchains exist that enable exchanging data and contracts, but they are not universal.
What's left is to implement a contract again and deploy it to another chain.
6/
This is certainly not the most effective solution, but having the ability to do so, could help increase the portability of contracts and standardization of libraries.
Blockchains with different opinions are fine. It enriches the ecosystem.
7/
All of them doing their own thing could, however, well hurt themselves in the end.
If developers have to decide, they usually try to settle on what's best supported, has the largest community, and the greatest ecosystem.
8/
Relearning a different language, ecosystem, and more is costly, both in time and money.
This fragmentation hurts the whole space.
9/
2. What WebAssembly can change
WebAssembly is already a compile target the community could agree upon for web development and even server-side use cases.
The tooling is already being built, and the specification worked on consistently.
10/
WASM runtimes are sandboxed and make it difficult to escape.
Performance is also a key concept of them.
All this ticks many boxes necessary to make a great smart contract execution environment.
11/
What's even greater for the community and all developers is that WebAssembly is a compile target.
You can still use your favorite language, create your smart contract, and then compile it down to WebAssembly.
12/
WASM modules can even be used as libraries in any language.
You've written a library in Rust? Let others use it from Python or JavaScript (AssemblyScript).
This can result in a massive boost for the ecosystem.
13/
JavaScript became so huge because the ecosystem is so huge.
There is a library for nearly everything, and it involves only some languages (all that somehow compile down to JavaScript and are frequently used).
14/
Having the choice to contribute to an ecosystem in nearly all languages could have a similar effect, only at least a hundred times larger.
The potential of this already has enough fuel to lift more than one rocket off the ground.
15/
3. What is currently done for WebAssembly on the blockchain?
The blockchain space is still in its early stages regarding WebAssembly.
There are some early adopters and some specification efforts already going on, though.
16 /
Ethereum, in the process of moving toward 2.0, has begun work on a specification for an Ethereum Virtual Machine that executes WebAssembly.
There are also already some experimental implementations. 👇🏻