How feasible is it to add EVM support for Plasm Network?
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.
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?
Let’s get this conversation going!