Ethereum can be simple enough to understand from a bird’s-eye view: Decentralized applications powered by the same sort of crypto-economic guarantees that underpin Bitcoin. But once you’ve zoomed in to, say, a street-level view, things get complicated rapidly.

Even assuming one has a strong grasp on proof-of-work, it’s not immediately clear how that translates to a blockchain doing more than keeping track of everyone’s unspent transaction outputs. Bitcoin uses computational work to decentralize money. Ethereum uses computational work to decentralize abstract computation. Wut? That abstraction is called the Ethereum Virtual Machine, and it’s the centerpiece of the Ethereum protocol, because “inside” the EVM is the special domain of smart contracts, and it’s the smart contracts that are ultimately to blame for all those ridiculous #defi tweets.

Upgrading the EVM is one of the major milestones of the Stateless Ethereum Tech Tree, and before we can dig in to the interesting work there, I think it’s prudent to first tackle the obvious question: “WTF is the EVM?”. In the first of this two-part series, we’ll get back to basics and try to understand the EVM from the ground up, so that later we can really engage with current discussion about things like Code Merklization and UNGAS— even stuff from the exciting world of Eth2 like Execution Environments!

WTF is the EVM?

When first year Algebra students get taught about that familiar function f(x), an analogy of “the function machine” is often used. The concept of deterministic input/output, it seems, is a lot easier for kids to think about as a literal physical machine chugging along. I like this analogy because it cuts both ways: The EVM, which in a way actually is a literal machine chugging along, can be thought about as a function which accepts as inputs some state and outputs a new one based on some arbitrary set of rules.

Setting aside the specifics of those rules for now, say that the only valid state transitions are the ones that come from valid transactions (that follow the rules). The abstract machine that will determine a new state (S’) given an old valid state (S) and a new set of valid transactions (T) is the Ethereum state transition function:
Y(S, T)= S’

The first thing that’s very important to understand about this function is that, as an abstraction, it’s sort of a mathematical placeholder: arguably not a real thing, and definitely not the EVM. The Ethereum state transition function is written all fancy in Greek in the yellow paper because thinking about the EVM as a black box function really helps with imagining the whole blockchain system (of which the EVM is just one part). The two-way connection between functions and machines is determinism: Given any valid input, both should produce one and only one output.

But the EVM, as I said before, is in some sense a literal machine chugging along out there in the world. The EVM’s physical instantiation can’t be described in the same way that one might point to a cloud or an ocean wave, but it does exist inside thousands of connected computers running Ethereum clients. And at any given time, there is one and only one canonical Ethereum state, and that’s what we care about. All of the other components inside an Ethereum client are there just to keep consensus over which state is the right one.

The term ‘canonical’ is used because ‘valid’ isn’t quite appropriate; a state transition computed correctly is ‘valid’, but it still might not end up “on chain” as part of the canon. Deciding which states are canonical and which states are not is the sole responsibility of miners doing proof-of-work on the chain. Anyone using Ethereum mainnet has, either literally or just figuratively, “bought in” to one particular state history, namely the one with the most computational work put behind it, as determined by Ethereum’s Greedy Heaviest Observed Subtree (GHOST) protocol. Along with each new block on the network comes a new set of transactions, a state transition, and a freshly determined output state ready to be passed forward into the next canonical block, determined by miners. And so on and so forth; that is how the Ethereum blockchain do.

We’ve so far ‘black-boxed’ the EVM as the state transition function (machine) that takes previous valid blocks and a handful of fresh transactions (as input), does some computation on it, and spits out a new valid state (as output). The other pieces of the Ethereum protocol (such as miners choosing canonical blocks) are necessary context, but now it’s time for some inside-the-box thinking. What about those specific rules we set aside earlier? How does the EVM compute a new state? How can a single machine compute everything from simple balance transfers to elliptic curve algebra?

The Steampunk Stack Machine

The best I can do to introduce the notion of a stack machine is this cartoon image of Babbage’s Analytical Engine (credit: Sydney Padua), which was designed in 1837 but never built:

With most people carrying around fantastically powerful electric computers in their pockets these days, it’s easy to forget that computers don’t necessarily need to be electronic, nor all that powerful. Babbage’s Analytical Engine is a very (hypothetically) real example of a Turing-complete (!) computer that if it had been built, would’ve run on steam and punch cards. The EVM is in important ways much closer kin to the Analytical Engine of two centuries ago than to the CPU inside the device you’re using to read this article.

The EVM is a stack machine, and although in reality it’s a virtualized machine running inside many Ethereum clients simultaneously, I find helpful to imagine the EVM as a real, more advanced (but of course still steam-powered) version of the Analytical Engine. This metaphor might seem a little far-fetched, but I implore you to stick with it for a little bit because it’s quite illustrative when we get to the subject of gas and a shared execution environment.

The steampunk EVM would be a mechanical computer that functions by manipulating physical punch cards. Each card would have 256 places for hole punches, and therefore each card could represent any number between 0 and 2^256. To perform a calculation, one could imagine this computer, through some fancy system of compressed air, putting the cards representing numbers and operations into a stack, and following a simple principle of “first in, last out”, one-by-one it would PUSH new cards to the top of the stack, or POP cards from the top of the stack to read them for next steps. These might be new numbers to calculate with, or arithmetic operations like ADD or MULTIPLY, but they could also be special instructions such as to STORE a card or set of cards for later. Because the cards are simple binary, the operations also have to be ‘encoded’ into a binary number; so we call them operational codes, or just opcodes for short.

If the stack machine were calculating 4 * 5 + 12, it would go about it like so:

_POP value 4 from the stack, keep it in memory. POP the value 5 off the stack, keep it in memory. POP the value _ from the stack; send everything in memory to the multiplication module; PUSH the returned result (20) the stack. POP the value 20 from the stack; keep it in memory. POP the value 12 from the stack; keep it in memory. POP the value + from the stack; send everything in memory to the addition module; PUSH the returned result (32) the stack. (Source: The EVM Runtime Environment)

We can imagine opcodes like ADD or MULTIPLY as special modules built into the machine, near enough to the stack so as to be accessible quickly. When the computer must multiply 4 and 5, it would send both cards to the “multiplication engine”, which might click and hiss before spitting back out the number 20 punched into a new card to PUSH back to the top of the stack.

The “real” EVM has many different opcodes for doing various things. A certain minimum-viable set of these opcodes are needed to do generalized computation, and the EVM has all of them (along with some special ones for crypto, e.g. the SHA-3 hash function). For better or worse, the idea that the EVM is (or is not) Turing-complete has long been under discussion— it’s this stack-based architecture which has the property of Turing-completeness: The EVM’s rules of execution can in principle, given a long enough time and big enough memory, run any conceivable computer program so long as it’s compiled down to the correct 256-bit words and executed in the stack.

Compiling a program in our alternate universe would entail the creation of a booklet of punch cards containing the appropriate data and opcodes. This is literally (er, figurative-literally, whatever) the process going on under the hood when you write a smart contract in a high-level language like Solidity and compile it to bytecode. You can get a pretty good sense of how a programming language gets converted into machine code by reading this humerously annotated output of a Solidity compiler.

So far, the state has not been mentioned, but recall that we set out to understand the rules by which a state transition can be calculated. Now we can summarize it a bit more clearly: The EVM is the physical instantiation (read: instance) of the state transition function. A valid state in Ethereum is one that was calculated by the EVM, and the canonical state is the valid state with the most computational work done on it (as determined by the GHOST protocol).

(Ideal) Gas

We might imagine Babbage completing the fictitious Ethereum Stack Engine and thereafter announcing that all mathematical tabulations and solutions for impossibly difficult problems were now within reach. He’d invite mathematicians and engineers to package up their problems as ‘transactions’ and deliver them to be compiled by Lady Lovelace into punch cards to run through the world computer. (Incidentally, Lovelace was the first person to ever write a computer program, making her the original compiler). Since the machine is meant to be an implementation of the EVM and part of a larger Ethereum steampunk universe, we’d have to imagine the state as being some sort of massive Merkleized library catalog which would be updated once per day according to a pre-selected set and order of transactions chosen as ‘canonical’, and committed to archive.

The trouble with this vision is that a real, mechanical EVM would be extraordinarily expensive to run. The turning of gears, winding of springs, and pumping of various pneumatic chambers collating punch cards would use tonnes of coal every day. Who would bear the expense of running the engine constantly? Say that five mathematicians wanted to run their programs on a particular day, but there was only time enough for three. How would these and related problems of resource management be solved? The solution that Ethereum employs seems, paradoxically, a lot more intuitive when we think about a large and inefficient mechanical computer: Charge money for computation and memory storage!

Imagining the the operations of the stack machine to be powered by compressed air, one could measure the exact amount of gas needed to perform an ADD operation, and compare it to the (much larger) amount of gas needed for SHA3. The table of gas costs for each opcode could be made publicly available, and anyone submitting a program required to provide at least enough money for their computation and storage space according to the cost of gas (which might be related to the price of coal or the demand for computation). The final stroke of genius is to make the machine state itself a ledger for accounts and balances, allowing a user to include payment for their computation inside the transaction itself.

As you might know, gas in an Ethereum transaction accounts for computation and memory costs of the EVM. Gas costs for a transaction must be paid for in ETH, and cannot be recovered once the execution takes place, whether the operation succeeds or not. If a contract call runs out of gas at any point during an operation, it throws an out-of-gas error.

The gas mechanic cleverly does two jobs: Gas efficiently allocates the common-pool computational resources of the EVM according to demand, and provides reasonable protection against infinitely looping programs (a problem that arises from Turing-completeness).

In the next installment of “The 1.X Files”

I hope this fanciful mechanical explanation of a stack machine has been helpful. If you enjoyed thinking about the steampunk EVM as much as I have, and you like historically plausible alt-reality comic books, do investigate “The Thrilling Adventures of Babbage and Lovelace” linked earlier; you won’t be disappointed.

Getting a handle on something so abstract isn’t easy, but there are topics in the Stateless Tech Tree that will be much easier to approach with a relatively complete (even if it’s a bit cartoonish) mental image of an EVM implementation.

One such topic is the introduction of Code Merkleization to the EVM, which would greatly reduce the size of witnesses by breaking up compiled contract code into smaller chunks. Next time we’ll be able to dig in to these immediately.

As always, if you have any questions, comments, requests for new topics or steampunk Ethereum fanfictions, please @gichiba or @JHancock on twitter.

Facepalm: As artificial intelligence becomes more sophisticated, a new breed of scam is quietly siphoning millions from the US higher education system. Cybercriminals are using AI-driven bots to impersonate students, enroll in online college courses, and divert financial aid, leaving real individuals with stolen identities and fraudulent debt.

One San Francisco resident, Heather Brady, learned the hard way how sophisticated education scams have become. A police officer showed up at her home with an unexpected question about her alleged college enrollment in Arizona. Brady had never applied ,but someone else had used her personal information to secure government aid.

Later, she discovered a student loan for more than $9,000 had been issued in her name for classes she never attended. “I just can’t imagine how many people this is happening to that have no idea,” Brady told The Associated Press.

The problem is escalating rapidly as online classes grow more widespread and AI tools make it easier for scammers to automate the entire process. These so-called “ghost students” can complete applications, enroll in classes, participate in coursework, and even submit assignments without a human ever being involved. In some cases, instructors have found that almost none of their students are genuine, with legitimate learners locked out of required classes because bots filled all the available slots.

The financial toll is substantial. In 2024, California’s community colleges reported 1.2 million suspicious applications, leading to over 220,000 likely fraudulent enrollments, according to data obtained by the Associated Press. The system lost at least $11.1 million in unrecoverable financial aid last year alone. Community colleges are particularly vulnerable, as their lower tuition means a greater portion of grant and loan funds goes directly to students for living expenses.

Wayne Chaw, who once took classes at De Anza Community College, was notified about a course he never signed up for. Thieves had used his Social Security number to claim nearly $1,400 in aid, and someone – likely an AI bot – was submitting homework under his name. “This person is typing as me, saying my first and last name. … It’s very freaky when I saw that,” Chaw said.

For victims, unraveling the damage is a long and frustrating ordeal. Brittnee Nelson, a small business owner in Louisiana, discovered that loans had been taken out in her name for schools she never attended. Despite diligently monitoring her credit and safeguarding her identity, she spent two years working to remove the fraudulent debt. “It’s like if someone came into your house and robbed you,” Nelson said.

Colleges say they often lack the power to prevent these scams. Delgado Community College in New Orleans, for example, emphasized that the ultimate authority for loan approval lies with federal agencies. “This is an unfortunate and serious matter, but it is not the direct or indirect result of Delgado’s internal processes,” said spokesperson Barbara Waiters.

In response to the surge in fraud, the US Department of Education recently enacted a temporary measure requiring first-time federal aid applicants to verify their identity with a government-issued ID. The department acknowledged the severity of the threat, stating, “The rate of fraud through stolen identities has reached a level that imperils the federal student aid program.” More robust screening is expected to follow.

While the government scrambles to tighten security, its capacity to investigate and resolve fraud is shrinking. Recent layoffs and staff attrition at key federal offices have left fewer personnel available to assist victims and pursue scammers. Brady, still facing the prospect of a $9,000 debt she never incurred, fears that help may never come. “The agency is going to be so broken down and disintegrated that I won’t be able to do anything, and I’m just going to be stuck” she said.

Recent prosecutions illustrate the scale of the problem. They include a Texas man accused of orchestrating a $1.5 million aid fraud, another individual in Texas admitting to using inmates’ names to claim more than $650,000, and a New York resident pleading guilty to a decade-long, $450,000 scam.

As AI-powered schemes continue to evolve, students and taxpayers remain at risk. Nelson believes stronger identity checks are essential. “If they can make these hurdles a little bit harder and have these verifications more provable, I think that’s really, really, really going to protect people in the long run,” she said.

CISA and the FBI said attackers deploying Ghost ransomware have breached victims from multiple industry sectors across over 70 countries, including critical infrastructure organizations.

Other industries impacted include healthcare, government, education, technology, manufacturing, and numerous small and medium-sized businesses.

“Beginning early 2021, Ghost actors began attacking victims whose internet facing services ran outdated versions of software and firmware,” CISA, the FBI, and the Multi-State Information Sharing and Analysis Center (MS-ISAC) said in a joint advisory released on Wednesday.

“This indiscriminate targeting of networks containing vulnerabilities has led to the compromise of organizations across more than 70 countries, including organizations in China.”

Ghost ransomware operators frequently rotate their malware executables, change the file extensions of encrypted files, alter the contents of their ransom notes, and utilize multiple email addresses for ransom communications, which has often led to fluctuating attribution of the group over time.

Names linked to this group include Ghost, Cring, Crypt3r, Phantom, Strike, Hello, Wickrme, HsHarada, and Rapture, with ransomware samples used in their attacks including Cring.exe, Ghost.exe, ElysiumO.exe, and Locker.exe.

This financially motivated ransomware group leverages publicly accessible code to exploit security flaws in vulnerable servers. They target vulnerabilities left unpatched in Fortinet (CVE-2018-13379), ColdFusion (CVE-2010-2861, CVE-2009-3960), and Exchange (CVE-2021-34473, CVE-2021-34523, CVE-2021-31207).

To defend against Ghost ransomware attacks, network defenders are advised to take the following measures:

1. Make regular and off-site system backups that can’t be encrypted by ransomware,
2. Patch operating system, software, and firmware vulnerabilities as soon as possible,
3. Focus on security flaws targeted by Ghost ransomware (i.e., CVE-2018-13379, CVE-2010-2861, CVE-2009-3960, CVE-2021-34473, CVE-2021-34523, CVE-2021-31207),
4. Segment networks to limit lateral movement from infected devices,
5. Enforce phishing-resistant multi-factor authentication (MFA) for all privileged accounts and email services accounts.

Right after Amigo_A and Swisscom’s CSIRT team first spotted Ghost ransomware in early 2021, their operators were dropping custom Mimikatz samples, followed by CobaltStrike beacons, and deploying ransomware payloads using the legitimate Windows CertUtil certificate manager to bypass security software.

In addition to being exploited for initial access in Ghost ransomware attacks, state-backed hacking groups that scanned for vulnerable Fortinet SSL VPN appliances also targeted the CVE-2018-13379 vulnerability.

Attackers also abused the same security vulnerability to breach Internet-exposed U.S. election support systems reachable over the Internet.

Fortinet warned customers to patch their SSL VPN appliances against CVE-2018-13379 multiple times in August 2019, July 2020, November 2020, and again in April 2021.

The joint advisory issued by CISA, the FBI, and MS-ISAC today also includes indicators of compromise (IOCs), tactics, techniques, and procedures (TTPs), and detection methods linked to previous Ghost ransomware activity identified during FBI investigations as recently as January 2025.