Summary
How feasible is it to add EVM support for Plasm Network?
Issue
Currently, Ethereum is the second biggest blockchain in the world, the biggest smart contract platform. Many people entering to the blockchain world are generally exposed via Ethereum and their smart contract capabilities. Because a lot of existing blockchain developers are using Ethereum, there have been many tools and services to support this task.
On the other hand, Substrate’s native contract pallet uses a language that is based on Rust, which is notorious for having a steep learning curve. Plus ink (substrate contract language) contracts currently do not have any sophisticated toolings to support dApp development or robust utilities that are easy to use and can safely migrate existing EVM-based applications to a WASM-based (substrate) blockchain. Solang is one solution, but it is not 100% compatible with what EVM offers.
If Plasm Network is to become one of the better scaling smart contract platforms, we must find a way to allow Ethereum based devs to migrate to Plasm net without any headaches.
Potential Solution
Implementing the EVM pallet provided by Parity Tech will allow any Substrate based blockchains to execute Solidity contracts. Furthermore, exposing the Ethereum RPC API will allow our chain to be used as a Web3js provider. This means that existing smart contract developers can import their existing code to Plasm Network, use the same tools such as Truffle, WalletConnect, Ethereum layer 2 implementations, and much more!
Limitations and Concerns
Not a huge issue, but due to the nature of Substrate and the hashing algorithm it uses, some of the existing web3js utility libraries might not be compatible.
Developers trying to communicate between WASM and EVM will have a hard time (especially trying to import WASM contracts to EVM, or vise versa).
WASM-based contracts have been proven to be much more scalable and functional than EVM*. This also means that the world will eventually move on to WASM-based solutions, while EVM is generally considered within the Polkadot ecosystem as being there for backward compatibility.
EVM can potentially overload the chain (just like Ethereum) if we poorly implement it without any adjustments (i.e. we need to streamline using layer 2 protocols for production).
Potentially skewing the developer base, or worst case, dividing the community (think of it like Python 2 when Python 3 was new) as ink becomes more mature.
So the question is,
How feasible is it for Plasm Network to add EVM support (beyond the EVM pallet).
How hard will it be to create a usable infrastructure (including SDKs) without undermining our existing ones?
What are the things we have to do to create a robust development enviornment?
How much resource (time, skills and man power) will we need?
What are the benefits/negatives for a blockchain that lives on a ecosystem that is always changing will have by implementing this?
Instead of Solang, would it be possible and even better to use AssemblyScript and WASM modules? AssemblyScript is far superior language, has WASM extensibility, and AssemblyScript, WASM and Rust just work out of the box when it comes to developer pipeline integration.
Parity has done work before PoC with AssemblyScript/WASM compile to OpenEthereum, how hard will it be to have that just compiled to Substrate directly?
There are advanced blockchains in the market which the developer experience is with AssemblyScript/WASM so is not a far fetched idea.
In its core, Substrate uses WASM as a way of future-proofing the blockchain (and Parity already have a bunch of things in Rust, so might as well). Due to the ubiquitous nature of WASM, smart contracts are not restricted by the language that they were written on, rather, they just have to comply with an interface. Rust (with ink!) is just a direct and dirty way to get things started and Solang is just one option to allow users to use this technology. I love the idea of having a contract language on AssemblyScript for substrate’s contract module (much easier for new devs to come in), however, I fear that may require a lot of community contribution and active support from Parity as well just to kick-start things when it comes to new language support, and substrate contracts standards are something that is quite new and growing (though in here, I’m mostly referring to the wide adoption of it rather than the tech).
I also think trying to implement modules from non-substrate blockchains that use WASM as a substrate pallet might be interesting too.
For example, Hyperledger Burrow uses EVM and WASM. This is done by leveraging ewasm, which I believe it is pretty similar to what the EVM pallet in substrate is as well.
No doubt that WASM is far superior and it is something that will grow in the coming years.
But then the question is, how can we provide a great development environment for Plasm Net and offer flawless migration for existing Ethereum dApps? In other words, can we still use the existing tools and tutorials online? The reality is, businesses don’t care about what technology it uses, it cares about how much it will costs to migrate from one chain to another. This also applies to small developers with existing dApps as well.
For me, the challenge right now is not about implementing EVM, but more about how can we create a client-side library that can use both Polkadot-js and Web3js (use both Substrate and Ethereum contract RPC with one library and without the devs trying to pull their hairs out or lose compatibility), and how to import one contract to another for compatibility (contract libraries will become something important later when the ecosystem becomes more developed).