56
An EVM program is a series of these opcodes and arguments. When these programs are combined into a single block of code, the result is known as "bytecode," typically represented as a long hexadecimal string. By putting a large number of these opcodes together in a specific order, any program can be created.
Rules within the EVM include:
- Every operation incurs a cost in order to prevent abuse/spam
- Every operation must be deterministic, as all nodes must agree on the state after transaction execution
- Transactions must be isolated with no access to I/O or external state.
Any entity participating in the Ethereum network must run the EVM to compute state transitions. If all nodes run the same EVM (same rules), all nodes are aware of global state changes.
The EVM keeps state using a data structure known as a "Merkle Patricia tree." Merkle Trees are generated through multiple rounds of hashing. The initial data begins at the bottom (of the image) and is combined with the other data and hashed together to create the parent hash on the rung above. These hashes are pooled (of the same size) and hashed again until a single (root) node remains. A Merkle tree's aim is to enable Merkle proofs, which prove a piece of data exists in the underlying dataset without requiring the broadcasting of the complete dataset.
Merkle trees can store all key-value pairs for all Ethereum addresses. The keys relate to both public and smart contract addresses, and their respective values describe their current state.
EVM and Solidity Have Become the Smart Contract Standard
Ethereum is a decentralized blockchain platform for building and running autonomous, Turing-complete smart contracts over a global network of permissionless nodes. The most popular implementation of the protocol (Geth) is written in , and the most widely-used smart contract language on the platform is
Solidity is designed to compile down to Ethereum Virtual Machine (EVM) bytecode, and it is currently the primary choice when coding smart contracts. Solidity has its problems, though, and other languages like for coding more secure and auditable smart contracts are on the rise. Despite this, Solidity’s syntactic similarity to JavaScript – one of the most popular programming languages in the world – affords it the unique advantage of having a less prohibitive learning curve compared to other languages.
Having Solidity become the de facto "standard" language for writing smart contracts (image below) enables more composability for dApps on Ethereum. Because smart contracts are deployed as open-source code in Solidity on Ethereum, anyone can build on top of these smart contracts by forking the code, incorporating their Solidity code, and creating an entirely new dApp.
In addition to Solidity becoming ubiquitous across the industry, there are several other key specifications that originated on Ethereum and have become widely accepted as global standards. These include:
- ERC20/ERC721, Ethereum token standards
- Ethereum's JSON-RPC Client API, a specification for communicating with Ethereum nodes
- Ethers.js, a web library for working with Ethereum
- Ethereum cryptography, such as the Keccak256 hash function and ECDSA signatures over Secp256k1
While it's possible to have an EVM-compatible chain without supporting all of these standards, conforming to them makes development and the user experience much easier. This is because with standardization comes composability, meaning devs can leverage one or more of the following:
- Ethereum's Social Graph: addresses are the same across EVM chains, meaning that any new project or chain can leverage the metadata associated with a user/address to solve cold-start problems
- Tooling and infrastructure: Some tools include Gnosis Safe, WalletConnect, Zerion, Metamask, and Etherscan. There are many open-source toolkits like OpenZeppelin, Hardhat, and Foundry
- Interoperability Cross-chain governance, ERC-20 token trading identical address system, etc.
- 8 of the top 20 blockchain ecosystems are running EVM.
