Last week on Bytecode Tuesday, we talked about making CALLs, how contracts can execute functions from other contracts. This week, we answer a more fundamental question: How much does it cost to run bytecode?

What Is Gas in the EVM?

Every opcode in Ethereum bytecode has a gas cost, which is the fee you pay to execute that instruction.

Gas prevents infinite loops and ensures that every transaction has a computational cost. It's Ethereum's way of making sure the network doesn’t get overloaded with spam or heavy computations. Additionally, it keeps the system healthy by rewarding validators and even removing excess ETH tokens from the system

When you send a transaction, you set a gas limit, which is the maximum you're willing to spend, and pay the gas used in ETH. If your transaction runs out of gas halfway through, the EVM reverts the entire transaction, this means no state changes, and the gas is still consumed.

However gas is not measured in ETH, it’s just a unit. The actual ETH cost of gas is based on network demand based on the following formula:

Total Cost (in ETH) = Gas Used × Gas Price

EIP-1559: Base Fee, Priority Fee, and Max Fee Explained

With the London hard fork, Ethereum introduced EIP-1559, a major change to how transaction fees are calculated. Instead of a single gasPrice, each transaction now includes:

• maxFeePerGas: the total you're willing to pay per unit of gas

• maxPriorityFeePerGas: the tip you're offering to the validator

• The network defines a baseFeePerGas, which must be paid and is burned, this means it is removed from circulation

The Gas Price you actually pay is:

Gas Price = baseFeePerGas + min(priorityFee, maxFeePerGas - baseFeePerGas)

If maxFeePerGas is less than the current base fee, your transaction is invalid and won’t be included.

This means that EIP-1559 made improved user UX by making the gas costs more predictable, less competitive and even burns a part of the costs to keep ETH price more sustainable.

Gas Cost per Opcode

Each opcode has a fixed cost also called static cost, and some have extra costs called dynamic cost. Dynamic costs are based on what they do.

Let’s see some examples:

How Dynamic Gas Costs Affect Your Contracts

When writing a contract is important to understand how gas fees affect the design of your code. The following are the tree most important gas behaviors to keep in mind.

Storage Writes (SSTORE) Are Expensive and Refundable:
Writing to storage costs a lot because it changes the blockchain state permanently. However, if you set a storage slot back to zero (clearing it), you get a partial gas refund. This incentivizes cleaning up state to keep the blockchain size manageable.

Memory Expansion Grows Quadraticall:
When your contract uses memory beyond what was used before, the gas cost increases not just linearly but quadratically. This means doubling your memory roughly quadruples the gas cost. Avoid scattered memory writes and reuse low memory offsets when possible.

Calls Are Costly and Variable:
Calling another contract is not just one opcode cost and since the called contract runs its own bytecode, it might consume even more gas than expected.

This article concludes our 10 week experiment on writing bytecode articles. We hope now you understand better what happens behind the scene when you code or use a smart contract.

Thanks for reading!

Welcome back to Bytecode Tuesday, where we pull back the curtain on what your smart contract is really doing under the hood. Last week, we looked at functions, how they're organized in bytecode and how the EVM routes execution. This week, we take on one of the most powerful opcodes in the EVM toolbox: CALL.

What is CALL?

CALL lets your smart contract talk to other contracts (or even itself) on the Ethereum blockchain.

Do you want to interact with an ERC20 token? Or invoke another contract’s function? Or even delegate work across contracts? You can do that with the CALL opcode.

But CALL isn’t just one thing, it’s a low-level instruction with a lot of parameters. Think of it like dialing a phone number where you also have to specify how much credit you’re willing to spend, what data to send, and where to store the response.

Anatomy of a CALL

CALL's bytecode is F1 but before the EVM can run it, you need to set up the stack with 7 arguments, in this exact order (from top to bottom of the stack):

Once you push all that onto the stack, CALL consumes it and tries to make the call. If it succeeds, it pushes 1 onto the stack. If it fails, it pushes 0.

What Happens in a CALL?

When one contract uses the CALL opcode to invoke another, two key pieces of data flow across:

1. Input data (calldata): What we send to the other contract (e.g. function selector + parameters).

2. Return data: What we get back from the other contract (if any).

Let’s See an Example

Let’s say we want to call another contract with no ETH, send 4 bytes of data (a function selector), and expect 32 bytes back.

Here’s the bytecode to make that happen:

PUSH1 0x20				// return data length = 32
PUSH0						// return data offset = 0
PUSH1 0x04				// call data length = 4
PUSH0						// call data offset = 0
PUSH0						// value to send = 0
PUSH20 <address>	// the contract address
PUSH2 0xFFFF			// gas = 65535 (for example)
CALL

We assume the calldata (like a function selector) is already stored in memory at offset 0x00.

And the actual bytecode form would be: 60205F60045F5F73<address>61FFFFF1.

After the CALL, the result (success or failure) will be on the top of the stack.

Error Handling with CALL

Unlike Solidity, which reverts on failed external calls by default, raw CALL does not. If the call fails, you just get 0 on the stack and it’s up to you to decide what to do.

So if you want to revert on error, you must explicitly check.

Other CALL Opcodes

Here’s a quick table of the family of call-related opcodes:

The CALL opcode is low-level and flexible. It exposes everything gas, calldata, return handling, and value transfers. While Solidity wraps it in nice syntax, EVM developers get to shape the whole interaction exactly how they want.

See you next Tuesday for our last Bytecode Tuesday release!

Is important to understand how function call work under the hood to be able to write better and safer smart contract, optimize, and integrate with any tooling available today. Additionally, this way we can prepare for future updates where EVM get's improved.

We are going to create a smart contract that has two functions as shown in the following pseudocode:

MyContract {
  a() {
    return 4
  }
  b() {
    return 5
  }
}

But before writing it we need to understand a concept introduced into the Ethereum ecosystem very early on: Function Signature Hashing.

What are functions signatures?

Function signatures are a standard and particular way to express the function names and parameters, for example the following is the ERC20 function signatures. Notice no spaces, also the return values are not expressed.

name()
symbol()
decimals()
totalSupply()
balanceOf(address)
transfer(address,uint256)
transferFrom(address,address,uint256)
approve(address,uint256)
allowance(address,address)

However , just as any bytecode language, the EVM has no native string implementation, it only has bytes. So in order to express function names in bytecode, the early ethereum community decided to hash the function names and grab the first 4 bytes. Those 4 bytes will represent the function names inside of EVM bytecode contracts. The following are ERC20 function signatures.

• name(): 0x06fdde03

• symbol(): 0x95d89b41

• decimals(): 0x313ce567

• totalSupply(): 0x18160ddd

• balanceOf(address): 0x70a08231

• transfer(address,uint256): 0xa9059cbb

• transferFrom(address,address,uint256): 0x23b872dd

• approve(address,uint256): 0x095ea7b3

• allowance(address,address): 0xdd62ed3e

This standard has been adopted by high level languages (solidity, vyper), indexers (etherscan, blockscout) and JS tooling (ethers, viem). It has been rightfully criticized of being too gas expensive, it can express more than 4 billion functions per contract where 1 byte can serve 256 functions, more than enough for most, if not all, contracts deployed on ethereum. That being said, this format has served to build a lot of tooling a provide good developer experience because it has been widely adopted across the all EVM usage.

How to pass data to functions

The standard in which any Ethereum account and smart contract can call functions on another smart contract is by sending data to another smart contract in the following format:

<4 byte signature><32 byte Param1><32 byte Param2><32 byte Param3>...

Data received can be read by calling the opcode CALLDATALOAD (aka 0x35) that receives a byte offset to be read.

Now let's go back to our example

We now know everything we need to create the contract we will be showcasing step-by-step.

MyContract {
  a() {
    return 4
  }
  b() {
    return 5
  }
}

The pseudocode smart contract entry (function dispatcher):

signature = CALLDATALOAD(0) // read first 4 bytes of call data
if signature == 0x0DBE671F			// this is the a() function signature
	goto a();
else
	goto b();

Notice that we are not using params and we assume that, if a() was not called b() will be called. This is not normally the case in smart contracts but understanding this simple example will give you solid foundations to understand more complex contracts later on.

The following is the smart contract runtime bytecode implementation:

5F		// PUSH0, which is a more gas efficient way of performing PUSH1(0)
35		// CALLDATALOAD
7F 0DBE671F00000000000000000000000000000000000000000000000000000000	// PUSH the a() function signature
14		// EQ, if the top 2 elements stacks are equal they get replaced by 0x01, otherwise by 0x00
60 2F	// PUSH1(0x2F) this is the function a() code destination, at byte 47
57		// JUMPI Jumps to byte 47 (0x2F) if the top of the stack is 0x01
// This is now function b() code
60 05	// PUSH1(0x05) the b() return value is now on the stack
5F		// PUSH0 we will place it on the memory to return it
52		// MSTORE 0x05 is not on memory
60 20	// PUSH1(0x20) Return size is 32 bytes, 0x20
5F		// PUSH0 pushes the offset of memory returned
F3		// RETURN
// This is function a() code, very similar to b()
5B		// JUMPDEST signals a safe landing for JUMPI 
60 04	// PUSH(0x04) Pushes the a() return value
5F		// PUSH0 Memory location where the number 0x04 will be placed
52		// MSTORE The return value is now on memory
60 20	// PUSH1(0x20) Return value is 32 bytes, 0x20
5F		// PUSH0 The location of the value returned, in memory
F3		// RETURN

And the following is the full string of bytes.

5F357F0DBE671F0000000000000000000000000000000000000000000000000000000014602F5760055F5260205FF35B60045F5260205FF3

But it's easier to understand with the following animation.

We hope you now have more clarity on how EVM smart contract functions work, this knowledge is fundamental for security auditors, builders and users to have the best results out the EVM and to prepare for future upgrades.

Thanks for reading, see you next Tuesday for more bytes!

Last week, we dissected smart contract deployment and how to separate init code from runtime code.

This week, we're diving into a recent (Dencun update) and powerful EVM feature: Transient Storage.

Why Do We Need Transient Storage?

We already know the three main data regions in the EVM: the stack which is super fast but only lasts for the current instruction, the memory that resets after each all and the persistent storage.

But there’s a gap:
What if we want to share temporary data between cross contract calls in a single transaction. Specifically in cases where data doesn’t need to persist after the transaction ends.

That’s where Transient Storage comes in.

What Is Transient Storage?

Transient Storage is like ephemeral memory that survives across calls but gets wiped at the end of the transaction. It’s a key-value store like regular SSTORE, but it’s cheaper and isolated to the current transaction.

The Opcodes: TSTORE and TLOAD

Ethereum introduced two new opcodes (with EIP-1153 in Decun update) to interact with transient storage:

These behave exactly like SLOAD and SSTORE, except the data is not persistent and can be use across smart contract calls.

Example:

Imagine a contract where Contract A sets a flag, calls Contract B, B calls A again, and then A checks that flag. With transient storage, Contract A can do this without writing to permanent storage.

Here’s a simplified outline:

PUSH1 0x01		// Value to write
PUSH1 0x00		// Key to write
TSTORE				// Store 1 into transient[0]

CALL					// Call logic (Abstracted because have not discussed it here yet)


// Reentry point
PUSH1 0x00		// Key to read
TLOAD				// Read from transient[0]

Unlike memory (which resets when there is an external call), this value remains accessible to all internal functions during the transaction.

Hands-On: Transient vs Persistent

Let’s store and retrieve a value both in transient and persistent storage to compare:

// Transient Store
PUSH1 0x2A
PUSH1 0x00
TSTORE
// Transient Load
PUSH1 0x00
TLOAD
// Persistent Store
PUSH1 0x2A
PUSH1 0x01
SSTORE
// Persistent Load
PUSH1 0x01
SLOAD

As you can see, the call API is very similar but when the transaction ends, the persistent value at slot 0x01 remains on-chain while the transient value at slot 0x00 is gone.

Use Cases for Transient Storage

• Re-entrancy Guards: Instead of storing a boolean in storage (expensive), store a flag in transient storage.

• Efficient Intermediate Values: Use transient slots to coordinate between multiple contract calls without touching global state nor calldata parameters.

• Gas-Efficient Caching: Cache data temporarily across contract calls in the same transaction.

Visual Recap

Try It Yourself

Write and check using this EVM Disassembler bytecode that:

1. Stores 0xAA in transient slot 0x00

2. Loads it from the same slot

3. Returns it

We’ve now seen how to manage state across contract calls, next Tuesday, we’ll look at how contracts organize their dispatch logic using functions. Subscribe for more bytes.

So far, we’ve explored how the EVM reads bytecode, how it handles memory and storage, and how it controls program flow with jumps. But here’s a question we haven’t answered yet: what happens when you deploy a contract?

When you deploy a smart contract, you’re sending a special transaction where:

• to = 0x0 (indicating contract creation)

• data = <contract bytecode>

But that <contract bytecode> is not just the logic of your contract. It’s a complete program that runs once during deployment. This program:

1. Runs your constructor

2. Uses the RETURN opcode to return the runtime code to the EVM

What the EVM stores to the blockchain is only the runtime code.

Contract Deployment Transaction Main Parts

When you deploy a new contract, the calldata bytecode of that transaction is usually divided into two parts.

1. Init Code

This is the first part of the bytecode. It executes only once at deployment. It starts by running the constructor logic where it can do writes in the storage if needed. Then returns the actual runtime code using the RETURN opcode.

When RETURN is called in the constructor, the value returned becomes the runtime code that is stored on-chain at your contract’s address.

2. Runtime Code

This is the code that actually lives on-chain at your contract address and runs every time someone calls the contract.

It’s the part that responds to function calls, reads calldata, interacts with storage, emits events, and does all the real work.

You can think of it like the permanent body of your contract. The init code is a temporary wrapper that sets it up.

Typical Init Code Strucuture

A typical structure of a innit code consists in loading the runtime code into memory and returning it.

PUSH1 <size>       // Number of bytes to copy (runtime size)
PUSH1 <offset>     // Starting point in bytecode
PUSH1 <dest>       // Destination in memory (typically 0x00)
CODECOPY           // Copy bytecode to memory
PUSH1 <size>        // Return size
PUSH1 <dest>       // Memory offset to return from
RETURN                // Return runtime code to EVM

Let's take a look at a typical way of deploying a smart contract on chain.

Example deployment bytecode:

6038600C60003960386000F35F357F0DBE671F0000000000000000000000000000000000000000000000000000000014602F5760055F5260205FF35B60045F5260205FF3

Let's now look at a step by step code deployment execution.

In our example, the process was:

1. Copy 56 bytes from <contract bytecode> starting at offset 12

2. Place them at memory position 0

3. Return them, this becomes the runtime code

In more complex smart contracts init code can also perform storage intializations, calls to other contracts or even new contract deployments.

Now you know what happens behind the scene when a contract is deployed. Thanks for reading and see you next Tuesday for more bytes.

Last week, we talked about Stack, Memory, and Storage, the three data regions of the EVM. Today, we’re going to explore how smart contracts make decisions and change execution paths using control flow.

What is control flow?

Control flow is the logic that determines what happens next in a program. In Solidity, you use if, else, for, while, or function calls. In bytecode, those high-level keywords are translated into jump instructions.

The EVM is a very simple machine, it executes bytecode one instruction at a time, moving forward by default. But with control flow instructions, we can tell it to jump to a different part of the code, or conditionally jump based on a value.

The Core Control Flow Opcodes

Example: Conditional return based on input

Let’s say you want to write a smart contract that:

• Returns 0x02 if the input is greater than 10

• Otherwise, returns 0x01

This is what our example looks like in pseudocode:

if (input > 10) {
  return 0x02;
} else {
  return 0x01;
}

And here’s what the EVM bytecode can be implemented:

False branch (default: input <= 10)

True branch (input > 10) starts at 0x12

Branch merge point, true and false branches converge here

Do we need JUMPDEST?

The EVM doesn’t allow jumping to just any byte, it has to be a JUMPDEST. This design prevents jumping into the middle of data or invalid instruction segments. Think of JUMPDEST as a checkpoint you can land on.

While marking safe spots for jump instructions is considered a sound and secure virtual machine design choice, the EVM has been rightfully criticized for requiring full 32-byte absolute offsets for every jump. This approach is unnecessarily heavy. A more ergonomic and lightweight alternative would be to use relative jumps based on the current execution point (known as the program counter). In most cases, such as typical if or while logic, the jump distances are small and could easily be expressed in a single byte. The inefficiency of absolute jumps is well-known, and there is ongoing discussion in the Ethereum ecosystem about adopting relative jumps in future virtual machine designs.

What’s Happening?

1. Input is loaded from calldata.

2. Compared with 10 using the GT (greater than) opcode.

3. If true, we JUMPI to a labeled part of the code where we return 0x01.

4. If false, the EVM continues forward and returns 0x00 and jumps to the merge point

5. The merge point is where both true and false branches reunite and returns the result

Both branches store the result at the stack, then on the merge point a 32-byte value padded with zeros is returned.

Try It Yourself

Modify it and check it using this EVM Disassembler to:

• Return 0xAA if the input is less than 5

• Return 0xBB if the input is between 5 and 20

• Return 0xCC otherwise

So far, we've explored bytecode piece by piece, but what does a real smart contract look like in raw bytecode?

Next Tuesday, we’ll take a full contract and break it down section by section. Subscribe now and see you next Tuesday for more bytecode.

Welcome back to Bytecode Tuesday. Last week, we saw how your contract gets compiled, deployed, and executed on Ethereum. This week, we cover something even more fundamental: the three data regions of the EVM.

Let’s recall them from the last post:

• Stack for last-in, first-out temporary values,

• Memory for intra-transaction data (a byte array that resets every call), and

• Storage slots for persistent state (a mapping of 32-byte keys to 32-byte values).

Now let’s break each one down

The Stack: Last-In, First-Out

Think of the stack like a pile of plates. You can only work with the top one. It’s:

• Last-In, First-Out (LIFO)

• Can hold up to 1024 items (each 32 bytes)

• Super fast and cheap to use

Some Relevant Instructions:

PUSH1 VALUE → put VALUE on the stack
Bytecode: 60VALUE // Replace VALUE with your desire value in hexadecimal (1 byte)
PUSH32 VALUE → put VALUE on the stack
Bytecode: 7FVALUE // Replace VALUE with your desired value in hexadecimal (32 bytes)
ADD → pop the top two values, add them, and push the result
Bytecode: 01

Example:

Which translates as

PUSH1 0x02
PUSH1 0x03
ADD

Let’s now see how the stack is being manipulated in the following step by step animation.

Memory: The Scratchpad

Memory is like RAM: it’s cleared after each transaction or call. You can use it to:

• Store temporary values during execution

• Return data to the caller (via RETURN)

• Store arrays, strings, etc.

Some Relevant Instructions

MSTORE → store 32 bytes at a memory offset
Bytecode: 52
MLOAD → read 32 bytes from memory
Bytecode: 51

Example:

Which translates as:

PUSH1 0x2A        // Value to store
PUSH1 0x00        // Memory offset
MSTORE             // Save 0x2A at offset 0x00, since MSTORE stores 32 bytes and we just push 1 byte (0x2A), the EVM left-pads the 1-byte value with 31 zero bytes to make it 32 bytes. This padded value is then stored at the specified memory offset (in this case 0x00).
PUSH1 0x20        // Length to return
PUSH1 0x00        // Start offset
RETURN              // Return memory [0x000….2A]

In the following animation notice how the memory operates based on stack inputs.

Storage: The Blockchain's Hard Drive

Each smart contract has its own storage, which is:

• Persistent: Survives across transactions

• Expensive: Writing to storage costs significant gas.

• Private to the contract: One contract cannot directly access another’s storage.

The EVM storage maps data using 32-byte (256 bits) keys and values.

So, the storage can be visualized as a map like:

0x0000000000000000000000000000000000000000000000000000000000000000 → 0x... (32 bytes)
0x0000000000000000000000000000000000000000000000000000000000000001 → 0x... (32 bytes)

Why 32 Bytes?

Ethereum uses 32 bytes words as the native unit for storage and computation. This design aligns naturally with the Keccak-256 hashing, which produces 32 bytes outputs. Since Ethereum relies heavily on this algorithm, for addresses, storage keys, and more, structuring everything around 32-byte chunks makes contract development efficient.

However, this design isn’t without tradeoffs. Storing small values, like a boolean or a single digit, still consumes the full 32 bytes, which means wasted space and higher gas costs. Developers often have to pack and unpack multiple values manually to use storage efficiently, adding complexity on both smart contracts and dApps frontends.

The EVM's 32-byte word size made sense for early Ethereum, especially given its focus on DeFi, tokens, and ownership primitives. But as the platform evolves into a general purpose execution layer, the limitations of this native word size become more apparent. There’s growing interest, including from Vitalik himself, in exploring a more flexible, byte oriented virtual machine that better supports new use cases and broader types of applications.

Some Relevant Instructions:

SSTORE → write value to a storage slot
Bytecode: 55
SLOAD → read from a storage slot
Bytecode: 54

Example:

Which translates as:

PUSH1 0x2A       // value
PUSH1 0x00       // storage key
SSTORE             // storage[0x000…00] = 0x2A, since SSTORE uses a 32-byte key and value, the EVM left-pads the 1-byte value with 31 zero bytes to make it 32 bytes in the same way as 
PUSH1 0x00       // key
SLOAD               // load from storage[0x000...00], as SSTORE, it left-pads the 1-byte key with 31 zero bytes

As you can see, the memory and the state operate very similarly, the main difference is the memory is addressed by byte pointers while the state by 32 byte slots.

Stack vs Memory vs Storage

Hands-on Assignment

Write and check using this EVM Disassembler bytecode that:

1. Stores the number 42 in memory

2. Loads it back from memory

3. Returns it

Bonus: Can you also store it in storage, then load and return it?

Bytecode isn’t magic. It’s just a sequence of stack gymnastics mixed with clever use of memory and storage.

Next week on Bytecode Tuesday, we’ll explore control flow, how to change the flow of execution inside a smart contract. Subscribe now for more weekly bytes and opcodes.

In the last article we explored opcodes, the individual instructions the EVM executes. Today we’re tracing the two distinct journeys your contract takes: one when you deploy it, and another each time it’s called.

1. Writing and Compiling

You start with a .sol or .vy file in Solidity or Vyper, defining functions, state variables and control flow in human-readable form. When you invoke solc or vyper, the compiler outputs EVM bytecode, a linear stream of one-byte opcodes plus any immediate data. That bytecode is split into a header segment, which runs once to set up constructor logic and write initial values into storage slots, and a runtime segment, the permanent code that lives at your contract’s address.

2. Deploying a Contract

Deployment is its own transaction with to = 0x0 and data = <contract-bytecode>. That transaction enters the network’s mempool, where nodes check nonce, gas limit and signature. When a block proposer includes it in a block, the EVM executes the header segment: it manipulates the stack, uses transient memory (a temporary byte array that persists only during each transaction) for intermediate data, and writes to persistent storage slots (32-byte keys in the global state). If init succeeds within the gas budget, the runtime segment is returned and stored at the new contract address. For this point forward your contract is now live on the blockchain.

3. Executing Contract Bytecode

Each call to your contract is another transaction with to = <contract-address> and data = <calldata>. Again it joins the mempool for basic validation. After mempool validation, the EVM loads the stored runtime bytecode and runs it with three data regions:

• Stack for last-in, first-out temporary values,

• Memory for intra-transaction data (a byte array that resets every call), and

• Storage slots for persistent state (a mapping of 32-byte keys to 32-byte values).

Storage in Ethereum is organized using a data structure called the Merkle Patricia Trie, which is a specialized form of a Merkle tree. This trie efficiently encodes key-value pairs (such as storage slots or account data) into a compact structure where the root hash represents the entire global state. Every time a storage slot is updated, the corresponding MPT changes, resulting in a new root hash that reflects the updated state.

During contract execution, each opcode consumes a certain amount of gas. If the transaction runs out of gas, all changes made during the call are reverted, this includes the stack, the memory and the storage. But when execution succeeds, the changes to storage and the emitted logs are emitted. The state of Ethereum then updates in the following flow: the old state root and the calldata (which you can think of as input parameters) are processed by the contract’s runtime bytecode. This produces an execution trace, which results in a new state root. The updated root reflects the global state after the transaction and is used in the block’s final state commitment.

4. Consensus and Finality

Upon successful execution, the node calculates a new state root, a Merkle Patricia commitment covering every account balance and storage slot. That root is embedded in the block header. Under Proof-of-Stake, validators propose and attest to blocks; peers re-execute the same bytecode to confirm the state root matches, then follow the fork-choice rule and finalized checkpoints to agree on one canonical chain. Once finalized, your deployment or function call is irreversible.

Now that you have a clear, step-by-step view of deployment versus execution and how each leads to a consensus-backed state, you’re ready to dive deeper into how contracts are constructed at the bytecode level. Subscribe here on paragraph and join us next Tuesday for more bytecode.

Welcome back to Bytecode Tuesday🤝

Last week, we talked about EVM Bytecode, the raw machine level code that the Ethereum Virtual Machine (EVM) understands and executes. This week, we're going a level deeper: Opcodes.

What is an Opcode?

An opcode (short for operation code) is a single instruction that tells the EVM what to do.

Think of it like a Lego block: each opcode does one very specific thing. When you put a bunch of them together, you build a working smart contract.

Each opcode is represented by 1 byte (2 hexadecimal characters), and each one corresponds to an operation like:

Storing data Loading data Adding two numbers Returning a result Jumping to a different part of the code

Some opcodes are followed by parameters or data, depending on what the operation needs.

Let's look at real Bytecode

Let’s take this snippet of bytecode:

7F00000000000000000000000000000000000000000000000000000000000000105F5260205FF3

What does this program do?

In plain English:

It pushes the number 16 (at the end of the PUSH32) to memory position 0 Then, it returns 32 bytes of memory starting at position 0 This includes the number 16 we just stored, followed by 31 zero bytes

It's a simple program that always returns the same 32-byte value (number 16 in decimal), which is composed mostly of zeros, except for a 0x10 (16) at the end.

We’ll break this down into opcodes and understand what each one does.

Dissecting the Code

We'll read it left to right, 1 byte at a time (2 hex characters = 1 byte)

Initial Stack: The stack is empty at the beginning.

Opcode 7F (PUSH32): Pushes the next 32 bytes onto the stack. These bytes represent the number 0x0000000000000000000000000000000000000000000000000000000000000010, which is 16 in decimal.

Opcode 5F (PUSH0): Pushes the constant 0 onto the stack (Equivalent to PUSH1 0, but with gas savings).

Opcode 52 (MSTORE): Pops the top two values from the stack and stores the second value at the memory location specified by the first value. In this case, it stores 0x0000000000000000000000000000000000000000000000000000000000000010 at memory location 0.

Opcode 60 20 (PUSH1 0x20): Pushes the byte 0x20 (32 in decimal) onto the stack (length of the data we want to return).

Opcode 5F (PUSH0): Pushes the constant 0 onto the stack.

Opcode F3 (RETURN): Pops the top two values from the stack. The first value specifies the memory location to start returning data from, and the second value specifies the size of the data to return. It returns 32 bytes starting from memory location 0.

The returned data is 0x0000000000000000000000000000000000000000000000000000000000000010, the number 16 in decimal notation.

Understanding the Flow

Stack Operations: The stack operates on a Last In, First Out (LIFO) principle. Each opcode manipulates the stack by pushing or popping values, which are then used in subsequent operations.

Memory Storage: The MSTORE opcode stores data in memory, which is temporary and used during contract execution. In this example, the number 16 is stored at memory location 0.

Returning Data: The RETURN opcode allows the contract to return data to the caller. It specifies the memory location and size of the data to be returned.

Assignment

Try using our online EVM Disassembler to break apart this bytecode yourself.

What is Bytecode?

Bytecode is a low-level version of your smart contract. It’s what your Solidity code turns into before it gets deployed on the Ethereum blockchain (or any Ethereum compatible blockchain , a.k.a EVM compatible blockchain).

Think of it like this:

You write your contract in Solidity (a human-friendly language). Then the computer translates it into bytecode (a machine-friendly language). This bytecode is what the Ethereum blockchain actually understands and runs.

What is the EVM?

EVM stands for Ethereum Virtual Machine. It’s like a global computer that runs on every Ethereum node. Whenever someone deploys or interacts with a smart contract, the EVM is responsible for running that code.

The EVM doesn't understand Solidity (or any other smart contract language) directly. It understands bytecode, a set of very simple instructions, kind of like a recipe with tiny steps.

The EVM Stack

The EVM uses something called a stack to do its work. Think of a stack like a pile of plates. You can only:

• Push a new plate onto the top, or

• Pop the top plate off.

You can't reach into the middle. You always work with the top of the pile.

How Instructions Work

In bytecode, everything is done by combining simple instructions. You push values onto the stack, then use an operation like ADD to do something with them.

Here’s a small example:

Add: 2 + 5

To add two numbers together, the EVM needs to:

1. Push the number 2 onto the stack

2. Push another 5 onto the stack

3. Run ADD to add the top two numbers

👀 What’s happening on the stack:

This is the foundation of how smart contracts work under the hood. Bytecode may seem basic, but when you combine lots of small instructions like this, you can build powerful and complex contracts, all without touching Solidity.

Click that Subscribe button for weekly bytecode learnings.

Let’s reject abstraction together.