Beigepaper:

An Ethereum Technical Specification

Micah Dameron

Abstract

The Ethereum Protocol is a deterministic but practically unbounded state-machine with two basic functions;
the first being a globally accessible singleton state, and the second being a virtual machine that applies changes
to that state. This paper explains the individual parts that make up these two factors.

1. Imagining Bitcoin as a penditures. This is called gas, and is explained fully

in §3. Gas is paid for exclusively in ether. The small-
Computer
est unit of currency in Ethereum is the Wei, which is
Ethereum utilizes the distributed ledger model that equal to Ξ10−18 , where Ξ stands for 1 ether. All cur-
originated with Bitcoin and repurposes it to model a vir- rency transactions in Ethereum, at the machine level,
tual computer, giving machine level opcodes the same are counted in Wei. There is also the Szabo, which is
level of certainty as Bitcoin transactions. Just as sure Ξ10−6 , and the Finney, which is Ξ10−3 .
as you can be certain that Bitcoin’s ledger is accurate The Ethereum network is subservient to others in
and that timestamps are correct through the Bitcoin terms of one thing only: ether, the native currency for
consensus mechanism, just so sure is it that machine Ethereum. Everything the system can do is bounded
instructions initiated on Ethereum will execute. up in its ability to expend ether in exchange for gas,
In other words, programs executed on the which buys a particular amount of system performance
Ethereum Blockchain are basically unstoppable. This in some desired direction.
doesn’t mean that Ethereum programs can’t have
Unit Ether Wei
bugs. This means that Ethereum programs can be
trusted to execute without any interference from exter- Ether Ξ1.000000000000000000 1,000,000,000,000,000,000

nal non-network forces. This property arises from the Finney Ξ0.001000000000000000 1,000,000,000,000,000

inherent security of the blockchain which is built by, and Szabo Ξ0.000001000000000000 1,000,000,000,000

maintained upon, cryptographic proofs. Wei Ξ0.000000000000000001 1

1.1. Native Currency 2. Memory and Storage

Because Ethereum strives not primarily at the currency
2.1. World State
application, but at all applications, there is a fundamen-
tal network cost unit used to mitigate the possibility of The world state is a mapping of Ethereum addresses
abusing the network with excessive computational ex- to accounts. Such a mapping consists of two things:

1
2. Memory and Storage Beigepaper – v0.8.5 2019-08-15

1. addresses 2.2. Tree Terminology1

2. account states
a) Root Node – The top (first) node in a tree.
through the use of the recursive length prefix standard
b) Child Node – A node directly connected to an-
(RLP). This information is stored as a merkle patricia
other node when moving away from the Root.
tree in a database backend.a that maintains a map-
ping of bytearrays to bytearrays.bc As a whole, the state c) Parent Node – The converse notion of a child.
is the sum total of database relationships in the state
d) Sibling Nodes – A group of nodes with the same
database.
parent.

e) Descendant Node – A node reachable by re-

2.1.1. Merkle Patricia Trees
peated proceeding from parent to child.
Merkle patricia trees are modified merkletrees where
f) Ancestor Node – A node reachable by repeated
nodes represent individual characters from hashes
proceeding from child to parent.
rather than each node representing an entire hash.
This allows the state data structure itself to represent g) Leaf Node – A node with no children.
not only the intrinsically correct paths in the data, but
h) Branch Node – A node with at least one child.
also the requisite cryptographic proofs which go into
making sure that a piece of data was valid in the first i) Degree – The number of subtrees of a node.
place. In other words, it keeps the blockchain valid by j) Edge – The connection between one node and
combining the structure of a standard merkletree with another.
the structure of a Radix Tree. Since all searching and
sorting algorithms in Ethereum must be filtered through k) Path – A sequence of nodes and edges connect-
this stringently correct database, accuracy of informa- ing a node with a descendant.
tion is guaranteed. l) Level – The level of a node is defined by 1 + (the
The following is a search tree beginning with hex- number of connections between the node and the
adecimal values a and 4: root).

m) Node Height – The height of a node is the number

a 4 of edges on the longest path between that node
and a leaf.
a
2 6 9
n) Tree Height – The height of a tree is the height of
its root node.
c b 2 7 c
o) Depth – The depth of a node is the number of
7 6 a62 f 9 edges from the tree’s root node to the node.

p) Forest – A forest is a set of n ≥ 0 disjoint trees.

a2c7 a2b6 f 5

497ff 4ac95
a The database backend is accessed by users through an external application, most likely an Ethereum client; see also: state database
bA bytearray is specific set of bytes [data] that can be loaded into memory. It is a structure for storing binary data, e.g. the contents of a file.
c This permanent data structure makes it possible to easily recall any previous state with its root hash keeping the resources off-chain and minimizing

on-chain storage needs.

2
2. Memory and Storage Beigepaper – v0.8.5 2019-08-15

2.2.1. Recursive Length Prefix Encoding 2. Ommers Hash – This is the Keccak-256 hash of
the ommer’s list portion of this block.
Recursive Length Prefix Encoding (RLP) imposes a
structure on data that intrinsically considers a prefixed 3. Beneficiary – This is the 20-byte address to
hex value to position the data in the state database which all block rewards are transferred.
tree. This hex value determines the depth of a cer- 4. State Root – This is the Keccak-256 hash of the
tain piece of data. There are two types of fundamental root node of the state trie, after a block and its
items one can encode in RLP:2 transactions are finalized.

1. Strings of bytes 5. Transactions Root – This is the Keccak-256

hash of the root node of the trie structure popu-
2. Lists of other items
lated with each transaction from a Block’s trans-
RLP encodes arrays of nested binary data to an action list.
arbitrary depth; it is the main serialization method for
6. Receipts Root – This is the Keccak-256 hash of
data in Ethereum. RLP encodes structure of data only,
the root node of the trie structure populated with
so it does not pay heed to the particular types of data
the receipts of each transaction in the transac-
being encoded.
tions list portion of the block.
Positive RLP integers are represented with the
most significant value stored at the lowest memory ad- 7. Logs Bloom – This is the bloom filter composed
dress (big endian) and without any leading zeroes. As from indexable information (log address and log
a result, the RLP integer value for 0 is represented by topic) contained in the receipt for each transac-
an empty byte-array. If a non-empty deserialized inte- tion in the transactions list portion of a block.
ger begins with leading zeroes it is invalid.3 8. Difficulty – This is the difficulty of this block – a
The global state database is encoded as RLP for quantity calculated from the previous block’s diffi-
fast traversal and inspection of data. RLP encoding culty and its timestamp.
creates a mapping between addresses and account
9. Number – This is a quantity equal to the number
states. Since it is stored on node operator’s comput-
of ancestor blocks behind the current block.
ers, the tree can be indexed and searched without net-
work delay. RLP encodes values as byte-arrays, or as 10. Gas Limit – This is a quantity equal to the current
sequences of further values, which are subsequently maximum gas expenditure per block.
encoded as byte-arrays.4 11. Gas Used – This is a quantity equal to the total
gas used in transactions in this block.

2.3. The Block 12. Timestamp – This is a record of Unix’s time at

this block’s inception.
A block is made up of 17 different elements. The first
15 elements are part of what is called the block header. 13. Extra Data – This byte-array of size 32 bytes or
less contains extra data relevant to this block.

2.3.1. The Block Header 14. Mix Hash – This is a 32-byte hash that verifies a
sufficient amount of computation has been done
Description : The information contained in a block on this block.
besides the transactions list. This consists of:
15. Nonce – This is an 8-byte hash that verifies a
1. Parent Hash – This is the Keccak-256 hash of the sufficient amount of computation has been done
parent block’s header. on this block.

3
3. Processing and Computation Beigepaper – v0.8.5 2019-08-15

2.3.2. The Other 2 Block Components 2.3.5. Account State

Ommer Block Headers – These are ommer block The account state contains details of any particular ac-
headers (15 components listed above) of this block. count during some specified world state. The account
state is made up of four variables:
Transaction Series – This is a list of transactions in 1. nonce The number of transactions sent from
this block and the only non-header content in the block. this address, or the number of contract creations
made by the account associated with this ad-
dress.
2.3.3. Block Number and Difficulty 2. balance The amount of Wei owned by this ac-
count. Stored as a key/value pair inside the state
Note that is the difficulty of the genesis block. The database.
Homestead difficulty parameter, is used to affect a dy-
3. storage_root A 256-bit (32-byte) hash of the root
namic homeostasis of time between blocks, as the time
node of a Merkle Patricia Tree that encodes the
between blocks varies, as discussed below, as im-
storage contents of the account.a
plemented in EIP-2. In the Homestead release, the
exponential difficulty symbol, causes the difficulty to 4. code_hash The hash of the EVM code of this
slowly increase (every 100,000 blocks) at an exponen- account’s contract. Code hashes are stored in
tial rate, and thus increasing the block time difference, the state database. Code hashes are permanent
and putting time pressure on transitioning to proof- and they are executed when the address belong-
of-stake. This effect, known as the “difficulty bomb”, ing to that account receives a message call.
or “ice age”, was explained in EIP-649 and delayed
and implemented earlier in EIP-2, was also modified
2.3.6. Bloom Filter
in EIP-100 with the use of x, the adjustment factor, and
the denominator 9, in order to target the mean block The Bloom Filter is composed from indexable informa-
time including uncle blocks. Finally, in the Byzantium tion (logger address and log topics) contained in each
release, with EIP-649, the ice age was delayed by cre- log entry from the receipt of each transaction in the
ating a fake block number, which is obtained by sub- transactions list.
stracting three million from the actual block number,
which in other words reduced the time difference be-
2.3.7. Transaction Receipts
tween blocks, in order to allow more time to develop
proof-of-stake and preventing the network from “freez-
ing” up.4
3. Processing and Computation

3.1. The Transaction

2.3.4. Account Creation The basic method for Ethereum accounts to interact
with each other. The transaction is a single crypto-
Account creation definitively occurs with contract cre- graphically signed instruction sent to the Ethereum net-
ation. Is related to: init. Lastly, there is the body work. There are two types of transactions: message
which is the EVM-code that executes if/when the ac- calls and contract creations. Transactions lie at
count containing it receives a message call. the heart of Ethereum, and are entirely responsible for
aA particular path from root to leaf in the state database

4
3. Processing and Computation Beigepaper – v0.8.5 2019-08-15

the dynamism and flexibility of the platform. Transac- 3.3. Mining

tions are the bread and butter of state transitions, that
The Block Beneficiary is the 160-bit (20-byte) ad-
is of block additions, which contain all of the computa-
dress to which all fees collected from the successful
tion performed in one block. Each transaction applies
mining of a block are transferred. Apply Rewards is
the execution changes to the machine state, a tempo-
the third process in block_finalization that sends
rary state which consists of all the required changes in
the mining reward to an account’s address. This is a
computation that must be made before a block is final-
scalar value corresponding to the difficulty level of a
ized and added to the world state.
current block.

3.1.1. Transactions Root

3.4. Verification
Notation : listhash
The process in The EVM that verifies Ommer Headers.

Alternatively: Transactions Root

3.5. Sender Function
Description : The Keccak-256 hash of the A description that maps transactions to their sender us-
root node that precedes the transactions in the ing ECDSA of the SECP-256k1 curve.
transactions_list section of a Block.

1. Nonce – The number of transactions sent by the 3.6. Serialization/Deserialization

sender.
This function expands a positive-integer value to a big-
2. Gas Price – The number of Wei to pay the net-
endian byte-array of minimal length. When accompa-
work for unit of gas.
nied by a · operator, it signals sequence concatenation.
3. Gas Limit – The maximum amount of gas to be The big_endian function accompanies RLP serializa-
used in while executing a transaction. tion and deserialization.
4. To – The 20-character recipient of a message
call.a 3.7. Ethereum Virtual Machine
5. Value – The number of Wei to be transferred to
The EVM has a simple stack-based architecture. The
the recipient of a message call.b
word size of the machine and thus size of stack is
6. v, r, s – Values for the transaction’s signature from 256-bit. This was chosen to facilitate the Keccak-
which the public key can be derived. 256 hash scheme and elliptic-curve based computa-
tion. The memory model is a simple word-addressed
byte-array. The memory stack has a maximum size of
3.2. State Transition Function
1024-bits. The machine also has an independent stor-
State Transitions come about through the State Transi- age model; this is similar in concept to the memory but
tion Function; this is a high-level abstraction of several rather than a byte array, it is a word-addressable word
operations in Ethereum which comprise the overall act array. Unlike memory, which is volatile, storage is non-
of taking changes from the machine state and adding volatile and is maintained as part of the system state.
them to the world state.
a In the case of a contract creation this is 0x000000000000000000.
b In the case of a contract creation, an endowment to the newly created contract account.

5
3. Processing and Computation Beigepaper – v0.8.5 2019-08-15

All locations in both storage and memory are well- clears an entry in the storage is not only waived, a
defined initially as zero. The machine does not follow qualified refund is given; in fact, this refund is effec-
the standard von Neumann architecture. Rather than tively paid up-front since the initial usage of a storage
storing program code in generally-accessible memory location costs substantially more than normal usage.4
or storage, it is stored separately in a virtual ROM in-
teractable only through specialized instructions.
The machine can have exceptional execution for 3.8. Execution
several reasons, including stack underflows and invalid
instructions. Like the out-of-gas exception, they do The execution of a transaction defines the state tran-
not leave state changes intact. Rather, the machine sition function: stf. However, before any transaction
halts immediately and reports the issue to the execu- can be executed it needs to go through the initial tests
tion agent (either the transaction processor or, recur- of intrinsic validity.
sively, the spawning execution environment) which will
deal with it separately. 3.8.1. Intrinsic Validity

The criteria for intrinsic validity are as follows:

3.7.1. Fees • The transaction follows the rules for well-formed
RLP (recursive length prefix.)
Fees (denominated in gas) are charged under three
• The signature on the transaction is valid.
distinct circumstances, all three as prerequisite to the
execution of an operation.4 The first and most com- • The nonce on the transaction is valid, i.e. it is
mon is the fee intrinsic to the computation of the op- equivalent to the sender account’s current nonce.
eration. Secondly, gas may be deducted in order to • The gas_limit is greater than or equal to the
form the payment for a subordinate message call or intrinsic_gas used by the transaction.
contract creation; this forms part of the payment for the • The sender’s account balance contains the cost
CREATE, CALL and CALLCODE operations. Finally, required in up-front payment.
gas may be paid due to an increase in the usage of the
memory.
3.8.2. Transaction Receipt
Over an account’s execution, the total fee for
memory-usage payable is proportional to smallest mul- While the amount of gas used in the execution and
tiple of 32 bytes that are required such that all memory the accrued log items belonging to the transaction are
indices (whether for read or write) are included in the stored, information concerning the result of a trans-
range. This is paid for on a just-in-time basis; as such, action’s execution is stored in the transaction receipt
referencing an area of memory at least 32 bytes greater tx_receipt. The set of log events which are created
than any previously indexed memory will certainly re- through the execution of the transaction, logs_set in
sult in an additional memory usage fee. Due to this addition to the bloom filter which contains the actual
fee it is highly unlikely that addresses will trend above information from those log events logs_bloom are lo-
32-bit bounds.4 cated in the transaction receipt. In addition, the post-
Implementations must be able to manage this transaction state post_transaction(state) and the
eventuality. Storage fees have a slightly nuanced be- amount of gas used in the block containing the trans-
haviour to incentivize minimization of the use of storage action receipt post(gas_used) are stored in the trans-
(which corresponds directly to a larger state database action receipt. As a result, the transaction receipt is a
on all nodes), the execution fee for an operation that record of any given execution.

6
3. Processing and Computation Beigepaper – v0.8.5 2019-08-15

A valid transaction execution begins with a per- of a computer. This is actually an instantial runtime
manent change to the state: the nonce of the sender that executes several substates, as EVM computation
account is increased by one and the balance is de- instances, before adding the finished result, all calcu-
creased by the collateral_gasa which is the amount lations having been completed, to the final state via the
of gas a transaction is required to pay prior to its execu- finalization function.
tion. The original transactor will differ from the sender In addition to the system state and the
if the message call or contract creation comes from a remaining gas for computation there are several
contract account executing code. pieces of important information used in the execution
After a transaction is executed, there comes a environment that the execution agent must provide:
provisional state, which is a pre-final state. Gas
used for the execution of individual EVM opcodes prior
• account_address, the address of the account
to their potential addition to the world_state creates:
which owns the code that is executing.
• Provisional state. • sender_address the sender address of the trans-
• intrinsic gas, and action that originated this execution.
• an associated substate. • originator_price the price of gas in the trans-
• The accounts tagged for self-destruction action that originated this execution.
following the transaction’s completion. • input_data, a byte array that is the input data to
self_destruct(accounts) this execution; if the execution agent is a transac-
• The logs_series, which creates checkpoints in tion, this would be the transaction data.
EVM code execution for frontend applications to • account_address the address of the account
explore, and is made up of thelogs_set and which caused the code to be executing; if the ex-
logs_bloom from the tx_receipt. ecution agent is a transaction, this would be the
• The refund balance.b transaction sender.
Code execution always depletes gas. If gas runs • newstate_value the value, in Wei, passed to this
out, an out-of-gas error is signaled (oog) and the result- account if the execution agent is a transaction,
ing state defines itself as an empty set; it has no effect this would be the transaction value.4
on the world state. This describes the transactional na-
• code array the byte array that is the machine
ture of Ethereum. In order to affect the world state,
code to be executed.4
a transaction must go through completely or not at all.
• block_header the block header of the present
block.
3.8.3. Code Deposit
• stack_depth the depth of the present message-
If the initialization code completes successfully, a final call or contract-creation (i.e. the number of CALLs
contract-creation cost is paid, the code-deposit cost, c, or CREATEs being executed at present).4
proportional to the size of the created contract’s code.
The execution model defines the state_transition
function, which can compute the resultant
3.8.4. Execution Model
state, the remaining_gas, the accrued_substate
Basics : The stack-based virtual machine which lies and the resultant_output, given these defini-
at the heart of the Ethereum and performs the actions tions. For the present context, we will define it
a Designated “intrinsic_gas” in the Yellowpaper
b The sstore operation increases the amount refunded by resetting contract storage to zero from some non-zero state.

7
3. Processing and Computation Beigepaper – v0.8.5 2019-08-15

where the accrued substate is defined as the tu- of two instructions, which evaluates to the according
ple of the self-destructs_set, the log_series, the value: otherwise In general, we assume the memory,
touched_accounts and the refunds.4 self-destruct set and system state don’t change: how-
ever, instructions do typically alter one or several com-
3.8.5. Execution Overview ponents of these values.

The execution_function, in most practical implemen-

Provisional State A smaller, temporary state that is
tations, will be modeled as an iterative progres-
generated during transaction execution. It contains
sion of the pair comprising the full system_state
three sets of data.a
and the machine_state. It’s defined recursively with
the iterator_function, which defines the result of
a single cycle of the state machine, together with 3.8.7. Message Calls
the halting_check function, which determines if the
A message call can come from a transaction or in-
present state is an exceptional halting state of the ma-
ternally from contract code execution. It contains the
chine and output_data of the instruction if the present
field data, which consists of user data input to a mes-
state is a controlled_halt of the machine. An empty
sage call. Messages allow communication between
sequence/series indicates that execution should halt,
accounts (whether contract or external.) Messages
while the empty set indicates that execution should
can come in the form of msg_calls which give out-
continue.
put data. If it is a contract account, this code gets
When evaluating execution, we extract the remain-
executed when the account receives a message call.
ing gas from the resultant machine state. It is thus
Message calls and contract creations are both transac-
cycled (recursively or with an iterative loop) until ei-
tions, but contract creations are never considered the
ther exceptional_halt becomes true indicating that
same as message calls. Message calls always trans-
the present state is exceptional and that the machine
fer some amount of value to another account. If the
must be halted and any changes discarded or until H
message call is an account creation transaction then
becomes a series (rather than the empty set) indicating
the value given takes on the role of an endowment
that the machine has reached a controlled halt.
towards the new account. Every time an account re-
The machine state is defined as the tuple which
ceives a message call it returns the body, something
are the gas available, the program counter, the
which is triggered by the init function. User data in-
memory contents, the active number of words in
put to a message_call, structured as an unlimited size
memory (counting continuously from position 0), and
byte-array.
the stack contents. The memory contents are a se-
ries of zeroes of size 2256 .4
Universal Gas Message calls always have a uni-
versally agreed-upon cost in gas. There is a strong
3.8.6. The Execution Cycle
distinction between contract creation transactions and
Stack items are added or removed from the left-most, message call transactions. Computation performed,
lower-indexed portion of the series; all other items re- whether it is a contract creation or a message call, rep-
main unchanged: The gas is reduced by the instruc- resents the currently legal valid state. There can be
tion’s gas cost and for most instructions, the program no invalid transactions from this point.4 There is also a
counter increments on each cycle, for the three ex- message call/contract creation stack. This stack has
ceptions, we assume a function J, subscripted by one a depth, depending on how many transactions are in
a The final state is reached after deleting all accounts that either appear in the self-destruct list or are touched and empty.

8
3. Processing and Computation Beigepaper – v0.8.5 2019-08-15

it. Contract creations and message calls have entirely 3.9. Gas
different ways of executing, and are entirely different
Gas is the fundamental network cost unit converted to
in their roles in Ethereum. The concepts can be con-
and from ether as needed to complete the transaction
flated. Message calls can result in computation that
while it is sent. Gas is arbitrarily determined at the mo-
occurs in the next state rather than the current one. If
ment it is needed, by the block and according to the
an account that is currently executing receives a mes-
total network’s miners decision to charge certain fees.
sage call, no code will execute, because the account
Each miner choose individually which gas prices they
might exist but has no code in it yet. To execute a mes-
want to accept and which they want to reject.
sage call transactions are required:

• sender 3.9.1. Gas Price/Gas Limit

• transaction originator
Gas price is a value equal to the current limit of gas
• recipient expenditure per block, according to the miners. Any
• account (usually the same as the recipient) unused gas is refunded to the sender. The canonical
gas limit of a block is expressed and is stabilized by the
• available gas
time_stamp of the block.
• value
• gas price Gas Price Stability Where new_header is the new
• An arbitrary length byte-array. arb array block’s header, but without the nonce and mix-hash
components, d being the current DAG, a large data
• present depth of the message call/contract cre-
set needed to compute the mix-hash, and PoW is the
ation stack.
proof-of-work function this evaluates to an array with
the first item being the mix-hash, to prove that a cor-
3.8.8. Contract Creation rect DAG has been used, and the second item being a
pseudo-random number cryptographically dependent
To initiate contract creation you need to send transac-
on it. Given an approximately uniform distribution in
tion to nothing. This executes init and returns the
the range the expected time to find a solution is pro-
body. Init is executed only once at account_cre-
portional to the difficulty.4
ation, and permanently discarded after that.
This is the foundation of the security of the
blockchain and is the fundamental reason why a mali-
3.8.9. Execution Environment cious node cannot propagate newly created blocks that
would otherwise overwrite (“rewrite”) history. Because
The Ethereum Runtime Environment is the environ-
the nonce must satisfy this requirement, and because
ment under which Autonomous Objects execute in the
its satisfaction depends on the contents of the block
EVM: the EVM runs as a part of this environment.
and in turn its composed transactions, creating new,
valid, blocks is difficult and, over time, requires approx-
3.8.10. Big Endian Function
imately the total compute power of the trustworthy por-
This function expands a positive-integer value to a big- tion of the mining peers. Thus we are able to define
endian byte array of minimal length. When accompa- the block header validity function.
nied by a · operator, it signals sequence concatenation.
The big_endian function accompanies RLP serializa- Gasused A value equal to the total gas used in trans-
tion and deserialization. actions in this block.

9
3. Processing and Computation Beigepaper – v0.8.5 2019-08-15

3.9.2. Machine State – false indicating in the run of computation, no

exceptions were signaled. If this value re-
The machine state is a tuple consisting of five ele-
mains false for the duration of the execution
ments:
until the set of transactions becomes a series
1. gas_available (rather than an empty set.) This means that
2. program_counter the machine has reached a controlled halt.

3. memory_contents A series of zeroes of size 2256

4. memory_words.count Substate A smaller, temporary state that is gener-
ated during transaction execution and runs parallel to
5. stack_contents
machine state. It contains three sets of data:
There is also, [to_execute]: the current operation
• The accounts tagged for self-destruction
to be executed
following the transaction’s completion.
self_destruct(accounts)
3.9.3. Exceptional Halting
• The logs_series, which creates checkpoints in
An exceptional halt may be caused by four conditions EVM code execution for frontend applications to
existing on the stack with regard to the next opcode in explore, and is made up of thelogs_set and l
line for execution: ogs_bloom from the tx_receipt.
• The refund balance.a
if
out_of_gas = true
or 3.9.4. EVM Code
bad_instruction = true
The bytecode that the EVM can natively execute. Used
or
to explicitly specify the meaning of a message to an ac-
bad_stack_size = true
count. A contract is a piece of EVM Code that may
or
be associated with an Account or an Autonomous Ob-
bad_jumpdest = true
ject. EVM Assembly is the human readable version of
then throw exception
EVM Code.
else exec opcode x
then init control_halt
3.10. Blocktree to Blockchain
Exceptional halts are reserved for opcodes that fail
to execute. They can never be caused through an op- The canonical blockchain is a path from root to leaf
code’s actual execution. through the entire block tree. In order to have consen-
sus over which path it is, conceptually we identify the
• The amount of remaining gas in each transac-
path that has had the most computation done upon
tion is extracted from information contained in the
it, or, the heaviest path. Clearly one factor that helps
machine_state
determine the heaviest path is the block number of the
• A simple iterative recursive loop4 with a Boolean leaf, equivalent to the number of blocks, not counting
value: the unmined genesis block, in the path. The longer
– true indicating that in the run of computation, the path, the greater the total mining effort that must
an exception was signaled have been done in order to arrive at the leaf. This is
a The sstore operation increases the amount refunded by resetting contract storage to zero from some non-zero state.

10
3. Processing and Computation Beigepaper – v0.8.5 2019-08-15

akin to existing schemes, such as that employed in or an ommer with the same beneficiary address as the
Bitcoin-derived protocols. Since a block header in- present block,
cludes the difficulty, the header alone is enough to additions are applied cumulatively. The block re-
validate the computation done. Any block contributes ward is three ether per block.
toward the total computation or total difficulty of a chain.
Thus we define the total difficulty of this_block re- State & Nonce Validation The function that maps a
cursively by the difficulty of its parent block and the block B to its initiation state, that is, the hash of the
block itself. The jobs of miners and validators are root node of a trie of state x. This value is stored in
as follows: Validate (or, if mining, determine) the state database trivial and efficient since the trie is
ommers; validate (or, if mining, determine) by nature a resilient data structure. And finally define
transactions; apply rewards; verify (or, if the block_transition_function, which maps an in-
mining, compute a valid) state and nonce. complete block to a complete block with a specified
dataset. As specified at the beginning of the present
work, the state_transition_function, which is de-
3.11. Ommer Validation
fined in terms of, the block_finalisation_function
The validation of ommer headers means nothing more and, the transaction_evaluation_function. As pre-
than verifying that each ommer header is both a valid viously detailed, there is the nth corresponding status
header and satisfies the relation of Nth-generation om- code, logs and cumulative gas used after each trans-
mer to the present block. The maximum of ommer action, the fourth component in the tuple, has already
headers is two. been defined in terms of the logs).

The nth state is given from applying the correspond-

3.12. Transaction Validation ing transaction to the state resulting from the previous
transaction (or the block’s initial state in the case of the
The given gasUsed must correspond faithfully to the
first BYZANTIUM VERSION 3475aa8 – 2018-01-26 14
transactions listed, the total gas used in the block, must
such transaction): otherwise in certain cases there is
be equal to the accumulated gas used according to the
a similar approach defining each item as the gas used
final transaction.
in evaluating the corresponding transaction summed
with the previous item (or zero, if it is the first), giv-
ing us a running total: the function is used that was
3.13. Reward Application
defined in the transaction execution function. Finally
The application of rewards to a block involves rais- new state exists in the context of the block reward
ing the balance of the accounts of the beneficiary function applied to the final transaction’s resultant
address of the block and each ommer by a certain state, thus the complete block-transition mechanism,
amount. We raise the block’s beneficiary account; for less PoW, the proof-of-work function is defined.
each ommer, we raise the block’s beneficiary by 1 an
additional 32 of the block reward and the beneficiary
3.14. Mining Proof-of-Work
of the ommer gets rewarded depending on the block
number. This constitutes the block_finalization Proof that a certain amount of mining has been done
state_transition_function. If there are collisions exists as a cryptographic probability statement which
of the beneficiary addresses between ommers and the asserts beyond reasonable doubt that a particular
block two ommers with the same beneficiary address amount of computation has been expended in the

11
3. Processing and Computation Beigepaper – v0.8.5 2019-08-15

determination of some token value pow_token. It is which can be computed for each block by scanning
utilised to enforce the security of the blockchain. Since through the block headers up until that point. From the
mined blocks produce a reward, the proof-of-work also seed, one can compute a pseudorandom cache, that
serves as a wealth distribution mechanism. For this is cache_init bytes in initial size. Light clients store
reason, the proof of work function is designed to be as the cache. From the cache, a dataset is generated,
accessible as possible to as many people as possible. dataset_size bytes in initial size, with the property
that each item in the dataset depends on only a small
A very basic application of this principle of acces- number of items from the cache. Full clients and min-
sibility is found in combining the traditional Proof-of- ers store the dataset. The dataset grows linearly with
Work function with a Memory-Hardness function. By time. Mining involves grabbing random slices of the
forcing the hashing algorithm to use memory as well dataset and hashing them together. Verification can
as CPU, miners are more likely to use computers than be done with low memory by using the cache to regen-
ASICs, meaning that ASIC efficiency will not obsolete erate the specific pieces of the dataset that you need,
the person who wants to mine on their home com- so you only need to store the cache. The large dataset
puter from participating in the mining process. To is updated once every 1 epoch (10,000) blocks, so the
make the Ethereum Blockchain ASIC resistant, the vast majority of a miner’s effort is spent on reading the
Proof-of-Work mechanism has been designed to be dataset, rather than on making changes to it.
sequential and memory-hard. This means that the
nonce requires high amounts of memory and band-
3.14.2. Difficulty Mechanism
width such that the memory cannot be used in paral-
lel to discover multiple nonces simultaneously. There- This mechanism enforces a relative predictability in
fore, the proof-of-work function takes the form of 2256 terms of the time-window between blocks; a smaller
the new block’s header but without the nonce and mix- period between the last two blocks results in an in-
hash components. There is the header_nonce, and crease in the difficulty level and thus additional com-
data_set which are required to compute the mix hash putation required, lengthening the next time-window.
and block_difficulty, the difficulty value of the new Conversely, if the time-window is too large, the
block. The proof-of-work function evaluates to an array difficulty is reduced, reducing the amount of time
with the first item being the mix hash and the second to the next block. The total_difficultya is the
item being a pseudorandom number which is crypto- difficulty_state of the entire Ethereum blockchain.
graphically dependent on the header_nonce and the The block_difficulty, in contrast, is not a state of
data_set. The name for this algorithm is Ethash. the blockchain, but is local–particular to each specific
block. You reach the total difficulty by summing the in-
dividual difficulty of all previous blocks and then adding
3.14.1. Ethash: Seed→Cache→Dataset→Slice
the difficulty of the present block.
Ethash is the Proof-of-Work algorithm which was used The GHOST Protocol provides an alternative so-
to launch the Ethereum network and bring it through its lution to double-spend attacks from the original solution
first few releases. It is in the process of being gradually in Satoshi Nakamoto’s Bitcoin Whitepaper. Nakamoto
phased out and replaced with a Proof-of-Stake model. solved the problem of double-spending by requiring the
For now it is the latest version of Dagger-Hashimoto, network to agree on a single block in order to function.
introduced by Vitalik Buterin. The general route that For that reason, in the Bitcoin protocol, it’s impossi-
the algorithm takes is as follows: There exists a seed ble to submit a “double-spend” block without having at
a Alternatively known as total_computation

12
3. Processing and Computation Beigepaper – v0.8.5 2019-08-15

least 50% of the network’s mining power to force the state data. This would be a variation on a compres-
longest chain. This is because the network automati- sion scheme.4
cally chooses the longest chain. So even if one wanted
to submit two spend transactions in a row, the network
3.17. Scalability
simply picks whichever one comes first, ignoring the
second because it no longer pertains to the longest Scalability is a constant concern. Because Ethereum’s
chain (which now contains the first block that was sent) state transitions are so broad in terms of possible con-
so the would-be hacker needs to submit a new block, tent, and because its applications and use-cases are
as the first double block is no longer feasible. so numerous in the number of potential transactions re-
The “GHOST Protocol” (which stands for Greedy quired, scalability is inherently necessary for increased
Heaviest Object subTree) rather requires that miners transaction throughput and for more efficient storage
begin mining whichever chain the most other miners and traversal of the chain.
are on. Because of differences in network propagation
of data about which miners are mining which block, this 3.17.1. Sharding
has a tendency to create more uncles. Nevertheless,
Parallelization of transaction combination and block
in spite of the increased amount of uncle blocks, the
building.
chain itself is equally secure, and this method allows
for higher throughput of transactions than Satoshi’s so-
3.17.2. Casper
lution to double-spending does.
3.17.3. Plasma

3.15. Pseudorandom Numbers

Pseudo-random numbers may be generated by utiliz-
ing data which is generally unknowable at the time
of transacting. This constitutes anything based off
of factors which are unknowable under regular cir-
cumstances, but become knowable through the reg-
ular operation and growth of the chain. Such data
might include a current (or relatively current) block’s
hash, timestamp, or beneficiary address. The block-
hash opcode uses the previous 256 blocks as pseudo-
random numbers. One could further automate this ran-
domness by adding two blockhash operations and
hashing the result.

3.16. Chainsize Limits

The state database usually won’t store every single
tree structure in the history of the blockchain. One idea
has been proposed to simply maintain node check-
points for each age (10,000 blocks) and eventually dis-
card checkpoints which no longer contain necessary

13
A. EVM Opcodes5 Beigepaper – v0.8.5 2019-08-15

A. EVM Opcodes5

A.1. 0x10’s: Comparisons and Bitwise Logic Operations

Data Opcode Gas Input Output Description

0x00 STOP 0 0 0 Halts execution.
0x01 ADD 3 2 1 Addition operation.
0x02 MUL 5 2 1 Multiplication operation.
0x03 SUB 3 2 1 Subtraction operation.
0x04 DIV 5 2 1 Integer division operation.
0x05 SDIV 5 2 1 Signed integer division operation (trun-
cated.)
0x06 MOD 5 2 1 Modulo remainder operation.
0x07 SMOD 5 2 1 Signed modulo remainder operation.
0x08 ADDMOD 8 3 1 Modulo addition operation.
0x09 MULMOD 8 3 1 Modulo multiplication operation.
0x0a EXP 10 2 1 Exponential operation.
0x0b SIGNEXTEND 5 2 1 Extend the length of two’s complemen-
tary signed integer.
0x10 LT 3 2 1 Less-than comparison.
0x11 GT 3 2 1 Greater-than comparison.
0x12 SLT 3 2 1 Signed less-than comparison.
0x13 SGT 3 2 1 Signed greater-than comparison.
0x14 EQ 3 2 1 Equality comparison.
0x15 ISZERO 3 1 1 Simple not operator.
0x16 AND 3 2 1 Bitwise and operation.
0x17 OR 3 2 1 Bitwise or operation.
0x18 XOR 3 2 1 Bitwise xor operation.
0x19 NOT 3 1 1 Bitwise not operation.
0x1a BYTE 3 2 1 Retrieve single byte from word.

A.2. 0x20’s: SHA3

Data Opcode Gas Input Output Description

0x20 SHA3 30 2 1 Compute a Keccak-256 hash.

A.3. 0x30’s: Environmental Information

Data Opcode Gas Input Output Description

0x30 ADDRESS 2 0 1 Get the address of the currently execut-
ing account.

14
A. EVM Opcodes5 Beigepaper – v0.8.5 2019-08-15

0x31 BALANCE 400 1 1 Get the balance of the given account.

0x32 ORIGIN 2 0 1 Get execution origination address. This
is always the original sender of a trans-
action, never a contract account.
0x33 CALLER 2 0 1 Get caller address. This is the address
of the account that is directly responsi-
ble for this execution.
0x34 CALLVALUE 2 0 1 Get deposited value by the instruction/-
transaction responsible for this execu-
tion.
0x35 CALLDATALOAD 3 1 1 Get input data of the current environ-
ment.
0x36 CALLDATASIZE 2 0 1 Get size of input data in current en-
vironment. This refers to the optional
data field that can be passed with a
message call instruction or transaction.
0x37 CALLDATACOPY 3 3 0 Copy input data in the current environ-
ment to memory. This refers to the op-
tional data field passed with the mes-
sage call instruction or transaction.
0x38 CODESIZE 2 0 1 Get size of code running in the current
environment.
0x39 CODECOPY 3 3 0 Copy the code running in the current
environment to memory.
0x3a GASPRICE 2 0 1 Get the price of gas in the current envi-
ronment. This is the gas price specified
by the originating transaction.
0x3b EXTCODESIZE 700 1 1 Get the size of an account’s code.
0x3c EXTCODECOPY 700 4 0 Copy an account’s code to memory.
0x3d RETURNDATA- 2 0 1
SIZE
0x3e RETURNDATA- 3 3 0
COPY

A.4. 0x40’s: Block Data

Data Opcode Gas Input Output Description

0x40 BLOCKHASH 20 1 1 Get the hash of one of the 256 most re-
cent blocks. a
0x41 COINBASE 2 0 1 Look up a block’s beneficiary address
by its hash.
aA value of 0 is left on the stack if the block number is more than 256 in number behind the current one, or if it is a number greater than the current one.

15
A. EVM Opcodes5 Beigepaper – v0.8.5 2019-08-15

0x42 TIMESTAMP 2 0 1 Look up a block’s timestamp by its

hash.
0x43 NUMBER 2 0 1 Look up a block’s number by its hash.
0x44 DIFFICULTY 2 0 1 Look up a block’s difficulty by its hash.
0x45 GASLIMIT 2 0 1 Look up a block’s gas limit by its hash.

A.5. 0x50’s: Stack, memory, storage, and flow operations.

Data Opcode Gas Input Output Description

0x50 POP 2 1 0 Removes an item from the stack.
0x51 MLOAD 3 1 1 Load a word from memory.
0x52 MSTORE 3 2 0 Save a word to memory.
0x53 MSTORE8 3 2 0 Save a byte to memory.
0x54 SLOAD 200 1 1 Load a word from storage.
0x55 SSTORE 5,000 – 20,000 2 0 Save a word to storage.
0x56 JUMP 8 1 0 Alter the program counter.
0x57 JUMPI 10 2 0 Conditionally alter the program counter.
0x58 PC 2 0 1 Look up the value of the program
counter prior to the increment resulting
from this instruction.
0x59 MSIZE 2 0 1 Get the size of active memory in bytes.
0x5a GAS 2 0 1 Get the amount of available gas, includ-
ing the corresponding reduction for the
cost of this instruction.
0x5b JUMPDEST 1 0 0 Mark a valid destination for jumps. a

A.6. 0x60-70’s: Push Operations

Data Opcode Gas Input Output Description

0x60 PUSH1 - 0 1 Place a 1-byte item on the stack.
0x61 PUSH2 - 0 1 Place a 2-byte item on the stack.
0x62 PUSH3 - 0 1 Place a 3-byte item on the stack.
0x63 PUSH4 - 0 1 Place a 4-byte item on the stack.
0x64 PUSH5 - 0 1 Place a 5-byte item on the stack.
0x65 PUSH6 - 0 1 Place a 6-byte item on the stack.
0x66 PUSH7 - 0 1 Place a 7-byte item on the stack.
0x67 PUSH8 - 0 1 Place a 8-byte item on the stack.
0x68 PUSH9 - 0 1 Place a 9-byte item on the stack.
0x69 PUSH10 - 0 1 Place a 10-byte item on the stack.
0x6a PUSH11 - 0 1 Place a 11-byte item on the stack.
a This operation has no effect on the machine_state during execution.

16
A. EVM Opcodes5 Beigepaper – v0.8.5 2019-08-15

0x6b PUSH12 - 0 1 Place a 12-byte item on the stack.

0x6c PUSH13 - 0 1 Place a 13-byte item on the stack.
0x6d PUSH14 - 0 1 Place a 14-byte item on the stack.
0x6e PUSH15 - 0 1 Place a 15-byte item on the stack.
0x6f PUSH16 - 0 1 Place a 16-byte item on the stack.
0x70 PUSH17 - 0 1 Place a 17-byte item on the stack.
0x71 PUSH18 - 0 1 Place a 18-byte item on the stack.
0x72 PUSH19 - 0 1 Place a 19-byte item on the stack.
0x73 PUSH20 - 0 1 Place a 20-byte item on the stack.
0x74 PUSH21 - 0 1 Place a 21-byte item on the stack.
0x75 PUSH22 - 0 1 Place a 22-byte item on the stack.
0x76 PUSH23 - 0 1 Place a 23-byte item on the stack.
0x77 PUSH24 - 0 1 Place a 24-byte item on the stack.
0x78 PUSH25 - 0 1 Place a 25-byte item on the stack.
0x79 PUSH26 - 0 1 Place a 26-byte item on the stack.
0x7a PUSH27 - 0 1 Place a 27-byte item on the stack.
0x7b PUSH28 - 0 1 Place a 28-byte item on the stack.
0x7c PUSH29 - 0 1 Place a 29-byte item on the stack.
0x7d PUSH30 - 0 1 Place a 30-byte item on the stack.
0x7e PUSH31 - 0 1 Place a 31-byte item on the stack.
0x7f PUSH32 - 0 1 Place a 32-byte item on the stack.

A.7. 0x80’s: Duplication Operations

Data Opcode Gas Input Output Description

0x80 DUP1 - 1 2 Duplicate the 1st item in the stack.
0x81 DUP2 - 2 3 Duplicate the 2nd item in the stack.
0x82 DUP3 - 3 4 Duplicate the 3rd item in the stack.
0x83 DUP4 - 4 5 Duplicate the 4th item in the stack.
0x84 DUP5 - 5 6 Duplicate the 5th item in the stack.
0x85 DUP6 - 6 7 Duplicate the 6th item in the stack.
0x86 DUP7 - 7 8 Duplicate the 7th item in the stack.
0x87 DUP8 - 8 9 Duplicate the 8th item in the stack.
0x88 DUP9 - 9 10 Duplicate the 9th item in the stack.
0x89 DUP10 - 10 11 Duplicate the 10th item in the stack.
0x8a DUP11 - 11 12 Duplicate the 11th item in the stack.
0x8b DUP12 - 12 13 Duplicate the 12th item in the stack.
0x8c DUP13 - 13 14 Duplicate the 13th item in the stack.
0x8d DUP14 - 14 15 Duplicate the 14th item in the stack.
0x8e DUP15 - 15 16 Duplicate the 15th item in the stack.
0x8f DUP16 - 16 17 Duplicate the 16th item in the stack.

17
A. EVM Opcodes5 Beigepaper – v0.8.5 2019-08-15

A.8. 0x90’s: Swap Operations

Data Opcode Gas Input Output Description

0x90 SWAP1 - 2 2 Exchange the 1st and 2nd stack items.
0x91 SWAP2 - 3 3 Exchange the 1st and 3rd stack items.
0x92 SWAP3 - 4 4 Exchange the 1st and 4th stack items.
0x93 SWAP4 - 5 5 Exchange the 1st and 5th stack items.
0x94 SWAP5 - 6 6 Exchange the 1st and 6th stack items.
0x95 SWAP6 - 7 7 Exchange the 1st and 7th stack items.
0x96 SWAP7 - 8 8 Exchange the 1st and 8th stack items.
0x97 SWAP8 - 9 9 Exchange the 1st and 9th stack items.
0x98 SWAP9 - 10 10 Exchange the 1st and 10th stack items.
0x99 SWAP10 - 11 11 Exchange the 1st and 11th stack items.
0x9a SWAP11 - 12 12 Exchange the 1st and 12th stack items.
0x9b SWAP12 - 13 13 Exchange the 1st and 13th stack items.
0x9c SWAP13 - 14 14 Exchange the 1st and 14th stack items.
0x9d SWAP14 - 15 15 Exchange the 1st and 15th stack items.
0x9e SWAP15 - 16 16 Exchange the 1st and 16th stack items.
0x9f SWAP16 - 17 17 Exchange the 1st and 17th stack items.

A.9. 0xa0’s: Logging Operations

Data Opcode Gas Input Output Description

0xa0 LOG0 375 2 0 Append log record with 0 topics.
0xa1 LOG1 750 3 0 Append log record with 1 topic.
0xa2 LOG2 1125 4 0 Append log record with 2 topic.
0xa3 LOG3 1500 5 0 Append log record with 3 topic.
0xa4 LOG4 1875 6 0 Append log record with 4 topic.

A.10. 0xf0’s: System Operations

Data Opcode Gas Input Output Description

0xf0 CREATE 32000 3 1 Create a new contract account.
Operand order is: value, input offset,
input size.
0xf1 CALL 700 7 1 Message-call into an account. The
operand order is: gas, to, value, in off-
set, in size, out offset, out size.

18
A. EVM Opcodes5 Beigepaper – v0.8.5 2019-08-15

0xf2 CALLCODE 700 7 1 Message-call into this account with an

alternative account’s code. Exactly
equivalent to CALL, except the recipi-
ent is the same account as at present,
but the code is overwritten.
0xf3 RETURN 0 2 0 Halt execution, then return output data.
This defines the output at the moment
of the halt.
0xf4 DELEGATECALL 700 6 1 Message-call into this account with an
alternative account’s code, but with per-
sisting values for sender and value.
DELEGATECALL takes one less argu-
ment than CALL. This means that the
recipient is in fact the same account as
at present, but that the code is overwrit-
ten and the context is almost entirely
identical.
0xfa STATICCALL 40 6 1 -
0xfd REVERT 0 2 0 -
0xfe INVALID - 1 0 Designated invalid instruction.
0xff SELFDESTRUCT 5000 1 0 Halt execution and register the account
for later deletion.

19
A. References Beigepaper – v0.8.5 2019-08-15

References
[1] W. contributors, Tree (data structure) — wikipedia,
the free encyclopedia, [Online; accessed
15-December-2017], 2017. [Online]. Available:
https : / / en . wikipedia . org / w / index . php ?
title = Tree _ (data _ structure ) %5C & oldid =
813972413 (cit. on p. 2).

[2] E. Foundation, Pyrlp tutorial, 2015. [Online]. Avail-

able: https://github.com/jnnk/pyrlp/blob/
master/docs/tutorial.rst (cit. on p. 3).

[3] ——, Ethereum whitepaper, https : / / github .

com/ethereum/wiki/wiki/White-Paper, 2017
(cit. on p. 3).

[4] D. G. Wood, Ethereum: A secure decentralised

generalised transaction ledger, https://github.
com/ethereum/yellowpaper, 2017 (cit. on pp. 3,
4, 6–10, 13).

[5] V. Buterin, Pyethereum source, https : / / www .

github.com/ethereum/pyethereum/ethereum/
opcodes.py, 2017 (cit. on pp. 14–19).

20
Glossary Beigepaper – v0.8.5 2019-08-15

Gas The fundamental network cost unit; gas is paid

for exclusively by ether. 21

Message Data (as a set of bytes) and Value (specified

Glossary in Wei) that is passed between two accounts. 21

account state The state of a particular account–a serialization Serialization is the process of converting
section of the total world state. Comprises: the an object into a stream of bytes in order to store
nonce, balance, storage root, and code hash the object or transmit it to memory, a database,
of the account. 21 or a file. Its main purpose is to save the machine
addresses 20 character strings, specifically the right- state of an object in order to be able to recreate it
most 20 characters of the Keccak-256 hash of when needed. 21
the RLP-derived mapping which contains the state machine The term State Machine is reserved
sender’s address and the nonce of the block. 21 for any simple or complex process that moves de-
terministically from one discrete state to the next.
beneficiary The 20-character (160-bit) address to 21
which all fees collected from the successful min- state database A database stored off-chain, [i.e. on
ing of a block are transferred. 21 the computer of some user running an Ethereum
block header All the information in a block besides client] which contains a radix tree mapping bytear-
transaction information. 21 rays (organized chunks of binary data) to other
bytearrays. The relationships between each node
Contract A piece of EVM Code that may be associ- on this trie constitutes a mapping of Ethereum’s
ated with an Account or an Autonomous Object. state. 1, 4, 13, 21
21
storage root One aspect of an account’s state: this
Cryptographic hashing functions Hash functions is the hash of the triea that decides the storage
make secure blockchains possible by establish- contents of the account. 21
ing universal inputs for which there are limited,
Storage State The information particular to a given
usually only one, possible output yet that output
account that is maintained between the times that
is unique. 21
the account’s associated EVM Code runs. 21
Ethereum Runtime Environment The environment
transaction A piece of data, signed by an External Ac-
which is provided to an Autonomous Object ex-
tor. It represents either a Message or a new Au-
ecuting in the EVM. Includes the EVM but also
tonomous Object. Transactions are recorded into
the structure of the world state on which the re-
each block of the blockchain. 21
lies for certain I/O instructions including CALL &
CREATE. 21
EVM Assembly The human readable version of EVM Acronyms
code. 21
ERE Ethereum Runtime Environment. 21
EVM Code The bytecode that the EVM can natively
execute. Used to formally specify the meaning EVM Ethereum Virtual Machine. 21
and ramifications of a message to an Account. 21
RLP Recursive Length Prefix. 21
aA particular path from root to leaf in the state database

21
A. Index Beigepaper – v0.8.5 2019-08-15

Index
160 bit, 5 block header, 3, 7
256 bit, 4, 5 block header validity function, 9
50% attack, 13 block number, 4, 11
block reward, 5, 11
abstract state-machine, 1 block reward function, 11
account, 9 block rewards, 3
account address, 7 BLOCKHASH, 13
account addresses, 2 body, 9
account balance, 4 branch node, 2
account body, 4 byte array, 5
account code hash, 4 byzantium, 4
account creation, 4, 9
account init, 4 cache, 12
account nonce, 4 canonical blockchain, 11
account state, 4 canonical gas, 9
account states, 2 casper, 13
account storage root, 4 certainty, 1
accrued substate, 8 checkpoint nodes, 13
accumulated gas used, 11 checkpoints, 10
age, 13 child node, 2
ancestor node, 2 code array, 7
apply rewards, 5, 11 collisions, 11
arbitrarily determined, 9 complete block, 11
arbitrary length byte-array, 9 computation, 9
asic resistant, 12 computation of operation, 6
autonomous objects, 9 compute valid nonce, 11
available gas, 9 compute valid state, 11
contract creation, 4, 9
balance, 1 contract creation stack, 9
beneficiary, 3 contract creation transactions, 9
beneficiary address, 11 controlled halt, 10
big endian, 3 correct DAG, 9
big endian function, 9 cumulative difficulty, 12
Bitcoin, 1 cumulative gas, 11
Bitcoin Whitepaper, 13
block, 9 DAG, 9
block beneficiary, 5 data structure, 2
block composition, 3 dataset, 12
block contents, 9 dataset slice, 13
block difficulty, 12 descendant node, 2
block finalization state transition function, 11 deserialization, 5, 9

22
Index Beigepaper – v0.8.5 2019-08-15

deterministic, 1 gas deducted, 6

difficulty, 3, 9 gas expenditure per block, 9
difficulty bomb, 4 gas limit, 3, 5, 6
difficulty mechanism, 12 gas paid for increased use of memory, 6
discard nodes, 13 gas price, 5, 6, 9
double-spend problem, 13 gas refund clearing space, 6
dynamic difficulty homeostasis, 4 gas used, 3, 6, 9, 11
genesis block, 11
EIP 100, 4 genesis difficulty, 4
EIP 2, 4 GHOST protocol, 13
EIP 649, 4 global state database, 3
elliptic curve , 5
elliptic curve computation, 5 halting function, 8
elliptic curve cryptography, 5 halting state, 8
empty byte-array, 3 hash scheme, 5
empty byte-sequence, 9 heaviest path, 11
empty set, 10 homestead, 4
ere, 9 homestead difficulty parameter, 4
ethash, 12
ice age, 4
ether, 1
incomplete block, 11
ethereum runtime environment, 9
init, 8, 9
EVM, 5
input data, 7
EVM assembly, 10
inspection of data, 3
EVM code, 10
instantial runtime, 7
evm computation instances, 7
intrinsic validity, 6
exceptional halt, 6, 8
invalid instruction, 6
executed, 1
iterative progression, 8
execution, 6
iterator function, 8
execution environment, 7
execution function, 8 keccak 256, 3, 5
execution model, 8
explicitly specify meaning, 10 leaf node, 2, 4
exponential difficulty increase, 4 ledger, 1
extra data, 3 log events, 6
extract remaining gas, 8 log items, 6
log series, 8
fees, 6 logs bloom, 3, 10
finalization function, 7 logs series, 10
Finney, 1 logs set, 10
forest, 2 longest chain, 13

gas, 6, 9 machine halt, 6

gas available, 10 machine instructions, 1

23
Index Beigepaper – v0.8.5 2019-08-15

machine state, 5, 10 ommer headers, 11

machine storage, 5 ommer validation, 11
mapping, 2 ommers hash, 3
mapping between account states, 3 opcodes, 1
mapping between addresses, 3 originator price, 7
memory, 5 out-of-gas, 6
memory contents, 10
memory model, 5 parent hash, 3
memory model volatility of, 5 parent node, 2
memory size, 5 payment, 6
memory stack, 5 plasma, 13
memory usage fee, 6 positive integer, 9
memory word count, 10 post transaction state, 6
merkle-patricia trees, 2 present depth, 9
merkle-patricia tries, 2 probability statement, 12
merkletrees, 2 program counter, 10
message call, 6, 8, 9 proof-of-work, 12
message call transactions, 9 pseudocode, 1
miner choice, 9 pseudorandom number generation, 13
miners, 9
receipts root, 3
minimize storage use, 6
recipient, 9
mining, 1
refunded, 9
mining effort, 11
refunds, 8
mix hash, 3, 9, 12
remaining gas, 7, 8
modified merkletrees, 2
report exception, 6
native currency, 1 resultant output, 8
natively execute, 10 resultant state, 8
nested binary data, 3 RLP, 2, 3
network cost unit, 9 rlp, 9
newstate value, 7 RLP encodes as byte-arrays, 3
no leading zeroes, 3 RLP integers, 3
node depth, 2 root node, 2, 4
node height, 2
node operator computer, 3 Satoshi Nakamoto, 13
non empty deserialized integer, 3 scalability, 13
non-standard architecture, 6 seed, 12
nonce, 3, 9 self-destructs set, 8
nonce validation, 11 sender, 9
number, 3 sender account, 6
sender address, 7
ommer, 11 sequence concatenation, 9
ommer block headers, 4 serialization, 5, 9

24
Index Beigepaper – v0.8.5 2019-08-15

sharding, 13 transaction series, 10

sibling node, 2 transaction signature, 6
singleton, 1 transaction validation, 11
slice, 12 transactions, 11
speedy traversal of data, 3 transactions root, 3
stack based, 5, 7 tree arbitrary depth, 3
stack based architecture, 5 tree database, 2
stack contents, 10 tree degree, 2
stack underflow, 6 tree edge, 2
state database, 4, 13 tree height, 2
state machine cycle, 8 tree level, 2
state root, 3 tree path, 2
state transition, 5 trie database, 2
state transition function, 8 trusted, 1
state unchanged, 6
status code, 11 universal gas, 9
storage model, 5 unstoppable, 1
substates, 7 unused gas, 9
system state, 5, 7 upfront payment, 6
Szabo, 1
valid header, 11
valid state, 9
tagged for self destruction, 10
value, 5, 9
time stamp, 9
verification, 5
timestamp, 3
virtual machine, 1, 7
timestamped, 1
virtual ROM, 6
to, 5
to execute, 10 Wei, 1
total difficulty, 12 wei, 4
total fee, 6 well defined memory, 6
total gas used, 11 well defined storage, 6
totaly difficulty, 11 well-formed RLP, 6
touched accounts, 8 word addressable, 5
transaction, 5 word addressed, 5
transaction execution, 6 word array, 5
transaction execution function, 11 word size, 5
transaction nonce, 6 world state, 2
transaction originator, 9
transaction receipt, 6, 10 Yellowpaper, 1

25