The contract's long-term storage, a key/value store. Unlike stack and memory, which
reset after computation ends, storage persists for the long term.
The code can also access the value, sender and data of the incoming message, as well as
block header data, and the code can also return a byte array of data as an output.
The formal execution model of EVM code is surprisingly simple. While the Ethereum virtual
machine is running, its full computational state can be defined by the tuple
(block_state, transaction, message, code, memory, stack, pc, gas) ,
where block_state is the global state containing all accounts and includes balances
and storage. At the start of every round of execution, the current instruction is found by
taking the pc -th byte of code (or 0 if pc >= len(code) ), and each instruction has its
own definition in terms of how it affects the tuple. For example, ADD pops two items off
the stack and pushes their sum, reduces gas by 1 and increments pc by 1, and SSTORE
pops the top two items off the stack and inserts the second item into the contract's
storage at the index specified by the first item. Although there are many ways to optimize
Ethereum virtual machine execution via just-in-time compilation, a basic implementation of
Ethereum can be done in a few hundred lines of code.
Blockchain and Mining
The Ethereum blockchain is in many ways similar to the Bitcoin blockchain, although it
does have some differences. The main difference between Ethereum and Bitcoin with
regard to the blockchain architecture is that, unlike Bitcoin(which only contains a copy of
the transaction list), Ethereum blocks contain a copy of both the transaction list and the
most recent state. Aside from that, two other values, the block number and the difficulty,
are also stored in the block. The basic block validation algorithm in Ethereum is as follows:
1. Check if the previous block referenced exists and is valid.
2. Check that the timestamp of the block is greater than that of the referenced previous