Ethereum can be sufficiently straightforward to comprehend from a high-level perspective: Decentralized applications driven by the same kind of crypto-economic assurances that support Bitcoin. However, once one zooms in to, for instance, a detailed view, complexities arise quickly.<\/p>\n
<\/p>\n
Even if one possesses a solid understanding of proof-of-work<\/a>, it may not be immediately obvious how that relates to a blockchain doing more than tracking everyone’s unspent transaction outputs. Bitcoin employs computational labor to decentralize currency<\/em>. Ethereum utilizes computational effort to decentralize abstract calculations<\/em>. Huh? That abstraction is referred to as the Ethereum Virtual Machine<\/em>, and it serves as the core of the Ethereum protocol because “within” the EVM lies the exclusive domain of smart contracts, which are ultimately responsible for all those ludicrous #defi tweets.<\/p>\n <\/p>\n Upgrading the EVM stands as one of the key milestones of the Stateless Ethereum Tech Tree<\/a>, and before we delve into the intriguing work there, I believe it’s wise to first address the obvious inquiry: “WTF is the EVM?”<\/em>. In the first part of this two-part series, we will revisit the basics and attempt to grasp the EVM from the ground up, so that later we can really engage with the current discussions about topics like Code Merklization and UNGAS\u2014even elements from the thrilling realm of Eth2 like Execution Environments!<\/p>\n <\/p>\n <\/p>\n When first-year Algebra scholars are introduced to that well-known function f(x)<\/em>, an analogy of “the function machine” is often employed. The notion of deterministic input\/output appears to be significantly more accessible for students to visualize as a tangible physical machine processing data. I appreciate this analogy as it works in both directions: The EVM, which in a sense actually is<\/em> a literal machine operating, can be conceptualized as a function<\/em> that receives some state as inputs and generates a new one based on a set of arbitrary rules.<\/p>\n <\/p>\n Setting aside the particulars of those rules for now, let\u2019s assume that the only acceptable state transitions are those stemming from valid transactions<\/em> (which adhere to the rules). The abstract machine that will determine a new state (S’<\/span>) based on an old valid state (S<\/span>) and a new collection of valid transactions (T<\/span>) is the Ethereum state transition function: <\/p>\n The first aspect that’s crucial to grasp about this function is that, as an abstraction, it’s somewhat of a mathematical placeholder: arguably not a tangible entity, and definitely not the<\/em> EVM. The Ethereum state transition function is elegantly inscribed in Greek in the yellow paper because envisioning the EVM as a black box function effectively aids in conceptualizing the entire blockchain system (of which the EVM is merely one segment). The bidirectional link between functions and machines is determinism<\/em>: Given any legitimate input, both should yield one and only one output.<\/p>\n <\/p>\n However, the EVM, as previously mentioned, is<\/em> in some respects a tangible machine operating in the world. The EVM’s physical manifestation cannot be articulated in the same manner one might refer to a cloud or an ocean wave, yet it does exist across thousands of interconnected computers running Ethereum clients. And at any given moment, there is one and only one canonical Ethereum state<\/strong>, which is what we are concerned with. All the other components within an Ethereum client exist solely to maintain consensus regarding which state is valid.<\/p>\n <\/p>\n The term ‘canonical’ is utilized because ‘valid’ isn’t entirely fitting; a state transition calculated correctly is ‘valid’, yet it may still not be incorporated “on-chain” as part of the canon. Determining which states are canonical and which states are not is solely the duty of miners executing proof-of-work on the chain. Everyone engaging with Ethereum mainnet has, either literally or symbolically, “invested in” one specific particular<\/em> state history, namely the one with the most computational effort invested in it, as determined by Ethereum’s Greedy Heaviest Observed Subtree (GHOST) protocol. With each new block added to the network comes a fresh set of transactions, a state transition, and a newly determined output state ready to be forwarded into the next canonical block, as dictated by miners. And this process continues indefinitely; that’s how the Ethereum blockchain operates.<\/p>\n <\/p>\n We\u2019ve thus far ‘black-boxed’ the EVM as the state transition function (machine) that accepts previous valid blocks and a selection of new transactions (as input), performs some calculations on it, and produces a new valid state (as output). The other components of the Ethereum protocol (such as miners selecting canonical blocks) provide necessary context, but it\u2019s now time for some deeper analysis. What about those specific rules we previously set aside? How<\/em> does the EVM compute a new state? How can a singular machine handle everything from simple balance transfers to elliptic curve algebra?<\/p>\n <\/p>\n <\/p>\n The best way I can introduce the concept of a stack machine is through this cartoon depiction of Babbage’s Analytical Engine (credit: Sydney Padua<\/a>), which was designed in 1837 but never constructed:<\/p>\n <\/p>\n \n <\/p>\n With the majority of individuals now carrying extraordinarily powerful electronic computers in their pockets, it\u2019s easy to forget that computers don’t necessarily have to be electronic or that powerful. Babbage’s Analytical Engine serves as a very (hypothetically) real example of a Turing-complete (!) computer that, if it were built, would have operated on steam and punch cards. The EVM is in significant ways much more closely related to the Analytical Engine of two centuries ago than to the CPU in the device you’re utilizing to read this article.<\/p>\n <\/p>\n The EVM is a stack machine<\/a>, and although in actuality, it’s a virtualized machine<\/em> operating withinnumerous Ethereum clients concurrently, I find it beneficial to envision the EVM as a tangible, albeit more sophisticated (yet still steam-driven) iteration of the Analytical Engine. This analogy might appear somewhat exaggerated, but I urge you to bear with it for a while as it becomes quite illustrative when we approach the topic of gas and a communal execution atmosphere.<\/p>\n <\/p>\n The steampunk EVM would serve as a mechanical computer that operates by manipulating tangible punch cards. Each card would possess 256 slots for hole punches, allowing each card to symbolize any integer from 0 to 2^256. To execute a computation, one might visualize this device, through an intricate system of compressed air, positioning the cards denoting numbers and functions into a stack<\/em>, adhering to a straightforward principle of “first in, last out”, it would sequentially PUSH new cards atop the stack or POP cards from the top for subsequent use. These might consist of new numbers for calculation, or arithmetic actions such as ADD or MULTIPLY, but they could equally be unique commands such as to STORE a card or set of cards for future use. Since the cards are merely binary, the operations must also be ‘encoded’ into a binary format; thus, we refer to them as operational codes, or simply opcodes for brevity.<\/p>\n <\/p>\n If the stack mechanism were calculating 4 * 5 + 12<\/span>, it would operate as follows:<\/p>\n <\/p>\n <\/p>\n \n<\/p>\n _POP value 4 from the stack, retain it in memory. POP the value 5 from the stack, hold it in memory. POP the value _ from the stack; transfer everything in memory to the multiplication module; PUSH the returned outcome (20) to the stack. POP the value 20 from the stack; remember it in memory. POP the value 12 from the stack; maintain it in memory. POP the value + from the stack; send everything in memory to the addition module; PUSH the returned outcome (32) onto the stack. (Source: The EVM Runtime Environment<\/a>)<\/p>\n <\/p><\/blockquote>\n <\/p>\n We can visualize opcodes like ADD or MULTIPLY as distinct modules incorporated into the device, positioned close to the stack for quick access. When the machine is required to multiply 4 and 5, it would relay both cards to the “multiplication engine,” which might click and hiss before delivering the number 20 punched into a new card to PUSH back to the stack’s apex.<\/p>\n <\/p>\n The “authentic” EVM contains numerous diverse opcodes<\/a> for executing various functions. A specific minimal viable collection of these opcodes is necessary to perform generalized computation<\/em>, and the EVM includes all of them (combined with some unique ones for cryptographic processes, such as the SHA-3 hash function<\/a>). For better or worse, the notion of whether the EVM is (or isn’t) Turing-complete<\/em><\/a> has been a topic of longstanding debate\u2014 it is this stack-based framework which possesses the trait of Turing-completeness: The EVM’s execution rules can, in principle, given ample time and sufficient memory, run any imaginable computer program<\/em> provided it’s compiled to the appropriate 256-bit words and executed in the stack.<\/p>\n <\/p>\n Compiling a program in our alternative realm would require forming a booklet of punch cards containing the relevant data and opcodes. This is literally (or, figuratively literally, whatever) the process occurring behind the scenes when you draft a smart contract in a high-level language like Solidity and convert it into bytecode. You can gain a clear understanding of how a programming language is transformed into machine code by reviewing this humorously annotated output of a Solidity compiler<\/a>.<\/p>\n <\/p>\n Up until now, the state<\/em> has not yet been addressed, but remember that we set out to comprehend the principles by which a state transition<\/em> can be computed. We can now articulate it a bit more clearly: The EVM embodies the physical instantiation (read: instance) of the state transition function. A valid state in Ethereum is one calculated by the EVM, and the canonical state is the valid state with the maximum computational effort expended on it (as determined by the GHOST protocol).<\/p>\n <\/p>\n <\/p>\nWTF is the EVM?<\/h2>\n
\nY(S, T)= S’<\/span><\/p>\nThe Steampunk Stack Machine<\/h2>\n
![\"\"](\"https:\/\/miro.medium.com\/max\/1300\/1*uyHYmN0Hs6hxncGG6Av4XQ.png\")
<\/p>\n(Ideal) Gas<\/h2>\n