Blockchain technology has prompted a massive shift from traditional financial architecture and has evolved from an electronic cash system to an all-encompassing technological breakthrough with diverse use cases. Decentralized applications (dApps), built primarily on Ethereum, showcase the true potential of decentralization. Blockchain technology is, however, still far from mainstream adoption. Ethereum as a network is congested, transaction speeds are low, and costs are high. These issues have become barriers to scalability and have led to the birth of other blockchains.
Cross-chain integration and interoperability are imperative to overcome these barriers. A value transfer system needs to be created that allows both the users and developers to leverage the solutions offered by these new chains.
Different blockchains are written in different languages. Ethereum is written in Solidity. For a dApp to have multi-chain variants, the code needs to be re-written in all different languages, which is extremely cumbersome.
The Ethereum Virtual Machine (EVM) makes it easier to transfer value between Ethereum and other blockchains without the need for new infrastructure. This connects the different silos of the blockchain with similar ecosystem components and toolkits requiring little-to-no change. There is no need for developers to use different technology stacks to reimplement existing Solidity backend contracts and dApp front ends.
This paper delves into the existing solutions that help to bridge these different blockchains by simply copying the code from Ethereum to other blockchains with minimal changes thus reducing transaction costs.
The Ethereum Virtual Machine (EVM)
Ethereum has become the functional layer of the blockchain and the smart contract world. A smart contract is just like any other real-world contract, except it’s digital. In programming lingo, a smart contract is a computer program consisting of self-executing pieces of code that execute when preset conditions are met. Smart contracts are written in programming languages like Solidity, Viper, Bamboo, and others. A processor does not understand programming languages and hence cannot execute smart contracts. That brings us to the Ethereum Virtual Machine (EVM). The EVM is the heart of the Ethereum blockchain.
The EVM serves as a computational engine, just like a CPU, and acts as a middle layer between the smart contract and the operating system. Contracts written in programming languages are compiled to low-level machine instructions called opcodes or operational codes. The EVM uses these codes to execute specific tasks. It thus provides the run time environment for smart contracts on Ethereum.
Any distributed network needs to have consensus, whereby every node on the network has the same information about the state of the network. For Ethereum, the EVM enables consensus, allowing anyone to execute code in a trustless ecosystem. The outcome of execution (smart contracts) can be guaranteed and is fully deterministic. It creates a level of abstraction between the executing code and the executing machine.
Ethereum’s state is a large data structure that holds all accounts and balances. It is also a machine state, which can change from block to block according to a predefined set of rules. At any given block, there can only be a single state of the blockchain. Ethereum maintains its state with the help of EVM, which does this by defining the rules for computing a new valid state.
In short, EVM exists as one single entity maintained by thousands of connected computers running an Ethereum client. It is operating system-agnostic, and without it, each operating system would need a separate compiler.
How the EVM Works
At a basic level, the EVM can be considered a translator from the smart contract language to the Ethereum nodes. It enables developers to build and deploy dApps (without the need for an extensive coding background). It makes the process of creating blockchain applications much easier and more efficient while eliminating the need for powerful hardware. The EVM has no downtime and keeps all created objects safe from being modified.
There are two types of accounts in Ethereum — external accounts and contracts. Every account is identified by an address, consisting of a balance, a nonce, bytecode, and stored data (storage). The code and storage of external accounts are empty, while contract accounts store their bytecode and the Merkle-root hash of the entire state tree. External accounts have a corresponding private key while contract accounts don’t. The actions of contract accounts are controlled by the code they host, in addition to the regular cryptographic signing of every Ethereum transaction. The creation of a contract is simply a transaction in which the receiver address is empty and its data field contains the compiled bytecode of the contract to be created.
The first thing that happens when a new contract is deployed to the Ethereum blockchain is account creation. The data sent with the transaction is executed as bytecode. This initializes the state variables in storage and determines the body of the contract being created. The process is executed only once during the lifecycle of a contract. Once a contract account has been created, there is no way to change its code. The EVM treats both accounts the same. A transaction sent from one account to the other can contain Ether or binary data (payload). If it contains code, it is executed and the payload becomes input data. If it is not set, the code sent is executed and returns the code for a new contract. During the construction, the code of the contract is empty.
Being decentralized, contracts are executed on all Ethereum nodes. This raises the risk of bad actors slowing down the network intentionally by creating a lot of complex contracts. To protect against such attacks, every opcode has a base gas cost. For any smart contract to be executed by the EVM, each and every line of code in Solidity requires a certain amount of gas to be executed. The gas is used as per the execution cost assigned to the instruction implemented by the EVM.
By using the Gas mechanism, two major issues are solved. A validator is guaranteed to receive the initial prepaid amount, even if the execution fails. An execution cannot run longer than the prepaid amount would allow. Instead of looping indefinitely, the execution would run until it runs out of Gas.
When a transaction is sent to the network, validators may take the transaction, executing the associated code. The validator will ensure:
– Validity of all information on the transaction.
– Enough funds are available to pay for the execution of the transaction.
– The EVM doesn’t run into any exceptions during the execution.
The EVM achieves Turing Completeness by enabling an economy that charges as per the execution of software instruction instead of financial transactions.
This is a two-part piece written on EVM and the existing EVM options. The first part covers EVM and working at a high level. The second part gives an insight into the existing options on different blockchains. \n The subsequent part will cover EVMs on different blockchains. \n (Continued in Part II)
EverythingBlockchain — In pursuit of simplifying the different blocks of the chain metaverse.
Donation address — 0xe9f581e005cbB94752A96198052088F206ac73b1 \n
Substack, Odysee, Twitter, Youtube, Publish0x, Presearch, Medium, Reddit, Loop
Any or all of the information provided through this work is intended solely for educational purposes and must not be treated as investment advice. Any lapses in presenting any of the information correctly are ours alone. We disclaim any liability associated with the use of this content.