Skip to content

Commit

Permalink
✨ feat: Update evm memory
Browse files Browse the repository at this point in the history
  • Loading branch information
raxhvl committed Oct 20, 2024
1 parent 388fae7 commit 0af3c39
Show file tree
Hide file tree
Showing 3 changed files with 11 additions and 9 deletions.
Binary file added docs/images/evm/evm-memory.gif
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Binary file removed docs/images/evm/evm-memory.jpg
Binary file not shown.
20 changes: 11 additions & 9 deletions docs/wiki/EL/evm.md
Original file line number Diff line number Diff line change
Expand Up @@ -56,7 +56,7 @@ In the figure above, each transaction is committed to a new state. However, in r

Considering the definition of the state transition function, we draw the following conclusion:

> ℹ️ Note
> ℹ️ Note
> **EVM is the state transition function of the Ethereum state machine. It determines how Ethereum transitions into a new (world) state based on input (transactions) and current state.**
In Ethereum, the world state is essentially a mapping of 20-byte addresses to account states.
Expand Down Expand Up @@ -98,6 +98,8 @@ This offers two key benefits: portability (bytecode runs on different platforms

The virtual machine concept serves as an abstraction. Ethereum Virtual Machine (EVM) is a _specific_ software implementation of this abstraction. The anatomy of the EVM is described below:

In computer architecture, a word refers to a fixed-size unit of data that the CPU can process at once. EVM has a word size of **32 bytes**.

![EVM anatomy](../../images/evm/evm-anatomy.jpg)

_For clarity, the figure above simplifies the Ethereum state. The actual state includes additional elements like Message Frames and Transient Storage._
Expand All @@ -108,7 +110,7 @@ In a real-world scenario, EVM may execute transactions involving multiple accoun

With a better grasp of virtual machines, let's extend our definition:

> ℹ️ Note
> ℹ️ Note
> EVM is the state transition function of the Ethereum state machine. It determines how Ethereum transitions into a new (world) state based on
> input (transactions) and current state. **It is implemented as a virtual machine so that it can run on any platform, independent of the
> underlying hardware.**
Expand Down Expand Up @@ -152,7 +154,7 @@ Select Opcodes used in this discussion:

Refer [Appendix H of Yellow Paper](https://ethereum.github.io/yellowpaper/paper.pdf) for a comprehensive list.

> ℹ️ Note
> ℹ️ Note
> [EIPs](https://eips.ethereum.org/) can propose EVM modifications. For instance, [EIP-1153](https://eips.ethereum.org/EIPS/eip-1153) introduced `TSTORE`, and `TSTORE` opcodes.
Ethereum clients such as [geth](https://github.com/ethereum/go-ethereum) implement the [EVM specifications](https://github.com/ethereum/execution-specs). This ensures all nodes agree on how transactions alter the system's state, creating a uniform execution environment across the network.
Expand Down Expand Up @@ -216,11 +218,11 @@ Refer [Appendix G of Yellow Paper](https://ethereum.github.io/yellowpaper/paper.

## Memory

EVM memory is designed as a **word-addressed byte array**. In computer architecture, a word refers to a fixed-size unit of data that the CPU can process at once. EVM has a word size of **32 bytes**.
EVM memory is a byte array of $2^{256}$ (or [practically infinite](https://www.talkcrypto.org/blog/2019/04/08/all-you-need-to-know-about-2256/)) bytes . All locations in memory are well-defined initially as zero.

![EVM Memory](../../images/evm/evm-memory.jpg)
![EVM Memory](../../images/evm/evm-memory.gif)

Unlike stack, which provides data to individual instructions, memory stores data that is relevant to the entire program.
Unlike stack, which provides data to individual instructions, memory stores ephemeral data that is relevant to the entire program.

### Writing to memory

Expand All @@ -240,7 +242,7 @@ The size of active memory is still 1 word.

### Memory expansion

In EVM, memory is dynamically allocated in multiples of 1 word “pages”. Gas is charged for the number of pages expanded. All locations in memory are well-defined initially as zero.
In EVM, memory is dynamically allocated in multiples of 1 word “pages”. Gas is charged for the number of pages expanded.

![Memory expansion](../../images/evm/memory-expansion.gif)

Expand Down Expand Up @@ -284,7 +286,7 @@ The example above shows only a small section of the account's storage. Like memo

Notice that the storage value persists between examples, demonstrating its persistence within the world state. Since the world state is replicated across all nodes, storage operations are gas expensive.

> ℹ️ Note
> ℹ️ Note
> Check out the wiki on [transaction](/wiki/EL/transaction.md) to see EVM in action.
## Wrapping up
Expand All @@ -295,7 +297,7 @@ Ethereum is a continuously evolving protocol and while the fundamentals we've di

## EVM upgrades

While Ethereum protocol undergoes many changes in each upgrade, changes in EVM are rather subtle. Major change in EVM might break contracts and languages, requiring keeping multiple versions of EVM which introduces a lot of complexity overhead. There are still certain upgrades done on EVM itself like new opcodes or changes to existing ones which don't break their logic. Some examples are EIPs like [1153](https://eips.ethereum.org/EIPS/eip-1153), [4788](https://eips.ethereum.org/EIPS/eip-4788), [5000](https://eips.ethereum.org/EIPS/eip-5000), [5656](https://eips.ethereum.org/EIPS/eip-5656) and [6780](https://eips.ethereum.org/EIPS/eip-6780). These are proposing to add new opcodes except the last one which is especially interesting because it's neutralizing `SELFDESTRUCT` opcode without breaking compatibility. Another important upgrade to EVM which would mark rather a major change is [EOF](https://notes.ethereum.org/@ipsilon/mega-eof-specification). It creates a format to bytecode which EVM can understand and process more easily, it encompasses various EIPs and has been discussed and polished for quite some time.
While Ethereum protocol undergoes many changes in each upgrade, changes in EVM are rather subtle. Major change in EVM might break contracts and languages, requiring keeping multiple versions of EVM which introduces a lot of complexity overhead. There are still certain upgrades done on EVM itself like new opcodes or changes to existing ones which don't break their logic. Some examples are EIPs like [1153](https://eips.ethereum.org/EIPS/eip-1153), [4788](https://eips.ethereum.org/EIPS/eip-4788), [5000](https://eips.ethereum.org/EIPS/eip-5000), [5656](https://eips.ethereum.org/EIPS/eip-5656) and [6780](https://eips.ethereum.org/EIPS/eip-6780). These are proposing to add new opcodes except the last one which is especially interesting because it's neutralizing `SELFDESTRUCT` opcode without breaking compatibility. Another important upgrade to EVM which would mark rather a major change is [EOF](https://notes.ethereum.org/@ipsilon/mega-eof-specification). It creates a format to bytecode which EVM can understand and process more easily, it encompasses various EIPs and has been discussed and polished for quite some time.

## Resources

Expand Down

0 comments on commit 0af3c39

Please sign in to comment.