A Deep Dive into the Ethereum Virtual Machine: Part II
This is the second part of the paper that gives an insight into the existing EVM options. To understand how the EVM works at a higher level, read the first part of the article.
Dapps depend on the speed of the underlying blockchain. This issue grew more prominent in late 2017, when enormous transactions on Cryptokitties congested the network and made the dApp virtually unusable. If the blockchain is to find mainstream adoption, the transaction speeds have to be faster and the transaction costs lesser. Ethereum’s existing infrastructure cannot offer high transaction speeds, and that has led to high transaction costs in the form of gas fees. The singular consensus offered by Ethereum Virtual Machines across the entire network makes computation slower and more expensive than it would be on traditional computers. Ethereum can process one block at a time, which takes around 13 seconds. That implies 30 transactions per second. Visa, by comparison, can process 15000 transactions per second.
Let us delve into the existing EVMs on other blockchains aimed at cross-chain integration and interoperability by offering EVM compatibility.
Binance Smart Chain (BSC)
BSC is an independent blockchain developed by Binance (built with Cosmos’ SDK) that runs in parallel with Binance Chain. It is based on a code fork of Ethereum using a Delegated Proof-of-Stake (DPoS) consensus mechanism with 21 validators and a 3-second block time. BNB is the native asset of the network. BSC does not offer block subsidies or minting of fresh BNB as block rewards. Instead, validators receive transaction fees as rewards for securing the network. The dual-chain architecture helps developers build decentralized apps and digital assets on one blockchain (BSC) and take advantage of the fast trading to exchange on the other (Binance).
BSC powers smart contract functionality and boasts compatibility with the Ethereum Virtual Machine, allowing for Ethereum dApps to port to BSC. It helps to achieve cross-chain integration while providing faster and cheaper transactions. Most of the dApps, ecosystem components, and toolkits work with BSC and require minimal changes. BSC nodes require similar or higher hardware specifications and skills to run and operate.
Aurora EVM is an application (smart contract) operating on the NEAR Protocol. It was created by the stellar team at the NEAR Protocol. It helps developers to replicate and scale dApps from Ethereum to NEAR.
NEAR is a blockchain that is fast (2-3 second transaction finalization) and scalable with low transaction costs.
Aurora EVM has two main components:
- Aurora Engine: Enables smart contracts in Solidity and Vyper programming languages.
- Aurora Bridge: A bridge application built on Rainbow Bridge, allowing tokens on Ethereum to be transferred to NEAR for pooling, trading, and use.
Aurora EVM is entirely compatible with Ethereum, so neither developers nor users need to use any additional tools or tokens to work with Aurora. With the Aurora bridge, account balances in Aurora’s EVM are denominated in the same Ether (ETH) as on Ethereum itself.
Moonbeam is an Ethereum-compatible smart contract platform on the Polkadot network that aims to provide compatibility with the existing Ethereum developer toolchain and network. It provides a full EVM implementation, a Web3-compatible API, and other bridges that connect Moonbeam to existing Ethereum networks. The Ethereum compatibility allows developers to deploy existing Solidity smart contracts and dApp user interfaces for Moonbeam with minimal changes.
Moonbeam is also a parachain on the Polkadot network which means shared security from the Polkadot relay chain. It is also able to integrate with other chains that are connected to Polkadot. Moonbeam’s scalability and security are derived from running under Polkadot’s sharded design and shared security umbrella.
The primary development framework for building applications on Polkadot is the Rust-based Substrate framework. By providing Ethereum compatibility, Substrate allows for the leveraging of the relatively mature ecosystem of tools that exist in the Ethereum ecosystem, such as Truffle and MetaMask.
Solana is a high-performance blockchain that uses a proof of stake consensus mechanism. It has a low barrier to entry with timestamped transactions to maximize efficiency using its innovative Proof of History (PoH) consensus. PoH makes it possible for Solana validators to add as many transactions as they can into a block. These transactions can later be easily sorted out and verified by other validator nodes using timestamps. It allows computation of as many transactions simultaneously giving a high throughput, with minimal finalization and block time. However, the only caveat for Solana is the language that it is written in (Rust) with fewer developers.
To bring Ethereum dApps onto the Solana ecosystem, NeonLabs has built an EVM. It aims to bridge the two blockchains enabling cross-chain integration. Neon EVM grants any decentralized application built and operating on the Ethereum ecosystem access to Solana’s high throughput capacity, scalability, and lower gas fee.
Neon EVM is an Ethereum Virtual Machine on the Solana blockchain. It is written in Rust and compiled to Berkeley Packet Filter (BPF) bytecode. This allows taking full advantage of Solana functionality, including parallel execution of transactions. It creates a compatibility layer permitting anyone to run Ethereum contracts directly by copying them onto the Solana blockchain. There is no need to rewrite clients or the contracts for existing dApps. It also makes it easy to update Neon EVM regardless of Solana’s hard forks. Neon EVM can add new functionalities at any time using updates. Code updates can take place by uploading them as a new smart contract, something which is not possible with Ethereum.
To use Solana in full for the Ethereum transactions, the first component is placing Solana’s Berkeley Packet Filter contract inside the Neon EVM that works on Solana. The other component which is Neon Web3 Proxy provides a Web3 API for external web clients to access the Solana blockchain. It is an intermediary for communication between Neon EVM clients and Neon EVM and it can be run by Neon EVM operators. Neon Web3 Proxy is optional for any Neon EVM client. Its main functionality is to help Neon EVM clients use Neon EVM (without any changes to their codebase).
With Neon EVM, developers can build with the same Ethereum toolkits in Solidity as they would on Ethereum. Currently, EVM is running on the Solana testnet.
Vitalik said, “Future will be multi-chain” and “not cross-chain”. What do you think? Drop your comments below.
EverythingBlockchain—In pursuit of simplifying the different blocks of the chain metaverse.
Fixed-Rate Lending/Borrowing on Notional.Finance
Disclaimer: This is a contribution post made for Globalcoinresearch.com and Layer3.