Paper

ETHEREUM: A SECURE DECENTRALISED GENERALISED TRANSACTION LEDGER
BYZANTIUM VERSION 7e819ec - 2019-10-20
DR. GAVIN WOOD

FOUNDER, ETHEREUM & PARITY
[email protected]
Abstract. The blockchain paradigm when coupled with cryptographically-secured transactions has demonstrated its
utility through a number of projects, with Bitcoin being one of the most notable ones. Each such project can be seen as
a simple application on a decentralised, but singleton, compute resource. We can call this paradigm a transactional
singleton machine with shared-state.
Ethereum implements this paradigm in a generalised manner. Furthermore it provides a plurality of such resources,
each with a distinct state and operating code but able to interact through a message-passing framework with others.
We discuss its design, implementation issues, the opportunities it provides and the future hurdles we envisage.
1. Introduction is often lacking, and plain old prejudices are difficult to

shake.
With ubiquitous internet connections in most places
Overall, we wish to provide a system such that users
of the world, global information transmission has become
can be guaranteed that no matter with which other indi-
incredibly cheap. Technology-rooted movements like Bit-
viduals, systems or organisations they interact, they can
coin have demonstrated through the power of the default,
do so with absolute confidence in the possible outcomes
consensus mechanisms, and voluntary respect of the social
and how those outcomes might come about.
contract, that it is possible to use the internet to make
a decentralised value-transfer system that can be shared
1.2. Previous Work. Buterin [2013a] first proposed the
across the world and virtually free to use. This system can
kernel of this work in late November, 2013. Though now
be said to be a very specialised version of a cryptographi-
evolved in many ways, the key functionality of a block-
cally secure, transaction-based state machine. Follow-up
chain with a Turing-complete language and an effectively
systems such as Namecoin adapted this original “currency
unlimited inter-transaction storage capability remains un-
application” of the technology into other applications albeit
changed.
rather simplistic ones.
Dwork and Naor [1992] provided the first work into the
Ethereum is a project which attempts to build the gen-
usage of a cryptographic proof of computational expendi-
eralised technology; technology on which all transaction-
ture (“proof-of-work”) as a means of transmitting a value
based state machine concepts may be built. Moreover it
signal over the Internet. The value-signal was utilised here
aims to provide to the end-developer a tightly integrated
as a spam deterrence mechanism rather than any kind
end-to-end system for building software on a hitherto un-
of currency, but critically demonstrated the potential for
explored compute paradigm in the mainstream: a trustful
a basic data channel to carry a strong economic signal,
object messaging compute framework.
allowing a receiver to make a physical assertion without
having to rely upon trust. Back [2002] later produced a
system in a similar vein.
1.1. Driving Factors. There are many goals of this The first example of utilising the proof-of-work as a
project; one key goal is to facilitate transactions between strong economic signal to secure a currency was by Vish-
consenting individuals who would otherwise have no means numurthy et al. [2003]. In this instance, the token was
to trust one another. This may be due to geographical used to keep peer-to-peer file trading in check, providing
separation, interfacing difficulty, or perhaps the incompati- “consumers” with the ability to make micro-payments to
bility, incompetence, unwillingness, expense, uncertainty, “suppliers” for their services. The security model afforded
inconvenience, or corruption of existing legal systems. By by the proof-of-work was augmented with digital signatures
specifying a state-change system through a rich and unam- and a ledger in order to ensure that the historical record
biguous language, and furthermore architecting a system couldn’t be corrupted and that malicious actors could not
such that we can reasonably expect that an agreement will spoof payment or unjustly complain about service deliv-
be thus enforced autonomously, we can provide a means ery. Five years later, Nakamoto [2008] introduced another
to this end. such proof-of-work-secured value token, somewhat wider in
Dealings in this proposed system would have several scope. The fruits of this project, Bitcoin, became the first
attributes not often found in the real world. The incorrupt- widely adopted global decentralised transaction ledger.
ibility of judgement, often difficult to find, comes naturally Other projects built on Bitcoin’s success; the alt-coins
from a disinterested algorithmic interpreter. Transparency, introduced numerous other currencies through alteration
or being able to see exactly how a state or judgement came to the protocol. Some of the best known are Litecoin and
about through the transaction log and rules or instructional Primecoin, discussed by Sprankel [2013]. Other projects
codes, never happens perfectly in human-based systems sought to take the core value content mechanism of the pro-
since natural language is necessarily vague, information tocol and repurpose it; Aron [2012] discusses, for example,
1
ETHEREUM: A SECURE DECENTRALISED GENERALISED TRANSACTION LEDGER BYZANTIUM VERSION 7e819ec - 2019-10-20 2
the Namecoin project which aims to provide a decentralised itself—that would be far too big). They also punctuate the
name-resolution system. transaction series with incentives for nodes to mine. This
Other projects still aim to build upon the Bitcoin net- incentivisation takes place as a state-transition function,
work itself, leveraging the large amount of value placed in adding value to a nominated account.
the system and the vast amount of computation that goes Mining is the process of dedicating effort (working) to
into the consensus mechanism. The Mastercoin project, bolster one series of transactions (a block) over any other
first proposed by Willett [2013], aims to build a richer potential competitor block. It is achieved thanks to a
protocol involving many additional high-level features on cryptographically secure proof. This scheme is known as a
top of the Bitcoin protocol through utilisation of a number proof-of-work and is discussed in detail in section 11.5.
of auxiliary parts to the core protocol. The Coloured Coins Formally, we expand to:
project, proposed by Rosenfeld et al. [2012], takes a similar (2) σ t+1 ≡ Π(σ t , B)
but more simplified strategy, embellishing the rules of a
transaction in order to break the fungibility of Bitcoin’s (3) B ≡ (..., (T0 , T1 , ...), ...)
base currency and allow the creation and tracking of tokens (4) Π(σ, B) ≡ Ω(B, Υ(Υ(σ, T0 ), T1 )...)
through a special “chroma-wallet”-protocol-aware piece of Where Ω is the block-finalisation state transition func-
software. tion (a function that rewards a nominated party); B is this
Additional work has been done in the area with discard- block, which includes a series of transactions amongst some
ing the decentralisation foundation; Ripple, discussed by other components; and Π is the block-level state-transition
Boutellier and Heinzen [2014], has sought to create a “fed- function.
erated” system for currency exchange, effectively creating This is the basis of the blockchain paradigm, a model
a new financial clearing system. It has demonstrated that that forms the backbone of not only Ethereum, but all
high efficiency gains can be made if the decentralisation decentralised consensus-based transaction systems to date.
premise is discarded.
Early work on smart contracts has been done by Szabo 2.1. Value. In order to incentivise computation within the
[1997] and Miller [1997]. Around the 1990s it became clear network, there needs to be an agreed method for transmit-
that algorithmic enforcement of agreements could become a ting value. To address this issue, Ethereum has an intrinsic
significant force in human cooperation. Though no specific currency, Ether, known also as ETH and sometimes referred
system was proposed to implement such a system, it was to by the Old English D̄. The smallest subdenomination
proposed that the future of law would be heavily affected of Ether, and thus the one in which all integer values of
by such systems. In this light, Ethereum may be seen as a the currency are counted, is the Wei. One Ether is defined
general implementation of such a crypto-law system. as being 1018 Wei. There exist other subdenominations of
For a list of terms used in this paper, refer to Appendix Ether:
A. Multiplier Name
0
10 Wei
2. The Blockchain Paradigm
1012 Szabo
Ethereum, taken as a whole, can be viewed as a 1015 Finney
transaction-based state machine: we begin with a gen- 1018 Ether
esis state and incrementally execute transactions to morph Throughout the present work, any reference to value,
it into some final state. It is this final state which we in the context of Ether, currency, a balance or a payment,
accept as the canonical “version” of the world of Ethereum. should be assumed to be counted in Wei.
The state can include such information as account bal-
ances, reputations, trust arrangements, data pertaining 2.2. Which History? Since the system is decentralised
to information of the physical world; in short, anything and all parties have an opportunity to create a new block
that can currently be represented by a computer is admis- on some older pre-existing block, the resultant structure is
sible. Transactions thus represent a valid arc between two necessarily a tree of blocks. In order to form a consensus
states; the ‘valid’ part is important—there exist far more as to which path, from root (the genesis block) to leaf (the
invalid state changes than valid state changes. Invalid state block containing the most recent transactions) through
changes might, e.g., be things such as reducing an account this tree structure, known as the blockchain, there must
balance without an equal and opposite increase elsewhere. be an agreed-upon scheme. If there is ever a disagreement
A valid state transition is one which comes about through between nodes as to which root-to-leaf path down the block
a transaction. Formally: tree is the ‘best’ blockchain, then a fork occurs.
This would mean that past a given point in time (block),
(1) σ t+1 ≡ Υ(σ t , T )
multiple states of the system may coexist: some nodes be-
where Υ is the Ethereum state transition function. In lieving one block to contain the canonical transactions,
Ethereum, Υ, together with σ are considerably more pow- other nodes believing some other block to be canonical,
erful than any existing comparable system; Υ allows com- potentially containing radically different or incompatible
ponents to carry out arbitrary computation, while σ allows transactions. This is to be avoided at all costs as the un-
components to store arbitrary state between transactions. certainty that would ensue would likely kill all confidence
Transactions are collated into blocks; blocks are chained in the entire system.
together using a cryptographic hash as a means of refer- The scheme we use in order to generate consensus is a
ence. Blocks function as a journal, recording a series of simplified version of the GHOST protocol introduced by
transactions together with the previous block and an iden- Sompolinsky and Zohar [2013]. This process is described
tifier for the final state (though do not store the final state in detail in section 10.
Sometimes, a path follows a new protocol from a par- assume that the unmodified ‘input’ value be denoted by
ticular height. This document describes one version of the the placeholder then the modified and utilisable value is
protocol. In order to follow back the history of a path, one denoted as 0 , and intermediate values would be ∗ , ∗∗
must reference multiple versions of this document. &c. On very particular occasions, in order to maximise
readability and only if unambiguous in meaning, we may
3. Conventions use alpha-numeric subscripts to denote intermediate values,
especially those of particular note.
We use a number of typographical conventions for the
When considering the use of existing functions, given a
formal notation, some of which are quite particular to the
function f , the function f ∗ denotes a similar, element-wise
present work:
version of the function mapping instead between sequences.
The two sets of highly structured, ‘top-level’, state val-
It is formally defined in section 4.3.
ues, are denoted with bold lowercase Greek letters. They
We define a number of useful functions throughout. One
fall into those of world-state, which are denoted σ (or a
of the more common is `, which evaluates to the last item
variant thereupon) and those of machine-state, µ.
in the given sequence:
Functions operating on highly structured values are
denoted with an upper-case Greek letter, e.g. Υ, the
Ethereum state transition function. (5) `(x) ≡ x[kxk − 1]
For most functions, an uppercase letter is used, e.g. C,
the general cost function. These may be subscripted to 4. Blocks, State and Transactions
denote specialised variants, e.g. CSSTORE , the cost func- Having introduced the basic concepts behind Ethereum,
tion for the SSTORE operation. For specialised and possibly we will discuss the meaning of a transaction, a block and
externally defined functions, we may format as typewriter the state in more detail.
text, e.g. the Keccak-256 hash function (as per version
3 of the winning entry to the SHA-3 contest by Bertoni 4.1. World State. The world state (state), is a map-
et al. [2011], rather than the final SHA-3 specification), is ping between addresses (160-bit identifiers) and account
denoted KEC (and generally referred to as plain Keccak). states (a data structure serialised as RLP, see Appendix
Also, KEC512 refers to the Keccak-512 hash function. B). Though not stored on the blockchain, it is assumed
Tuples are typically denoted with an upper-case letter, that the implementation will maintain this mapping in
e.g. T , is used to denote an Ethereum transaction. This a modified Merkle Patricia tree (trie, see Appendix D).
symbol may, if accordingly defined, be subscripted to refer The trie requires a simple database backend that main-
to an individual component, e.g. Tn , denotes the nonce tains a mapping of byte arrays to byte arrays; we name
of said transaction. The form of the subscript is used to this underlying database the state database. This has a
denote its type; e.g. uppercase subscripts refer to tuples number of benefits; firstly the root node of this structure
with subscriptable components. is cryptographically dependent on all internal data and
Scalars and fixed-size byte sequences (or, synonymously, as such its hash can be used as a secure identity for the
arrays) are denoted with a normal lower-case letter, e.g. entire system state. Secondly, being an immutable data
n is used in the document to denote a transaction nonce. structure, it allows any previous state (whose root hash
Those with a particularly special meaning may be Greek, is known) to be recalled by simply altering the root hash
e.g. δ, the number of items required on the stack for a accordingly. Since we store all such root hashes in the
given operation. blockchain, we are able to trivially revert to old states.
Arbitrary-length sequences are typically denoted as a The account state, σ[a], comprises the following four
bold lower-case letter, e.g. o is used to denote the byte fields:
sequence given as the output data of a message call. For nonce: A scalar value equal to the number of trans-
particularly important values, a bold uppercase letter may actions sent from this address or, in the case
be used. of accounts with associated code, the number of
Throughout, we assume scalars are non-negative inte- contract-creations made by this account. For ac-
gers and thus belong to the set N. The set of all byte count of address a in state σ, this would be for-
sequences is B, formally defined in Appendix B. If such mally denoted σ[a]n .
a set of sequences is restricted to those of a particular balance: A scalar value equal to the number of Wei
length, it is denoted with a subscript, thus the set of all owned by this address. Formally denoted σ[a]b .
byte sequences of length 32 is named B32 and the set of storageRoot: A 256-bit hash of the root node of a
all non-negative integers smaller than 2256 is named N256 . Merkle Patricia tree that encodes the storage con-
This is formally defined in section 4.3. tents of the account (a mapping between 256-bit
Square brackets are used to index into and reference integer values), encoded into the trie as a mapping
individual components or subsequences of sequences, e.g. from the Keccak 256-bit hash of the 256-bit integer
µs [0] denotes the first item on the machine’s stack. For keys to the RLP-encoded 256-bit integer values.
subsequences, ellipses are used to specify the intended The hash is formally denoted σ[a]s .
range, to include elements at both limits, e.g. µm [0..31] codeHash: The hash of the EVM code of this
denotes the first 32 items of the machine’s memory. account—this is the code that gets executed should
In the case of the global state σ, which is a sequence of this address receive a message call; it is immutable
accounts, themselves tuples, the square brackets are used and thus, unlike all other fields, cannot be changed
to reference an individual account. after construction. All such code fragments are
When considering variants of existing values, we follow contained in the state database under their corre-
the rule that within a given scope for definition, if we sponding hashes for later retrieval. This hash is
formally denoted σ[a]c , and thus the code may be gasPrice: A scalar value equal to the number of
denoted as b, given that KEC(b) = σ[a]c . Wei to be paid per unit of gas for all computation
Since we typically wish to refer not to the trie’s root costs incurred as a result of the execution of this
hash but to the underlying set of key/value pairs stored transaction; formally Tp .
within, we define a convenient equivalence: gasLimit: A scalar value equal to the maximum
amount of gas that should be used in executing
TRIE L∗I (σ[a]s ) ≡ σ[a]s

(6) this transaction. This is paid up-front, before any
The collapse function for the set of key/value pairs in computation is done and may not be increased
the trie, L∗I , is defined as the element-wise transformation later; formally Tg .
of the base function LI , given as: to: The 160-bit address of the message call’s recipi-
ent or, for a contract creation transaction, ∅, used
(7) LI (k, v) ≡ KEC(k), RLP(v) here to denote the only member of B0 ; formally
where: Tt .
value: A scalar value equal to the number of Wei to
(8) k ∈ B32 ∧ v∈N be transferred to the message call’s recipient or,
in the case of contract creation, as an endowment
It shall be understood that σ[a]s is not a ‘physical’
to the newly created account; formally Tv .
member of the account and does not contribute to its later
v, r, s: Values corresponding to the signature of the
serialisation.
transaction and used to determine the sender of
If the codeHash field is the Keccak-256 hash of the
the transaction; formally Tw , Tr and Ts . This is
empty string, i.e. σ[a]c = KEC () , then the node represents
expanded in Appendix F.
a simple account, sometimes referred to as a “non-contract”
account. Additionally, a contract creation transaction contains:
Thus we may define a world-state collapse function LS : init: An unlimited size byte array specifying the
(9) LS (σ) ≡ {p(a) : σ[a] 6= ∅} EVM-code for the account initialisation procedure,
formally Ti .
where
init is an EVM-code fragment; it returns the body,
(10) p(a) ≡ KEC(a), RLP (σ[a]n , σ[a]b , σ[a]s , σ[a]c ) a second fragment of code that executes each time the
account receives a message call (either through a trans-
This function, LS , is used alongside the trie function
action or due to the internal execution of code). init is
to provide a short identity (hash) of the world state. We
executed only once at account creation and gets discarded
assume:
immediately thereafter.
(11) ∀a : σ[a] = ∅ ∨ (a ∈ B20 ∧ v(σ[a])) In contrast, a message call transaction contains:
where v is the account validity function: data: An unlimited size byte array specifying the
input data of the message call, formally Td .
(12) v(x) ≡ xn ∈ N256 ∧xb ∈ N256 ∧xs ∈ B32 ∧xc ∈ B32
Appendix F specifies the function, S, which maps trans-
An account is empty when it has no code, zero nonce actions to the sender, and happens through the ECDSA of
and zero balance: the SECP-256k1 curve, using the hash of the transaction
(13) (excepting the latter three signature fields) as the datum
EMPTY(σ, a) ≡ σ[a]c = KEC () ∧σ[a]n = 0∧σ[a]b = 0 to sign. For the present we simply assert that the sender
Even callable precompiled contracts can have an empty of a given transaction T can be represented with S(T ).
account state. This is because their account states do not
usually contain the code describing its behavior. (15) (
An account is dead when its account state is non-existent (Tn , Tp , Tg , Tt , Tv , Ti , Tw , Tr , Ts ) if Tt = ∅
LT (T ) ≡
or empty: (Tn , Tp , Tg , Tt , Tv , Td , Tw , Tr , Ts ) otherwise
(14) DEAD(σ, a) ≡ σ[a] = ∅ ∨ EMPTY(σ, a) Here, we assume all components are interpreted by the
RLP as integer values, with the exception of the arbitrary
4.2. The Transaction. A transaction (formally, T ) is a
length byte arrays Ti and Td .
single cryptographically-signed instruction constructed by
an actor externally to the scope of Ethereum. While it is (16) Tn ∈ N256 ∧ Tv ∈ N256 ∧ Tp ∈ N256 ∧
assumed that the ultimate external actor will be human in Tg ∈ N256 ∧ Tw ∈ N5 ∧ Tr ∈ N256 ∧
nature, software tools will be used in its construction and Ts ∈ N256 ∧ Td ∈ B ∧ Ti ∈ B
dissemination1. There are two types of transactions: those
which result in message calls and those which result in where
the creation of new accounts with associated code (known
(17) Nn = {P : P ∈ N ∧ P < 2n }
informally as ‘contract creation’). Both types specify a
number of common fields: The address hash Tt is slightly different: it is either a
nonce: A scalar value equal to the number of trans- 20-byte address hash or, in the case of being a contract-
actions sent by the sender; formally Tn . creation transaction (and thus formally equal to ∅), it is
1Notably, such ‘tools’ could ultimately become so causally removed from their human-based initiation—or humans may become so
causally-neutral—that there could be a point at which they rightly be considered autonomous agents. e.g. contracts may offer bounties to
humans for being sent transactions to initiate their execution.
the RLP empty byte sequence and thus the member of B0 : nonce: A 64-bit value which, combined with the mix-
hash, proves that a sufficient amount of computa-
( tion has been carried out on this block; formally
B20 if Tt 6= ∅
(18) Tt ∈ Hn .
B0 otherwise
The other two components in the block are simply a list
of ommer block headers (of the same format as above),
BU and a series of the transactions, BT . Formally, we can
4.3. The Block. The block in Ethereum is the collec- refer to a block B:
tion of relevant pieces of information (known as the block
header ), H, together with information corresponding to (19) B ≡ (BH , BT , BU )
the comprised transactions, T, and a set of other block
headers U that are known to have a parent equal to the 4.3.1. Transaction Receipt. In order to encode information
present block’s parent’s parent (such blocks are known as about a transaction concerning which it may be useful
ommers 2). The block header contains several pieces of to form a zero-knowledge proof, or index and search, we
information: encode a receipt of each transaction containing certain in-
formation from its execution. Each receipt, denoted BR [i]
parentHash: The Keccak 256-bit hash of the parent for the ith transaction, is placed in an index-keyed trie
block’s header, in its entirety; formally Hp . and the root recorded in the header as He .
ommersHash: The Keccak 256-bit hash of the om- The transaction receipt, R, is a tuple of four items com-
mers list portion of this block; formally Ho . prising: the cumulative gas used in the block containing
beneficiary: The 160-bit address to which all fees the transaction receipt as of immediately after the trans-
collected from the successful mining of this block action has happened, Ru , the set of logs created through
be transferred; formally Hc . execution of the transaction, Rl and the Bloom filter com-
stateRoot: The Keccak 256-bit hash of the root posed from information in those logs, Rb and the status
node of the state trie, after all transactions are code of the transaction, Rz :
executed and finalisations applied; formally Hr .
transactionsRoot: The Keccak 256-bit hash of the (20) R ≡ (Ru , Rb , Rl , Rz )
root node of the trie structure populated with each
transaction in the transactions list portion of the The function LR trivially prepares a transaction receipt
block; formally Ht . for being transformed into an RLP-serialised byte array:
receiptsRoot: The Keccak 256-bit hash of the root (21) LR (R) ≡ (0 ∈ B256 , Ru , Rb , Rl )
node of the trie structure populated with the re-
ceipts of each transaction in the transactions list where 0 ∈ B256 replaces the pre-transaction state root that
portion of the block; formally He . existed in previous versions of the protocol.
logsBloom: The Bloom filter composed from index- We assert that the status code Rz is a non-negative
able information (logger address and log topics) integer.
contained in each log entry from the receipt of
each transaction in the transactions list; formally (22) Rz ∈ N
Hb . We assert that Ru , the cumulative gas used, is a non-
difficulty: A scalar value corresponding to the dif- negative integer and that the logs Bloom, Rb , is a hash of
ficulty level of this block. This can be calculated size 2048 bits (256 bytes):
from the previous block’s difficulty level and the
timestamp; formally Hd . (23) Ru ∈ N ∧ Rb ∈ B256
number: A scalar value equal to the number of an-
cestor blocks. The genesis block has a number of The sequence Rl is a series of log entries, (O0 , O1 , ...).
zero; formally Hi . A log entry, O, is a tuple of the logger’s address, Oa , a
gasLimit: A scalar value equal to the current limit possibly empty series of 32-byte log topics, Ot and some
of gas expenditure per block; formally Hl . number of bytes of data, Od :
gasUsed: A scalar value equal to the total gas used (24) O ≡ (Oa , (Ot0 , Ot1 , ...), Od )
in transactions in this block; formally Hg .
timestamp: A scalar value equal to the reasonable
output of Unix’s time() at this block’s inception; (25) Oa ∈ B20 ∧ ∀x ∈ Ot : x ∈ B32 ∧ Od ∈ B
formally Hs .
We define the Bloom filter function, M , to reduce a log
extraData: An arbitrary byte array containing data
entry into a single 256-byte hash:
relevant to this block. This must be 32 bytes or
_
fewer; formally Hx .

(26) M (O) ≡ x∈{Oa }∪Ot M3:2048 (x)
mixHash: A 256-bit hash which, combined with the
nonce, proves that a sufficient amount of compu- where M3:2048 is a specialised Bloom filter that sets
tation has been carried out on this block; formally three bits out of 2048, given an arbitrary byte sequence.
Hm . It does this through taking the low-order 11 bits of each of
2ommer is a gender-neutral term to mean “sibling of parent”; see https://nonbinary.miraheze.org/wiki/Gender_neutral_language#Aunt.
2FUncle
311 bits = 22048 , and the low-order 11 bits is the modulo 2048 of the operand, which is in this case is “each of the first three pairs of
bytes in a Keccak-256 hash of the byte sequence.”
the first three pairs of bytes in a Keccak-256 hash of the where

byte sequence.3 Formally:
(38) Bn = {B : B ∈ B ∧ kBk = n}
(27)M3:2048 (x : x ∈ B) ≡ y : y ∈ B256 where:
(28) y = (0, 0, ..., 0) except: We now have a rigorous specification for the construc-
tion of a formal block structure. The RLP function RLP
(29) ∀i ∈ {0, 2, 4} : Bm(x,i) (y) = 1
(see Appendix B) provides the canonical method for trans-
(30) m(x, i) ≡ KEC(x)[i, i + 1] mod 2048 forming this structure into a sequence of bytes ready for
where B is the bit reference function such that Bj (x) transmission over the wire or storage locally.
equals the bit of index j (indexed from 0) in the byte array
x. 4.3.4. Block Header Validity. We define P (BH ) to be the
parent block of B, formally:
4.3.2. Holistic Validity. We can assert a block’s validity
if and only if it satisfies several conditions: it must be in- (39) P (H) ≡ B 0 : KEC(RLP(BH
0
)) = Hp
ternally consistent with the ommer and transaction block
hashes and the given transactions BT (as specified in sec The block number is the parent’s block number incre-
11), when executed in order on the base state σ (derived mented by one:
from the final state of the parent block), result in a new
(40) Hi ≡ P (H)H i + 1
state of the identity Hr :
(31) Hr ≡ TRIE(LS (Π(σ, B))) ∧ The canonical difficulty of a block of header H is defined
Ho ≡ KEC(RLP(L∗H (BU ))) ∧ as D(H):
Ht ≡ TRIE({∀i < kBT k, i ∈ N : (41) (
p(i, LT (BT [i]))}) ∧ D0 if Hi = 0
D(H) ≡
He ≡ TRIE({∀i < kBR k, i ∈ N :

max D0 , P (H)H d + x × ς2 + otherwise
W p(i, LR(BR [i]))}) ∧
Hb ≡ r∈BR rb where:
where p(k, v) is simply the pairwise RLP transformation, (42) D0 ≡ 131072
in this case, the first being the index of the transaction in
the block and the second being the transaction receipt:
P (H)H d
(32) p(k, v) ≡ RLP(k), RLP(v)
(43) x≡
2048
Furthermore:
Hs − P (H)H s

(33) TRIE(LS (σ)) = P (BH )H r (44) ς2 ≡ max y − , −99
9
Thus TRIE(LS (σ)) is the root node hash of the Merkle
Patricia tree structure containing the key-value pairs of (
the state σ with values encoded using RLP, and P (BH ) is 1 if kP (H)U k = 0
y≡
the parent block of B, defined directly. 2 otherwise
The values stemming from the computation of transac-
tions, specifically the transaction receipts, BR , and that j 0
k
defined through the transaction’s state-accumulation func- (45) ≡ 2bHi ÷100000c−2
tion, Π, are formalised later in section 11.4. (46) Hi0 ≡ max(Hi − 3000000, 0)
4.3.3. Serialisation. The function LB and LH are the Note that D0 is the difficulty of the genesis block. The
preparation functions for a block and block header re- Homestead difficulty parameter, ς2 , is used to affect a dy-
spectively. Much like the transaction receipt preparation namic homeostasis of time between blocks, as the time
function LR , we assert the types and order of the structure between blocks varies, as discussed below, as implemented
for when the RLP transformation is required: in EIP-2 by Buterin [2015]. In the Homestead release,
(34) LH (H) ≡ ( Hp , H o , H c , H r , H t , H e , H b , H d , the exponential difficulty symbol, causes the difficulty to
Hi , H l , H g , H s , H x , H m , H n ) slowly increase (every 100,000 blocks) at an exponential
rate, and thus increasing the block time difference, and
LH (BH ), L∗T (BT ), L∗H (BU )

(35) LB (B) ≡ putting time pressure on transitioning to proof-of-stake.
With L∗T and L∗H being element-wise sequence transfor- This effect, known as the “difficulty bomb”, or “ice age”,
mations, thus: was explained in EIP-649 by Schoedon and Buterin [2017]
(36) and delayed and implemented earlier in EIP-2. ς2 was also
f ∗ (x0 , x1 , ...) ≡ f (x0 ), f (x1 ), ... for any function f

modified in EIP-100 with the use of x, the adjustment
factor above, and the denominator 9, in order to target
The component types are defined thus:
the mean block time including uncle blocks by Buterin
(37) Hp ∈ B32 ∧ Ho ∈ B32 ∧ Hc ∈ B20 ∧ [2016]. Finally, in the Byzantium release, with EIP-649,
Hr ∈ B32 ∧ Ht ∈ B32 ∧ He ∈ B32 ∧ the ice age was delayed by creating a fake block number,
Hb ∈ B256 ∧ Hd ∈ N ∧ Hi ∈ N ∧ Hi0 , which is obtained by subtracting three million from
Hl ∈ N ∧ Hg ∈ N ∧ Hs ∈ N256 ∧ the actual block number, which in other words reduced
Hx ∈ B ∧ Hm ∈ B32 ∧ Hn ∈ B8 and the time difference between blocks, in order to allow
more time to develop proof-of-stake and preventing the 5. Gas and Payment
network from “freezing” up.
In order to avoid issues of network abuse and to sidestep
The canonical gas limit Hl of a block of header H must
the inevitable questions stemming from Turing complete-
fulfil the relation:
ness, all programmable computation in Ethereum is subject
P (H)H l to fees. The fee schedule is specified in units of gas (see Ap-
(47) Hl < P (H)H l + ∧
1024 pendix G for the fees associated with various computation).

P (H)H l Thus any given fragment of programmable computation
Hl > P (H)H l − ∧
1024 (this includes creating contracts, making message calls,
Hl > 5000 utilising and accessing account storage and executing op-
erations on the virtual machine) has a universally agreed
Hs is the timestamp (in Unix’s time()) of block H and cost in terms of gas.
must fulfil the relation: Every transaction has a specific amount of gas associ-
(48) Hs > P (H)H s ated with it: gasLimit. This is the amount of gas which
is implicitly purchased from the sender’s account balance.
This mechanism enforces a homeostasis in terms of the
The purchase happens at the according gasPrice, also
time between blocks; a smaller period between the last two
specified in the transaction. The transaction is consid-
blocks results in an increase in the difficulty level and thus
ered invalid if the account balance cannot support such
additional computation required, lengthening the likely
a purchase. It is named gasLimit since any unused gas
next period. Conversely, if the period is too large, the
at the end of the transaction is refunded (at the same
difficulty, and expected time to the next block, is reduced.
rate of purchase) to the sender’s account. Gas does not
The nonce, Hn , must satisfy the relations:
exist outside of the execution of a transaction. Thus for
2256 accounts with trusted code associated, a relatively high
(49) n6 ∧ m = Hm
Hd gas limit may be set and left alone.
with (n, m) = PoW(Hn , Hn , d). In general, Ether used to purchase gas that is not re-
Where Hn is the new block’s header H, but without the funded is delivered to the beneficiary address, the address
nonce and mix-hash components, d being the current DAG, of an account typically under the control of the miner.
a large data set needed to compute the mix-hash, and PoW Transactors are free to specify any gasPrice that they
is the proof-of-work function (see section 11.5): this evalu- wish, however miners are free to ignore transactions as
ates to an array with the first item being the mix-hash, to they choose. A higher gas price on a transaction will there-
prove that a correct DAG has been used, and the second fore cost the sender more in terms of Ether and deliver
item being a pseudo-random number cryptographically a greater value to the miner and thus will more likely be
dependent on H and d. Given an approximately uniform selected for inclusion by more miners. Miners, in general,
distribution in the range [0, 264 ), the expected time to find will choose to advertise the minimum gas price for which
a solution is proportional to the difficulty, Hd . they will execute transactions and transactors will be free
This is the foundation of the security of the blockchain to canvas these prices in determining what gas price to
and is the fundamental reason why a malicious node can- offer. Since there will be a (weighted) distribution of min-
not propagate newly created blocks that would otherwise imum acceptable gas prices, transactors will necessarily
overwrite (“rewrite”) history. Because the nonce must sat- have a trade-off to make between lowering the gas price
isfy this requirement, and because its satisfaction depends and maximising the chance that their transaction will be
on the contents of the block and in turn its composed mined in a timely manner.
transactions, creating new, valid, blocks is difficult and,
over time, requires approximately the total compute power 6. Transaction Execution
of the trustworthy portion of the mining peers. The execution of a transaction is the most complex part
Thus we are able to define the block header validity of the Ethereum protocol: it defines the state transition
function V (H): function Υ. It is assumed that any transactions executed
2256 first pass the initial tests of intrinsic validity. These include:
(50) V (H) ≡ n6 ∧ m = Hm ∧
Hd (1) The transaction is well-formed RLP, with no addi-
Hd = D(H) ∧ tional trailing bytes;
Hg ≤ Hl ∧ (2) the transaction signature is valid;
(3) the transaction nonce is valid (equivalent to the
P (H)H l
Hl < P (H)H l + ∧ sender account’s current nonce);
1024
(4) the gas limit is no smaller than the intrinsic gas,
P (H)H l g0 , used by the transaction; and
Hl > P (H)H l − ∧
1024 (5) the sender account balance contains at least the
Hl > 5000 ∧ cost, v0 , required in up-front payment.
Hs > P (H)H s ∧ Formally, we consider the function Υ, with T being a
Hi = P (H)H i + 1 ∧ transaction and σ the state:
kHx k ≤ 32 (51) σ 0 = Υ(σ, T )
where (n, m) = PoW(Hn , Hn , d) Thus σ 0 is the post-transactional state. We also define
g
Noting additionally that extraData must be at most Υ to evaluate to the amount of gas used in the execution
32 bytes. of a transaction, Υl to evaluate to the transaction’s accrued
log items and Υz to evaluate to the status code resulting as Tg − g0 . The computation, whether contract creation
from the transaction. These will be formally defined later. or a message call, results in an eventual state (which may
legally be equivalent to the current state), the change to
6.1. Substate. Throughout transaction execution, we ac- which is deterministic and never invalid: there can be no
crue certain information that is acted upon immediately invalid transactions from this point.
following the transaction. We call this the accrued transac- We define the checkpoint state σ 0 :
tion substate, or accrued substate for short, and represent
it as A, which is a tuple: (59) σ0 ≡ σ except:
(52) A ≡ (As , Al , At , Ar ) (60) σ 0 [S(T )]b ≡ σ[S(T )]b − Tg Tp
The tuple contents include As , the self-destruct set: a (61) σ 0 [S(T )]n ≡ σ[S(T )]n + 1
set of accounts that will be discarded following the trans- Evaluating σ P from σ 0 depends on the transaction
action’s completion. Al is the log series: this is a series of type; either contract creation or message call; we define
archived and indexable ‘checkpoints’ in VM code execu- the tuple of post-execution provisional state σ P , remaining
tion that allow for contract-calls to be easily tracked by gas g 0 , accrued substate A and status code z:
onlookers external to the Ethereum world (such as decen- (62)
tralised application front-ends). At is the set of touched 
Λ4 (σ 0 , S(T ), To , g,
accounts, of which the empty ones are deleted at the end



of a transaction. Finally there is Ar , the refund balance,
 Tp , Tv , Ti , 0, >) if Tt = ∅
(σ P , g 0 , A, z) ≡
increased through using the SSTORE instruction in order 

Θ4 (σ 0 , S(T ), To , Tt , Tt ,
to reset contract storage to zero from some non-zero value. g, Tp , Tv , Tv , Td , 0, >) otherwise

Though not immediately refunded, it is allowed to partially
offset the total execution costs. where g is the amount of gas remaining after deducting
We define the empty accrued substate A0 to have no the basic amount required to pay for the existence of the
self-destructs, no logs, no touched accounts and a zero transaction:
refund balance:
(63) g ≡ Tg − g0
(53) A0 ≡ (∅, (), ∅, 0)
and To is the original transactor, which can differ from the
6.2. Execution. We define intrinsic gas g0 , the amount of sender in the case of a message call or contract creation
gas this transaction requires to be paid prior to execution, not directly triggered by a transaction but coming from
as follows: the execution of EVM-code.
Note we use Θ4 and Λ4 to denote the fact that only the
(
X Gtxdatazero if i = 0
(54) g0 ≡ first four components of the functions’ values are taken;
G txdatanonzero otherwise
i∈Ti ,Td the final represents the message-call’s output value (a byte
(
Gtxcreate if Tt = ∅ array) and is unused in the context of transaction evalua-
(55) + tion.
0 otherwise
After the message call or contract creation is processed,
(56) + Gtransaction the refund counter has to be incremented for the accounts
where Ti , Td means the series of bytes of the trans- that were self-destructed throughout its invocation.
action’s associated data and initialisation EVM-code, de- X
(64) A0r ≡ Ar + Rself destruct
pending on whether the transaction is for contract-creation
i∈As
or message-call. Gtxcreate is added if the transaction is
contract-creating, but not if a result of EVM-code. G is Then the state is finalised by determining the amount
fully defined in Appendix G. to be refunded, g ∗ from the remaining gas, g 0 , plus some
The up-front cost v0 is calculated as: allowance from the refund counter, to the sender at the
original rate.
(57) v0 ≡ Tg Tp + Tv
Tg − g 0 k 0
j
The validity is determined as: (65) g ∗ ≡ g 0 + min , Ar
2
(58) S(T ) 6= ∅ ∧
σ[S(T )] 6 = ∅ ∧ The total refundable amount is the legitimately remain-
Tn = σ[S(T )]n ∧ ing gas g 0 , added to Ar , with the latter component being
g0 6 Tg ∧ capped up to a maximum of half (rounded down) of the
v0 6 σ[S(T )]b ∧ total amount used Tg − g 0 . Therefore, g ∗ is the total gas
Tg 6 BH l − `(BR )u that remains after the transaction has been executed.
The Ether for the gas is given to the miner, whose
Note the final condition; the sum of the transaction’s
address is specified as the beneficiary of the present block
gas limit, Tg , and the gas utilised in this block prior, given
B. So we define the pre-final state σ ∗ in terms of the
by `(BR )u , must be no greater than the block’s gasLimit,
provisional state σ P :
BH l .
The execution of a valid transaction begins with an (66) σ∗ ≡ σP except
irrevocable change made to the state: the nonce of the ∗
(67) σ [S(T )]b ≡ σ P [S(T )]b + g ∗ Tp
account of the sender, S(T ), is incremented by one and the
balance is reduced by part of the up-front cost, Tg Tp . The (68) σ ∗ [m]b ≡ σ P [m]b + (Tg − g ∗ )Tp
gas available for the proceeding computation, g, is defined (69) m ≡ BH c
The final state, σ 0 , is reached after deleting all accounts where v 0 is the account’s pre-existing value, in the event
that either appear in the self-destruct set or are touched it was previously in existence:
and empty: (
0 if σ[a] = ∅
(70) σ0 ≡ σ∗ except (82) 0
v ≡
0 σ[a]b otherwise
(71) ∀i ∈ As : σ [i] = ∅
(72) ∀i ∈ At : σ 0 [i] = ∅ if DEAD(σ ∗, i) Finally, the account is initialised through the execution
g of the initialising EVM code i according to the execution
And finally, we specify Υ , the total gas used in this
model (see section 9). Code execution can effect several
transaction Υl , the logs created by this transaction and
events that are not internal to the execution state: the
Υz , the status code of this transaction:
account’s storage can be altered, further accounts can be
(73) Υg (σ, T ) ≡ Tg − g ∗ created and further message calls can be made. As such,
(74) l
Υ (σ, T ) ≡ Al the code execution function Ξ evaluates to a tuple of the re-
sultant state σ ∗∗ , available gas remaining g ∗∗ , the accrued
(75) Υz (σ, T ) ≡ z substate A and the body code of the account o.
These are used to help define the transaction receipt
and are also used later for state and nonce validation.
(83) (σ ∗∗ , g ∗∗ , A, o) ≡ Ξ(σ ∗ , g, I, {s, a})
7. Contract Creation where I contains the parameters of the execution environ-

There are a number of intrinsic parameters used when ment, that is:
creating an account: sender (s), original transactor (o),
available gas (g), gas price (p), endowment (v) together (84) Ia ≡ a
with an arbitrary length byte array, i, the initialisation (85) Io ≡ o
EVM code, the present depth of the message-call/contract- (86) Ip ≡ p
creation stack (e) and finally the permission to make mod- (87) Id ≡ ()
ifications to the state (w).
We define the creation function formally as the function (88) Is ≡ s
Λ, which evaluates from these values, together with the (89) Iv ≡ v
state σ to the tuple containing the new state, remaining (90) Ib ≡ i
gas, accrued transaction substate and an error message (91) Ie ≡ e
(σ 0 , g 0 , A, o), as in section 6:
(92) Iw ≡ w
(76) (σ 0 , g 0 , A, z, o) ≡ Λ(σ, s, o, g, p, v, i, e, w)
Id evaluates to the empty tuple as there is no input data
The address of the new account is defined as being the to this call. IH has no special treatment and is determined
rightmost 160 bits of the Keccak hash of the RLP encoding from the blockchain.
of the structure containing only the sender and the account Code execution depletes gas, and gas may not go below
nonce. Thus we define the resultant address for the new zero, thus execution may exit before the code has come
account a: to a natural halting state. In this (and several other) ex-

(77) a ≡ B96..255 KEC RLP (s, σ[s]n − 1) ceptional cases we say an out-of-gas (OOG) exception has
occurred: The evaluated state is defined as being the empty
where KEC is the Keccak 256-bit hash function, RLP is set, ∅, and the entire create operation should have no effect
the RLP encoding function, Ba..b (X) evaluates to a binary on the state, effectively leaving it as it was immediately
value containing the bits of indices in the range [a, b] of prior to attempting the creation.
the binary data X, and σ[x] is the address state of x, or If the initialization code completes successfully, a final
∅ if none exists. Note we use one fewer than the sender’s contract-creation cost is paid, the code-deposit cost, c,
nonce value; we assert that we have incremented the sender proportional to the size of the created contract’s code:
account’s nonce prior to this call, and so the value used
is the sender’s nonce at the beginning of the responsible (93) c ≡ Gcodedeposit × kok
transaction or VM operation.
The account’s nonce is initially defined as one, the bal- If there is not enough gas remaining to pay this, i.e.
ance as the value passed, the storage as empty and the g ∗∗ < c, then we also declare an out-of-gas exception.
code hash as the Keccak 256-bit hash of the empty string; The gas remaining will be zero in any such exceptional
the sender’s balance is also reduced by the value passed. condition, i.e. if the creation was conducted as the recep-
Thus the mutated state becomes σ ∗ : tion of a transaction, then this doesn’t affect payment of
the intrinsic cost of contract creation; it is paid regardless.
(78) σ∗ ≡ σ except: However, the value of the transaction is not transferred to
the aborted contract’s address when we are out-of-gas.
σ ∗ [a] 1, v + v 0 , TRIE(∅), KEC ()

(79) = If such an exception does not occur, then the remaining
( gas is refunded to the originator and the now-altered state
∅ if σ[s] = ∅ ∧ v = 0
(80) σ ∗ [s] = is allowed to persist. Thus formally, we may specify the
a∗ otherwise resultant state, gas, accrued substate and status code as
(81) a∗ ≡ (σ[s]n , σ[s]b − v, σ[s]s , σ[s]c ) (σ 0 , g 0 , A, z) where:
We define σ 1 , the first transitional state as the orig-

(94) inal state but with the value transferred from sender to
recipient:
( (99) σ 1 [r]b ≡ σ[r]b + v ∧ σ 1 [s]b ≡ σ[s]b − v
0 0 if F
g ≡
g ∗∗ − c otherwise unless s = r.
Throughout the present work, it is assumed that if σ 1 [r]
(95)
 was originally undefined, it will be created as an account

 σ if F with no code or state and zero balance and nonce. Thus

σ ∗∗ except:


 the previous equation should be taken to mean:
0
σ ≡ σ 0 [a] = ∅ if DEAD(σ ∗∗ , a)
 ∗∗
(100) σ 1 ≡ σ 01 except:
σ

 except:

0

σ [a]c = KEC(o) otherwise
 (
∅ if σ 01 [s] = ∅ ∧ v = 0
(96) (101) σ 1 [s] ≡
( a1 otherwise
0 if σ ∗∗ = ∅ ∨ g ∗∗ < c
z≡
1 otherwise
a1 ≡ σ 01 [s]n , σ 01 [s]b − v, σ 01 [s]s , σ 01 [s]c

(102)
where
(97) (103) and σ 01 ≡ σ except:
F ≡ (σ ∗∗ = ∅ ∧ o = ∅) ∨ g ∗∗ < c ∨ kok > 24576

(104)
The exception in the determination of σ 0 dictates that 
σ 01 [r] ≡ (0, v, TRIE(∅), KEC(())) if σ[r] = ∅ ∧ v =
6 0
o, the resultant byte sequence from the execution of the 
initialisation code, specifies the final body code for the σ 01 [r] ≡ ∅ if σ[r] = ∅ ∧ v = 0
 0
σ 1 [r] ≡ a01

newly-created account. otherwise
Note that intention is that the result is either a success-
fully created new contract with its endowment, or no new (105) a01 ≡ (σ[r]n , σ[r]b + v, σ[r]s , σ[r]c )
contract with no transfer of value.
The account’s associated code (identified as the frag-
7.1. Subtleties. Note that while the initialisation code ment whose Keccak hash is σ[c]c ) is executed according to
is executing, the newly created address exists but with the execution model (see section 9). Just as with contract
no intrinsic body code4. Thus any message call received creation, if the execution halts in an exceptional fashion
by it during this time causes no code to be executed. If (i.e. due to an exhausted gas supply, stack underflow, in-
the initialisation execution ends with a SELFDESTRUCT valid jump destination or invalid instruction), then no gas
instruction, the matter is moot since the account will be is refunded to the caller and the state is reverted to the
deleted before the transaction is completed. For a normal point immediately prior to balance transfer (i.e. σ).
STOP code, or if the code returned is otherwise empty, then
the state is left with a zombie account, and any remaining (
balance will be locked into the account forever. 0 σ if σ ∗∗ = ∅
(106) σ ≡
σ ∗∗ otherwise
8. Message Call 
0
 if σ ∗∗ = ∅ ∧
In the case of executing a message call, several param- (107) g0 ≡ o=∅
eters are required: sender (s), transaction originator (o),  ∗∗

g otherwise
recipient (r), the account whose code is to be executed (c, (
usually the same as recipient), available gas (g), value (v) 0 if σ ∗∗ = ∅
z ≡
and gas price (p) together with an arbitrary length byte 1 otherwise
array, d, the input data of the call, the present depth of
(108) (σ ∗∗ , g ∗∗ , A, o) ≡ Ξ
the message-call/contract-creation stack (e) and finally the
permission to make modifications to the state (w). (109) Ia ≡ r
Aside from evaluating to a new state and accrued (110) Io ≡ o
transaction substate, message calls also have an extra (111) Ip ≡ p
component—the output data denoted by the byte array
(112) Id ≡ d
o. This is ignored when executing transactions, however
message calls can be initiated due to VM-code execution (113) Is ≡ s
and in this case this information is used. (114) Iv ≡ ṽ
(98) 0 0
(σ , g , A, z, o) ≡ Θ(σ, s, o, r, c, g, p, v, ṽ, d, e, w) (115) Ie ≡ e
(116) Iw ≡ w
Note that we need to differentiate between the value that
is to be transferred, v, from the value apparent in the (117) t ≡ {s, r}
execution context, ṽ, for the DELEGATECALL instruction. (118)
4During initialization code execution, EXTCODESIZE on the address should return zero, which is the length of the code of the account while
CODESIZE should return the length of the initialization code (as defined in H.2).
where the transaction processor or, recursively, the spawning

execution environment) which will deal with it separately.



ΞECREC (σ 1 , g, I, t) if r = 1

ΞSHA256 (σ 1 , g, I, t) if r = 2 9.2. Fees Overview. Fees (denominated in gas) are






ΞRIP160 (σ 1 , g, I, t) if r = 3 charged under three distinct circumstances, all three as

ΞID (σ 1 , g, I, t)

 if r = 4 prerequisite to the execution of an operation. The first
 and most common is the fee intrinsic to the computation
(119) Ξ ≡ ΞEXPMOD (σ 1 , g, I, t) if r = 5
 of the operation (see Appendix G). Secondly, gas may be
ΞBN ADD (σ 1 , g, I, t)

if r = 6


 deducted in order to form the payment for a subordinate
ΞBN MUL (σ 1 , g, I, t) if r = 7 message call or contract creation; this forms part of the




payment for CREATE, CALL and CALLCODE. Finally, gas



ΞSNARKV (σ 1 , g, I, t) if r = 8
may be paid due to an increase in the usage of the memory.


Ξ(σ , g, I, t) otherwise
1
Over an account’s execution, the total fee for memory-
usage payable is proportional to smallest multiple of 32
(120) Let KEC(Ib ) = σ[c]c bytes that are required such that all memory indices
It is assumed that the client will have stored the pair (whether for read or write) are included in the range. This
(KEC(Ib ), Ib ) at some point prior in order to make the is paid for on a just-in-time basis; as such, referencing an
determination of Ib feasible. area of memory at least 32 bytes greater than any previ-
As can be seen, there are eight exceptions to the usage ously indexed memory will certainly result in an additional
of the general execution framework Ξ for evaluation of memory usage fee. Due to this fee it is highly unlikely
the message call: these are eight so-called ‘precompiled’ addresses will ever go above 32-bit bounds. That said,
contracts, meant as a preliminary piece of architecture implementations must be able to manage this eventuality.
that may later become native extensions. The eight con- Storage fees have a slightly nuanced behaviour—to in-
tracts in addresses 1 to 8 execute the elliptic curve public centivise minimisation of the use of storage (which corre-
key recovery function, the SHA2 256-bit hash scheme, the sponds directly to a larger state database on all nodes),
RIPEMD 160-bit hash scheme, the identity function, ar- the execution fee for an operation that clears an entry in
bitrary precision modular exponentiation, elliptic curve the storage is not only waived, a qualified refund is given;
addition, elliptic curve scalar multiplication and an elliptic in fact, this refund is effectively paid up-front since the
curve pairing check respectively. initial usage of a storage location costs substantially more
Their full formal definition is in Appendix E. than normal usage.
See Appendix H for a rigorous definition of the EVM
9. Execution Model gas cost.
The execution model specifies how the system state is 9.3. Execution Environment. In addition to the sys-
altered given a series of bytecode instructions and a small tem state σ, and the remaining gas for computation g,
tuple of environmental data. This is specified through a there are several pieces of important information used in
formal model of a virtual state machine, known as the the execution environment that the execution agent must
Ethereum Virtual Machine (EVM). It is a quasi-Turing- provide; these are contained in the tuple I:
complete machine; the quasi qualification comes from the • Ia , the address of the account which owns the code
fact that the computation is intrinsically bounded through that is executing.
a parameter, gas, which limits the total amount of compu- • Io , the sender address of the transaction that orig-
tation done. inated this execution.
9.1. Basics. The EVM is a simple stack-based architec- • Ip , the price of gas in the transaction that origi-
ture. The word size of the machine (and thus size of stack nated this execution.
items) is 256-bit. This was chosen to facilitate the Keccak- • Id , the byte array that is the input data to this
256 hash scheme and elliptic-curve computations. The execution; if the execution agent is a transaction,
memory model is a simple word-addressed byte array. The this would be the transaction data.
stack has a maximum size of 1024. The machine also has • Is , the address of the account which caused the
an independent storage model; this is similar in concept code to be executing; if the execution agent is a
to the memory but rather than a byte array, it is a word- transaction, this would be the transaction sender.
addressable word array. Unlike memory, which is volatile, • Iv , the value, in Wei, passed to this account as
storage is non volatile and is maintained as part of the part of the same procedure as execution; if the
system state. All locations in both storage and memory execution agent is a transaction, this would be the
are well-defined initially as zero. transaction value.
The machine does not follow the standard von Neu- • Ib , the byte array that is the machine code to be
mann architecture. Rather than storing program code executed.
in generally-accessible memory or storage, it is stored • IH , the block header of the present block.
separately in a virtual ROM interactable only through • Ie , the depth of the present message-call or
a specialised instruction. contract-creation (i.e. the number of CALLs or
The machine can have exceptional execution for several CREATEs being executed at present).
reasons, including stack underflows and invalid instruc- • Iw , the permission to make modifications to the
tions. Like the out-of-gas exception, they do not leave state.
state changes intact. Rather, the machine halts immedi- The execution model defines the function Ξ, which can
ately and reports the issue to the execution agent (either compute the resultant state σ 0 , the remaining gas g 0 , the
accrued substate A and the resultant output, o, given these 9.4.1. Machine State. The machine state µ is defined as
definitions. For the present context, we will define it as: the tuple (g, pc, m, i, s) which are the gas available, the
program counter pc ∈ N256 , the memory contents, the
(121) (σ 0 , g 0 , A, o) ≡ Ξ(σ, g, I) active number of words in memory (counting continuously
from position 0), and the stack contents. The memory
where we will remember that A, the accrued substate, contents µm are a series of zeroes of size 2256 .
is defined as the tuple of the self-destructs set As , the log For the ease of reading, the instruction mnemonics,
series Al , the touched accounts At and the refund balance written in small-caps (e.g. ADD), should be interpreted as
Ar : their numeric equivalents; the full table of instructions and
their specifics is given in Appendix H.
(122) A ≡ (As , Al , At , Ar )
For the purposes of defining Z, H and O, we define w
as the current operation to be executed:
9.4. Execution Overview. We must now define the Ξ (
function. In most practical implementations this will be Ib [µpc ] if µpc < kIb k
(136) w≡
modelled as an iterative progression of the pair comprising STOP otherwise
the full system state, σ and the machine state, µ. For-
mally, we define it recursively with a function X. This We also assume the fixed amounts of δ and α, specifying
uses an iterator function O (which defines the result of a the stack items removed and added, both subscriptable
single cycle of the state machine) together with functions on the instruction and an instruction cost function C eval-
Z which determines if the present state is an exceptional uating to the full cost, in gas, of executing the given
halting state of the machine and H, specifying the output instruction.
data of the instruction if and only if the present state is a
normal halting state of the machine. 9.4.2. Exceptional Halting. The exceptional halting func-
The empty sequence, denoted (), is not equal to the tion Z is defined as:
empty set, denoted ∅; this is important when interpreting (137)
the output of H, which evaluates to ∅ when execution is to Z(σ, µ, I) ≡ µg < C(σ, µ, I) ∨
continue but a series (potentially empty) when execution δw = ∅ ∨
should halt. kµs k < δw ∨
(w = JUMP ∧ µs [0] ∈ / D(Ib )) ∨
(123) Ξ(σ, g, I, T ) ≡ (σ 0, µ0g , A, o) (w = JUMPI ∧ µs [1] 6= 0 ∧
(σ 0 , µ0, A, ..., o) X (σ, µ, A0, I)

(124) ≡ µs [0] ∈
/ D(Ib )) ∨
(125) µg ≡ g (w = RETURNDATACOPY∧
µs [1] + µs [2] > kµo k) ∨
(126) µpc ≡ 0
kµs k − δw + αw > 1024 ∨ (¬Iw ∧ W (w, µ))
(127) µm ≡ (0, 0, ...)
(128) µi ≡ 0 where
(138)
(129) µs ≡ () W (w, µ) ≡ w ∈ {CREATE, SSTORE,
(130) µo ≡ () SELFDESTRUCT} ∨
LOG0 ≤ w ∧ w ≤ LOG4 ∨
(131) w ∈ {CALL, CALLCODE} ∧ µs [2] 6= 0
∅, µ, A0 , I, ∅


 if Z(σ, µ, I)
 ∅, µ0 , A0 , I, o

if w = REVERT This states that the execution is in an exceptional halt-
X (σ, µ, A, I) ≡ ing state if there is insufficient gas, if the instruction is
O(σ, µ, A, I) · o if o 6= ∅


 invalid (and therefore its δ subscript is undefined), if there
X O(σ, µ, A, I) otherwise are insufficient stack items, if a JUMP/JUMPI destination
is invalid, the new stack size would be larger than 1024 or
where
state modification is attempted during a static call. The as-
(132) o ≡ H(µ, I) tute reader will realise that this implies that no instruction
can, through its execution, cause an exceptional halt.
(133) (a, b, c, d) · e ≡ (a, b, c, d, e)
(134) µ0 ≡ µ except: 9.4.3. Jump Destination Validity. We previously used D
(135) µ0g ≡ µg − C(σ, µ, I) as the function to determine the set of valid jump desti-
nations given the code that is being run. We define this
Note that, when we evaluate Ξ, we drop the fourth as any position in the code occupied by a JUMPDEST
element I 0 and extract the remaining gas µ0g from the instruction.
resultant machine state µ0 . All such positions must be on valid instruction bound-
X is thus cycled (recursively here, but implementations aries, rather than sitting in the data portion of PUSH
are generally expected to use a simple iterative loop) until operations and must appear within the explicitly defined
either Z becomes true indicating that the present state is portion of the code (rather than in the implicitly defined
exceptional and that the machine must be halted and any STOP operations that trail it).
changes discarded or until H becomes a series (rather than Formally:
the empty set) indicating that the machine has reached a
controlled halt. (139) D(c) ≡ DJ (c, 0)
where: heaviest path is the block number of the leaf, equivalent

(140) to the number of blocks, not counting the unmined genesis
block, in the path. The longer the path, the greater the

 {} if i > kck
total mining effort that must have been done in order to


{i} ∪ D (c, N (i, c[i]))
J
DJ (c, i) ≡ arrive at the leaf. This is akin to existing schemes, such as
 if c[i] = JUMPDEST


 that employed in Bitcoin-derived protocols.
DJ (c, N (i, c[i])) otherwise Since a block header includes the difficulty, the header
where N is the next valid instruction position in the alone is enough to validate the computation done. Any
code, skipping the data of a PUSH instruction, if any: block contributes toward the total computation or total
(141) difficulty of a chain.
Thus we define the total difficulty of block B recursively

i + w − PUSH1 + 2

as:
N (i, w) ≡ if w ∈ [PUSH1, PUSH32]

i+1 otherwise

(153) Bt ≡ Bt0 + Bd
9.4.4. Normal Halting. The normal halting function H is (154) B0 ≡ P (BH )
defined:
(142)  As such given a block B, Bt is its total difficulty, B 0 is
HRETURN (µ) if w ∈ {RETURN, REVERT}
 its parent block and Bd is its difficulty.
H(µ, I) ≡ () if w ∈ {STOP, SELFDESTRUCT}

otherwise

∅
The data-returning halt operations, RETURN and
REVERT, have a special function HRETURN . Note also 11. Block Finalisation
the difference between the empty sequence and the empty The process of finalising a block involves four stages:
set as discussed here.
(1) Validate (or, if mining, determine) ommers;
9.5. The Execution Cycle. Stack items are added or
(2) validate (or, if mining, determine) transactions;
removed from the left-most, lower-indexed portion of the
(3) apply rewards;
series; all other items remain unchanged:
(4) verify (or, if mining, compute a valid) state and
≡ (σ 0 , µ0 , A0 , I)

(143) O (σ, µ, A, I) block nonce.
(144) ∆ ≡ αw − δw
(145) kµ0s k ≡ kµs k + ∆
(146) ∀x ∈ [αw , kµ0s k) : µ0s [x] ≡ µs [x − ∆] 11.1. Ommer Validation. The validation of ommer
headers means nothing more than verifying that each om-
The gas is reduced by the instruction’s gas cost and mer header is both a valid header and satisfies the relation
for most instructions, the program counter increments on of N th-generation ommer to the present block where N ≤ 6.
each cycle, for the three exceptions, we assume a function The maximum of ommer headers is two. Formally:
J, subscripted by one of two instructions, which evaluates
to the according value: ^
(155) kBU k 6 2 V (U) ∧ k(U, P (BH )H , 6)
(147) µ0g ≡ µg − C(σ, µ, I) U∈BU

JJUMP (µ) if w = JUMP

(148) µ0pc ≡ JJUMPI (µ) if w = JUMPI where k denotes the “is-kin” property:
 (156)
N (µpc , w) otherwise
 
false if n=0
In general, we assume the memory, self-destruct set and

k(U, H, n) ≡ s(U, H)
system state don’t change: 
∨ k(U, P (H)H , n − 1) otherwise

(149) µ0m ≡ µm
(150) µ0i ≡ µi and s denotes the “is-sibling” property:
(151) A0 ≡ A (157)
(152) σ0 ≡ σ s(U, H) ≡ (P (H) = P (U ) ∧ H 6= U ∧ U ∈ / B(H)U )
However, instructions do typically alter one or several
components of these values. Altered components listed by where B(H) and P (H) are the block and the parent block
instruction are noted in Appendix H, alongside values for of the corresponding header H respectively.
α and δ and a formal description of the gas requirements.
10. Blocktree to Blockchain 11.2. Transaction Validation. The given gasUsed

The canonical blockchain is a path from root to leaf must correspond faithfully to the transactions listed: BH g ,
through the entire block tree. In order to have consensus the total gas used in the block, must be equal to the
over which path it is, conceptually we identify the path accumulated gas used according to the final transaction:
that has had the most computation done upon it, or, the
heaviest path. Clearly one factor that helps determine the (158) BH g = `(R)u
11.3. Reward Application. The application of rewards such transaction):

to a block involves raising the balance of the accounts of (
the beneficiary address of the block and each ommer by a Γ(B) if n < 0
(170) σ[n] =
certain amount. We raise the block’s beneficiary account Υ(σ[n − 1], BT [n]) otherwise
by Rblock ; for each ommer, we raise the block’s beneficiary In the case of BR [n]u , we take a similar approach defin-
1
by an additional 32 of the block reward and the benefi- ing each item as the gas used in evaluating the correspond-
ciary of the ommer gets rewarded depending on the block ing transaction summed with the previous item (or zero,
number. Formally we define the function Ω: if it is the first), giving us a running total:
(159) 
0
 if n < 0
Ω(B, σ) ≡ σ0 : σ0 = σ except: (171) R[n]u = Υg (σ[n − 1], BT [n])

kBU k 
(160) σ 0 [BH c ]b +R[n − 1]u otherwise

= σ[BH c ]b + 1 + Rblock
32
(161) For R[n]l , we utilise the Υl function that we conve-
niently defined in the transaction execution function.
∀U ∈ BU :
(172) R[n]l = Υl (σ[n − 1], BT [n])
(
0 ∅ if σ[Uc ] = ∅ ∧ R = 0
σ [Uc ] =
a0 otherwise We define R[n]z in a similar manner.
(162) a 0
≡ (σ[Uc ]n , σ[Uc ]b + R, σ[Uc ]s , σ[Uc ]c ) (173) R[n]z = Υz (σ[n − 1], BT [n])

1 Finally, we define Π as the new state given the block re-
(163) R ≡ 1 + (Ui − BH i ) Rblock
8 ward function Ω applied to the final transaction’s resultant
If there are collisions of the beneficiary addresses be- state, `(σ):
tween ommers and the block (i.e. two ommers with the (174) Π(σ, B) ≡ Ω(B, `(σ))
same beneficiary address or an ommer with the same bene-
ficiary address as the present block), additions are applied Thus the complete block-transition mechanism is de-
cumulatively. fined, except for PoW, the proof-of-work function.
We define the block reward as 3 Ether: 11.5. Mining Proof-of-Work. The mining proof-of-
(164) Let Rblock = 3 × 1018 work (PoW) exists as a cryptographically secure nonce
that proves beyond reasonable doubt that a particular
11.4. State & Nonce Validation. We may now define amount of computation has been expended in the deter-
the function, Γ, that maps a block B to its initiation state: mination of some token value n. It is utilised to enforce
(165) the blockchain security by giving meaning and credence
to the notion of difficulty (and, by extension, total dif-
(
σ 0 kern10pc if P (BH ) = ∅
Γ(B) ≡ ficulty). However, since mining new blocks comes with
σ i : TRIE(LS (σ i )) = P (BH )H r otherwise
an attached reward, the proof-of-work not only functions
Here, TRIE(LS (σ i )) means the hash of the root node of as a method of securing confidence that the blockchain
a trie of state σ i ; it is assumed that implementations will will remain canonical into the future, but also as a wealth
store this in the state database, which is trivial and efficient distribution mechanism.
since the trie is by nature an immutable data structure. For both reasons, there are two important goals of the
And finally we define Φ, the block transition function, proof-of-work function; firstly, it should be as accessible as
which maps an incomplete block B to a complete block possible to as many people as possible. The requirement
B0: of, or reward from, specialised and uncommon hardware
should be minimised. This makes the distribution model
(166) Φ(B) ≡ B0 : B0 = B∗ except: as open as possible, and, ideally, makes the act of mining a
256
2 simple swap from electricity to Ether at roughly the same
(167) Bn0 = n: x6
Hd rate for anyone around the world.
0 ∗ Secondly, it should not be possible to make super-linear
(168) Bm = m with (x, m) = PoW(Bn , n, d)
profits, and especially not so with a high initial barrier.
(169) B∗ ≡ B except: Br∗ = r(Π(Γ(B), B))
Such a mechanism allows a well-funded adversary to gain
With d being a dataset as specified in appendix J. a troublesome amount of the network’s total mining power
As specified at the beginning of the present work, Π is and as such gives them a super-linear reward (thus skewing
the state-transition function, which is defined in terms of distribution in their favour) as well as reducing the network
Ω, the block finalisation function and Υ, the transaction- security.
evaluation function, both now well-defined. One plague of the Bitcoin world is ASICs. These are
As previously detailed, R[n]z , R[n]l and R[n]u are the specialised pieces of compute hardware that exist only to
nth corresponding status code, logs and cumulative gas do a single task (Smith [1997]). In Bitcoin’s case the task is
used after each transaction (R[n]b , the fourth component the SHA256 hash function (Courtois et al. [2014]). While
in the tuple, has already been defined in terms of the logs). ASICs exist for a proof-of-work function, both goals are
We also define the nth state σ[n], which is defined simply placed in jeopardy. Because of this, a proof-of-work func-
as the state resulting from applying the corresponding tion that is ASIC-resistant (i.e. difficult or economically
transaction to the state resulting from the previous trans- inefficient to implement in specialised compute hardware)
action (or the block’s initial state in the case of the first has been identified as the proverbial silver bullet.
Two directions exist for ASIC resistance; firstly make utilises the data feed—to determine how much trust can
it sequential memory-hard, i.e. engineer the function such be placed in any single data feed.
that the determination of the nonce requires a lot of mem- The general pattern involves a single contract within
ory and bandwidth such that the memory cannot be used Ethereum which, when given a message call, replies with
in parallel to discover multiple nonces simultaneously. The some timely information concerning an external phenome-
second is to make the type of computation it would need to non. An example might be the local temperature of New
do general-purpose; the meaning of “specialised hardware” York City. This would be implemented as a contract that
for a general-purpose task set is, naturally, general purpose returned that value of some known point in storage. Of
hardware and as such commodity desktop computers are course this point in storage must be maintained with the
likely to be pretty close to “specialised hardware” for the correct such temperature, and thus the second part of the
task. For Ethereum 1.0 we have chosen the first path. pattern would be for an external server to run an Ethereum
More formally, the proof-of-work function takes the node, and immediately on discovery of a new block, creates
form of PoW: a new valid transaction, sent to the contract, updating said
(175) value in storage. The contract’s code would accept such
2256 updates only from the identity contained on said server.
m = Hm ∧ n 6 with (m, n) = PoW(Hn , Hn , d)
Hd
12.2. Random Numbers. Providing random numbers
Where Hn is the new block’s header but without the within a deterministic system is, naturally, an impossible
nonce and mix-hash components; Hn is the nonce of the task. However, we can approximate with pseudo-random
header; d is a large data set needed to compute the mix- numbers by utilising data which is generally unknowable
Hash and Hd is the new block’s difficulty value (i.e. the at the time of transacting. Such data might include the
block difficulty from section 10). PoW is the proof-of-work block’s hash, the block’s timestamp and the block’s benefi-
function which evaluates to an array with the first item ciary address. In order to make it hard for malicious miners
being the mixHash and the second item being a pseudo- to control those values, one should use the BLOCKHASH
random number cryptographically dependent on H and d. operation in order to use hashes of the previous 256 blocks
The underlying algorithm is called Ethash and is described as pseudo-random numbers. For a series of such numbers,
below. a trivial solution would be to add some constant amount
11.5.1. Ethash. Ethash is the PoW algorithm for Ethereum and hashing the result.
1.0. It is the latest version of Dagger-Hashimoto, intro-
duced by Buterin [2013b] and Dryja [2014], although it 13. Future Directions
can no longer appropriately be called that since many of The state database won’t be forced to maintain all past
the original features of both algorithms were drastically state trie structures into the future. It should maintain
changed with R&D from February 2015 until May 4 2015 an age for each node and eventually discard nodes that
(Jentzsch [2015]). The general route that the algorithm are neither recent enough nor checkpoints. Checkpoints,
takes is as follows: or a set of nodes in the database that allow a particular
There exists a seed which can be computed for each block’s state trie to be traversed, could be used to place a
block by scanning through the block headers up until that maximum limit on the amount of computation needed in
point. From the seed, one can compute a pseudorandom order to retrieve any state throughout the blockchain.
cache, Jcacheinit bytes in initial size. Light clients store Blockchain consolidation could be used in order to re-
the cache. From the cache, we can generate a dataset, duce the amount of blocks a client would need to download
Jdatasetinit bytes in initial size, with the property that to act as a full, mining, node. A compressed archive of the
each item in the dataset depends on only a small number trie structure at given points in time (perhaps one in every
of items from the cache. Full clients and miners store the 10,000th block) could be maintained by the peer network,
dataset. The dataset grows linearly with time. effectively recasting the genesis block. This would reduce
Mining involves grabbing random slices of the dataset the amount to be downloaded to a single archive plus a
and hashing them together. Verification can be done with hard maximum limit of blocks.
low memory by using the cache to regenerate the specific Finally, blockchain compression could perhaps be con-
pieces of the dataset that you need, so you only need to ducted: nodes in state trie that haven’t sent/received a
store the cache. The large dataset is updated once every transaction in some constant amount of blocks could be
Jepoch blocks, so the vast majority of a miner’s effort will thrown out, reducing both Ether-leakage and the growth
be reading the dataset, not making changes to it. The of the state database.
mentioned parameters as well as the algorithm is explained
in detail in appendix J. 13.1. Scalability. Scalability remains an eternal concern.
With a generalised state transition function, it becomes dif-
12. Implementing Contracts ficult to partition and parallelise transactions to apply the
divide-and-conquer strategy. Unaddressed, the dynamic
There are several patterns of contracts engineering that
value-range of the system remains essentially fixed and as
allow particular useful behaviours; two of these that we
the average transaction value increases, the less valuable of
will briefly discuss are data feeds and random numbers.
them become ignored, being economically pointless to in-
12.1. Data Feeds. A data feed contract is one which pro- clude in the main ledger. However, several strategies exist
vides a single service: it gives access to information from that may potentially be exploited to provide a considerably
the external world within Ethereum. The accuracy and more scalable protocol.
timeliness of this information is not guaranteed and it is Some form of hierarchical structure, achieved by either
the task of a secondary contract author—the contract that consolidating smaller lighter-weight chains into the main
block or building the main block through the incremen- Vitalik Buterin. EIP-100: Change difficulty adjust-
tal combination and adhesion (through proof-of-work) of ment to target mean block time including uncles,
smaller transaction sets may allow parallelisation of trans- April 2016. URL https://github.com/ethereum/EIPs/
action combination and block-building. Parallelism could blob/master/EIPS/eip-100.md.
also come from a prioritised set of parallel blockchains, Nicolas T. Courtois, Marek Grajek, and Rahul Naik.
consolidating each block and with duplicate or invalid Optimizing SHA256 in Bitcoin Mining, pages 131–
transactions thrown out accordingly. 144. Springer Berlin Heidelberg, Berlin, Heidel-
Finally, verifiable computation, if made generally avail- berg, 2014. ISBN 978-3-662-44893-9. doi: 10.
able and efficient enough, may provide a route to allow the 1007/978-3-662-44893-9 12. URL https://doi.org/10.
proof-of-work to be the verification of final state. 1007/978-3-662-44893-9_12.
B.A. Davey and H.A. Priestley. Introduction to lattices
14. Conclusion and order. 2nd ed. Cambridge: Cambridge University
Press, 2nd ed. edition, 2002. ISBN 0-521-78451-4/pbk.
We have introduced, discussed and formally defined the Thaddeus Dryja. Hashimoto: I/O bound proof of
protocol of Ethereum. Through this protocol the reader work, 2014. URL http://diyhpl.us/~bryan/papers2/
may implement a node on the Ethereum network and join bitcoin/meh/hashimoto.pdf.
others in a decentralised secure social operating system. Cynthia Dwork and Moni Naor. Pricing via pro-
Contracts may be authored in order to algorithmically cessing or combatting junk mail. In In 12th An-
specify and autonomously enforce rules of interaction. nual International Cryptology Conference, pages 139–
147, 1992. URL http://www.wisdom.weizmann.ac.il/
15. Acknowledgements
~naor/PAPERS/pvp.pdf.
Many thanks to Aeron Buchanan for authoring the Phong Vo Glenn Fowler, Landon Curt Noll. FowlerNol-
Homestead revisions, Christoph Jentzsch for authoring the lVo hash function, 1991. URL http://www.isthe.com/
Ethash algorithm and Yoichi Hirai for doing most of the chongo/tech/comp/fnv/index.html.
EIP-150 changes. Important maintenance, useful correc- Nils Gura, Arun Patel, Arvinderpal Wander, Hans Eberle,
tions and suggestions were provided by a number of others and Sheueling Chang Shantz. Comparing elliptic curve
from the Ethereum DEV organisation and Ethereum com- cryptography and RSA on 8-bit CPUs. In Cryptographic
munity at large including Gustav Simonsson, Pawel Bylica, Hardware and Embedded Systems-CHES 2004, pages
Jutta Steiner, Nick Savers, Viktor Trón, Marko Simovic, 119–132. Springer, 2004. URL https://www.iacr.org/
Giacomo Tazzari and, of course, Vitalik Buterin. archive/ches2004/31560117/31560117.pdf.
Christoph Jentzsch. Commit date for ethash, 2015. URL
16. Availability https://github.com/ethereum/yellowpaper/commit/
77a8cf2428ce245bf6e2c39c5e652ba58a278666#
The source of this paper is maintained at https: commitcomment-24644869.
//github.com/ethereum/yellowpaper/. An auto- Don Johnson, Alfred Menezes, and Scott Van-
generated PDF is located at https://ethereum.github. stone. The Elliptic Curve Digital Signa-
io/yellowpaper/paper.pdf. ture Algorithm (ECDSA), 2001. URL https:
//web.archive.org/web/20170921160141/http://
References cs.ucsb.edu/~koc/ccs130h/notes/ecdsa-cert.pdf.
Accessed 21 September 2017, but the original link was
Jacob Aron. BitCoin software finds new life. New Scientist,
inaccessible on 19 October 2017. Refer to section 6.2 for
213(2847):20, 2012. URL http://www.sciencedirect.
ECDSAPUBKEY, and section 7 for ECDSASIGN and
com/science/article/pii/S0262407912601055.
ECDSARECOVER.
Adam Back. Hashcash - Amortizable Publicly Auditable
Sergio Demian Lerner. Strict Memory Hard Hashing Func-
Cost-Functions, 2002. URL http://www.hashcash.org/
tions, 2014. URL http://www.hashcash.org/papers/
papers/amortizable.pdf.
memohash.pdf.
Guido Bertoni, Joan Daemen, Michal Peeters, and
Mark Miller. The Future of Law. In pa-
Gilles Van Assche. The KECCAK SHA-3 sub-
per delivered at the Extro 3 Conference (August
mission, 2011. URL https://keccak.team/files/
9), 1997. URL https://drive.google.com/file/d/
Keccak-submission-3.pdf.
0Bw0VXJKBgYPMS0J2VGIyWWlocms/edit?usp=sharing.
Roman Boutellier and Mareike Heinzen. Pirates, Pio-
Satoshi Nakamoto. Bitcoin: A peer-to-peer electronic cash
neers, Innovators and Imitators. In Growth Through
system, 2008. URL http://www.bitcoin.org/bitcoin.
Innovation, pages 85–96. Springer, 2014. URL https:
pdf.
//www.springer.com/gb/book/9783319040158.
Meni Rosenfeld, Yoni Assia, Vitalik Buterin, m li-
Vitalik Buterin. Ethereum: A Next-Generation Smart
orhakiLior, Oded Leiba, Assaf Shomer, and Eli-
Contract and Decentralized Application Platform,
ran Zach. Colored Coins Protocol Specification,
2013a. URL https://github.com/ethereum/wiki/
2012. URL https://github.com/Colored-Coins/
wiki/White-Paper.
Colored-Coins-Protocol-Specification.
Vitalik Buterin. Dagger: A Memory-Hard to Compute,
Afri Schoedon and Vitalik Buterin. EIP-649: Metropo-
Memory-Easy to Verify Scrypt Alternative, 2013b. URL
lis difficulty bomb delay and block reward reduction,
http://www.hashcash.org/papers/dagger.html.
June 2017. URL https://github.com/ethereum/EIPs/
Vitalik Buterin. EIP-2: Homestead hard-fork changes,
blob/master/EIPS/eip-649.md.
2015. URL https://github.com/ethereum/EIPs/
blob/master/EIPS/eip-2.md.
Michael John Sebastian Smith. Application-Specific Nick Szabo. Formalizing and securing relation-
Integrated Circuits. Addison-Wesley, 1997. ISBN ships on public networks. First Monday, 2(9),
0201500221. 1997. URL http://firstmonday.org/ojs/index.php/
Yonatan Sompolinsky and Aviv Zohar. Accelerating bit- fm/article/view/548.
coin’s transaction processing. fast money grows on trees, Vivek Vishnumurthy, Sangeeth Chandrakumar, and
not chains, 2013. URL https://eprint.iacr.org/ Emin Gn Sirer. KARMA: A secure economic framework
2013/881. for peer-to-peer resource sharing, 2003. URL https://
Simon Sprankel. Technical Basis of Digital Currencies, www.cs.cornell.edu/people/egs/papers/karma.pdf.
2013. URL http://www.coderblog.de/wp-content/ J. R. Willett. MasterCoin Complete Specification, 2013.
uploads/technical-basis-of-digital-currencies. URL https://github.com/mastercoin-MSC/spec.
pdf.
Appendix A. Terminology
External Actor: A person or other entity able to interface to an Ethereum node, but external to the world of
Ethereum. It can interact with Ethereum through depositing signed Transactions and inspecting the blockchain
and associated state. Has one (or more) intrinsic Accounts.
Address: A 160-bit code used for identifying Accounts.
Account: Accounts have an intrinsic balance and transaction count maintained as part of the Ethereum state.
They also have some (possibly empty) EVM Code and a (possibly empty) Storage State associated with them.
Though homogenous, it makes sense to distinguish between two practical types of account: those with empty
associated EVM Code (thus the account balance is controlled, if at all, by some external entity) and those with
non-empty associated EVM Code (thus the account represents an Autonomous Object). Each Account has a
single Address that identifies it.
Transaction: A piece of data, signed by an External Actor. It represents either a Message or a new Autonomous
Object. Transactions are recorded into each block of the blockchain.
Autonomous Object: A notional object existent only within the hypothetical state of Ethereum. Has an intrinsic
address and thus an associated account; the account will have non-empty associated EVM Code. Incorporated
only as the Storage State of that account.
Storage State: The information particular to a given Account that is maintained between the times that the
Account’s associated EVM Code runs.
Message: Data (as a set of bytes) and Value (specified as Ether) that is passed between two Accounts, either
through the deterministic operation of an Autonomous Object or the cryptographically secure signature of the
Transaction.
Message Call: The act of passing a message from one Account to another. If the destination account is associated
with non-empty EVM Code, then the VM will be started with the state of said Object and the Message acted
upon. If the message sender is an Autonomous Object, then the Call passes any data returned from the VM
operation.
Gas: The fundamental network cost unit. Paid for exclusively by Ether (as of PoC-4), which is converted freely to
and from Gas as required. Gas does not exist outside of the internal Ethereum computation engine; its price is
set by the Transaction and miners are free to ignore Transactions whose Gas price is too low.
Contract: Informal term used to mean both a piece of EVM Code that may be associated with an Account or an
Autonomous Object.
Object: Synonym for Autonomous Object.
App: An end-user-visible application hosted in the Ethereum Browser.
Ethereum Browser: (aka Ethereum Reference Client) A cross-platform GUI of an interface similar to a simplified
browser (a la Chrome) that is able to host sandboxed applications whose backend is purely on the Ethereum
protocol.
Ethereum Virtual Machine: (aka EVM) The virtual machine that forms the key part of the execution model
for an Account’s associated EVM Code.
Ethereum Runtime Environment: (aka ERE) The environment which is provided to an Autonomous Object
executing in the EVM. Includes the EVM but also the structure of the world state on which the EVM relies for
certain I/O instructions including CALL & CREATE.
EVM Code: The bytecode that the EVM can natively execute. Used to formally specify the meaning and
ramifications of a message to an Account.
EVM Assembly: The human-readable form of EVM-code.
LLL: The Lisp-like Low-level Language, a human-writable language used for authoring simple contracts and general
low-level language toolkit for trans-compiling to.
Appendix B. Recursive Length Prefix

This is a serialisation method for encoding arbitrarily structured binary data (byte arrays).
We define the set of possible structures T:

(176) T ≡ L]B
(177) L ≡ {t : t = (t[0], t[1], ...) ∧ ∀n < ktk : t[n] ∈ T}
(178) B ≡ {b : b = (b[0], b[1], ...) ∧ ∀n < kbk : b[n] ∈ O}
Where O is the set of (8-bit) bytes. Thus B is the set of all sequences of bytes (otherwise known as byte arrays, and
a leaf if imagined as a tree), L is the set of all tree-like (sub-)structures that are not a single leaf (a branch node if
imagined as a tree) and T is the set of all byte arrays and such structural sequences. The disjoint union ] is needed only
to distinguish the empty byte array () ∈ B from the empty list () ∈ L, which are encoded differently as defined below; as
common, we will abuse notation and leave the disjoint union indices implicit, inferable from context.
We define the RLP function as RLP through two sub-functions, the first handling the instance when the value is a byte
array, the second when it is a sequence of further values:
(
Rb (x) if x ∈ B
(179) RLP(x) ≡
Rl (x) otherwise
If the value to be serialised is a byte array, the RLP serialisation takes one of three forms:
• If the byte array contains solely a single byte and that single byte is less than 128, then the input is exactly equal
to the output.
• If the byte array contains fewer than 56 bytes, then the output is equal to the input prefixed by the byte equal to
the length of the byte array plus 128.
• Otherwise, the output is equal to the input, provided that it contains fewer than 264 bytes, prefixed by the
minimal-length byte array which when interpreted as a big-endian integer is equal to the length of the input byte
array, which is itself prefixed by the number of bytes required to faithfully encode this length value plus 183.
Byte arrays containing 264 or more bytes cannot be encoded. This restriction ensures that the first byte of the encoding
of a byte array is always below 192, and thus it can be readily distinguished from the encodings of sequences in L.
Formally, we define Rb :


 x if kxk = 1 ∧ x[0] < 128

(128 + kxk) · x else if kxk < 56
(180) Rb (x) ≡

 183 + BE(kxk) · BE(kxk) · x else if kxk < 264


∅ otherwise
kbk−1
X
(181) BE(x) ≡ (b0 , b1 , ...) : b0 6= 0 ∧ x = bn · 256kbk−1−n
n=0
(182) (x1 , ..., xn ) · (y1 , ..., ym ) = (x1 , ..., xn , y1 , ..., ym )
Thus BE is the function that expands a non-negative integer value to a big-endian byte array of minimal length and
the dot operator performs sequence concatenation.
If instead, the value to be serialised is a sequence of other items then the RLP serialisation takes one of two forms:
• If the concatenated serialisations of each contained item is less than 56 bytes in length, then the output is equal
to that concatenation prefixed by the byte equal to the length of this byte array plus 192.
• Otherwise, the output is equal to the concatenated serialisations, provided that they contain fewer than 264 bytes,
prefixed by the minimal-length byte array which when interpreted as a big-endian integer is equal to the length
of the concatenated serialisations byte array, which is itself prefixed by the number of bytes required to faithfully
encode this length value plus 247.
Sequences whose concatenated serialized items contain 264 or more bytes cannot be encoded. This restriction ensures
that the first byte of the encoding does not exceed 255 (otherwise it would not be a byte).
Thus we finish by formally defining Rl :

(192 + ks(x)k)


· s(x)

if s(x) 6= ∅ ∧ ks(x)k < 56
(183) Rl (x) ≡ 247 + BE(ks(x)k) · BE(ks(x)k) · s(x) else if s(x) 6= ∅ ∧ ks(x)k < 264

otherwise

∅
(
RLP(x[0]) · RLP(x[1]) · ... if ∀i : RLP(x[i]) 6= ∅
(184) s(x) ≡
∅ otherwise
If RLP is used to encode a scalar, defined only as a non-negative integer (in N, or in Nx for any x), it must be encoded
as the shortest byte array whose big-endian interpretation is the scalar. Thus the RLP of some non-negative integer i is
defined as:
(185) RLP(i : i ∈ N) ≡ RLP(BE(i))
When interpreting RLP data, if an expected fragment is decoded as a scalar and leading zeroes are found in the byte
sequence, clients are required to consider it non-canonical and treat it in the same manner as otherwise invalid RLP data,
dismissing it completely.
There is no specific canonical encoding format for signed or floating-point values.
Appendix C. Hex-Prefix Encoding

Hex-prefix encoding is an efficient method of encoding an arbitrary number of nibbles as a byte array. It is able to
store an additional flag which, when used in the context of the trie (the only context in which it is used), disambiguates
between node types.
It is defined as the function HP which maps from a sequence of nibbles (represented by the set Y) together with a
boolean value to a sequence of bytes (represented by the set B):
(
(16f (t), 16x[0] + x[1], 16x[2] + x[3], ...) if kxk is even
(186) HP(x, t) : x ∈ Y ≡
(16(f (t) + 1) + x[0], 16x[1] + x[2], 16x[3] + x[4], ...) otherwise
(
2 if t 6= 0
(187) f (t) ≡
0 otherwise
Thus the high nibble of the first byte contains two flags; the lowest bit encoding the oddness of the length and the
second-lowest encoding the flag t. The low nibble of the first byte is zero in the case of an even number of nibbles and the
first nibble in the case of an odd number. All remaining nibbles (now an even number) fit properly into the remaining
bytes.
Appendix D. Modified Merkle Patricia Tree

The modified Merkle Patricia tree (trie) provides a persistent data structure to map between arbitrary-length binary
data (byte arrays). It is defined in terms of a mutable data structure to map between 256-bit binary fragments and
arbitrary-length binary data, typically implemented as a database. The core of the trie, and its sole requirement in terms
of the protocol specification, is to provide a single value that identifies a given set of key-value pairs, which may be either
a 32-byte sequence or the empty byte sequence. It is left as an implementation consideration to store and maintain the
structure of the trie in a manner that allows effective and efficient realisation of the protocol.
Formally, we assume the input value I, a set containing pairs of byte sequences with unique keys:
(188) I = {(k0 ∈ B, v0 ∈ B), (k1 ∈ B, v1 ∈ B), ...}
When considering such a sequence, we use the common numeric subscript notation to refer to a tuple’s key or value,
thus:
(189) ∀I ∈ I : I ≡ (I0 , I1 )
Any series of bytes may also trivially be viewed as a series of nibbles, given an endian-specific notation; here we assume
big-endian. Thus:
(190) y(I) = {(k00 ∈ Y, v0 ∈ B), (k01 ∈ Y, v1 ∈ B), ...}
(
bkn [i ÷ 2] ÷ 16c if i is even
(191) ∀n : ∀i < 2kkn k : k0n [i] ≡
kn [bi ÷ 2c] mod 16 otherwise
We define the function TRIE, which evaluates to the root of the trie that represents this set when encoded in this
structure:
(192) TRIE(I) ≡ KEC(c(I, 0))
We also assume a function n, the trie’s node cap function. When composing a node, we use RLP to encode the
structure. As a means of reducing storage complexity, for nodes whose composed RLP is fewer than 32 bytes, we store
the RLP directly; for those larger we assert prescience of the byte array whose Keccak hash evaluates to our reference.
Thus we define in terms of c, the node composition function:

()
 if I = ∅
(193) n(I, i) ≡ c(I, i) if kc(I, i)k < 32

KEC(c(I, i)) otherwise

In a manner similar to a radix tree, when the trie is traversed from root to leaf, one may build a single key-value pair.
The key is accumulated through the traversal, acquiring a single nibble from each branch node (just as with a radix tree).
Unlike a radix tree, in the case of multiple keys sharing the same prefix or in the case of a single key having a unique
suffix, two optimising nodes are provided. Thus while traversing, one may potentially acquire multiple nibbles from each
of the other two node types, extension and leaf. There are three kinds of nodes in the trie:
Leaf: A two-item structure whose first item corresponds to the nibbles in the key not already accounted for by the
accumulation of keys and branches traversed from the root. The hex-prefix encoding method is used and the
second parameter to the function is required to be 1.
Extension: A two-item structure whose first item corresponds to a series of nibbles of size greater than one that
are shared by at least two distinct keys past the accumulation of the keys of nibbles and the keys of branches as
traversed from the root. The hex-prefix encoding method is used and the second parameter to the function is
required to be 0.
Branch: A 17-item structure whose first sixteen items correspond to each of the sixteen possible nibble values for
the keys at this point in their traversal. The 17th item is used in the case of this being a terminator node and
thus a key being ended at this point in its traversal.
A branch is then only used when necessary; no branch nodes may exist that contain only a single non-zero entry. We
may formally define this structure with the structural composition function c:
(194)


 RLP HP(I0 [i..(kI0 k − 1)], 1), I1 if kIk = 1 where ∃I : I ∈ I


RLP HP(I0 [i..(j − 1)], 0), n(I, if i 6= j where j = max{x : ∃l : klk = x ∧ ∀I ∈ I : I0 [0..(x − 1)] = l}


 j)
c(I, i) ≡ RLP (u(0), u(1), ..., u(15), v)

 otherwise where u(j) ≡ n({I ( : I ∈ I ∧ I0 [i] = j}, i + 1)

I1 if ∃I : I ∈ I ∧ kI0 k = i




 v =
() otherwise

D.1. Trie Database. Thus no explicit assumptions are made concerning what data is stored and what is not, since
that is an implementation-specific consideration; we simply define the identity function mapping the key-value set I
to a 32-byte hash and assert that only a single such hash exists for any I, which though not strictly true is accurate
within acceptable precision given the Keccak hash’s collision resistance. In reality, a sensible implementation will not fully
recompute the trie root hash for each set.
A reasonable implementation will maintain a database of nodes determined from the computation of various tries or,
more formally, it will memoise the function c. This strategy uses the nature of the trie to both easily recall the contents of
any previous key-value set and to store multiple such sets in a very efficient manner. Due to the dependency relationship,
Merkle-proofs may be constructed with an O(log N ) space requirement that can demonstrate a particular leaf must exist
within a trie of a given root hash.
Appendix E. Precompiled Contracts

For each precompiled contract, we make use of a template function, ΞPRE , which implements the out-of-gas checking.
(
(∅, 0, A0 , ()) if g < gr
(195) ΞPRE (σ, g, I, T ) ≡ 0
(σ, g − gr , A , o) otherwise
The precompiled contracts each use these definitions and provide specifications for the o (the output data) and gr , the
gas requirements.
We define ΞECREC as a precompiled contract for the elliptic curve digital signature algorithm (ECDSA) public key
recovery function (ecrecover). See Appendix F for the definition of the function ECDSARECOVER. We also define d to be
the input data, well-defined for an infinite length by appending zeroes as required. In the case of an invalid signature
(ECDSARECOVER(h, v, r, s) = ∅), we return no output.
(196) ΞECREC ≡ ΞPRE where:

(197) gr = 3000
(
0 if ECDSARECOVER(h, v, r, s) = ∅
(198) kok =
32 otherwise
(199) if kok = 32 :
(200) o[0..11] = 0

(201) o[12..31] = KEC ECDSARECOVER(h, v, r, s) [12..31] where:
(202) d[0..(kId k − 1)] = Id
(203) d[kId k..] = (0, 0, ...)
(204) h = d[0..31]
(205) v = d[32..63]
(206) r = d[64..95]
(207) s = d[96..127]
We define ΞSHA256 and ΞRIP160 as precompiled contracts implementing the SHA2-256 and RIPEMD-160 hash functions
respectively. Their gas usage is dependent on the input data size, a factor rounded up to the nearest number of words.
(208) ΞSHA256 ≡ ΞPRE where:

l kI k m
d
(209) gr = 60 + 12
32
(210) o[0..31] = SHA256(Id )
(211) ΞRIP160 ≡ ΞPRE where:
l kI k m
d
(212) gr = 600 + 120
32
(213) o[0..11] = 0
(214) o[12..31] = RIPEMD160(Id )
For the purposes here, we assume we have well-defined standard cryptographic functions for RIPEMD-160 and
SHA2-256 of the form:
(215) SHA256(i ∈ B) ≡ o ∈ B32

(216) RIPEMD160(i ∈ B) ≡ o ∈ B20
The fourth contract, the identity function ΞID simply defines the output as the input:
(217) ΞID ≡ ΞPRE where:
l kI k m
d
(218) gr = 15 + 3
32
(219) o = Id
The fifth contract performs arbitrary-precision exponentiation under modulo. Here, 00 is taken to be one, and x mod 0
is zero for all x. The first word in the input specifies the number of bytes that the first non-negative integer B occupies.
The second word in the input specifies the number of bytes that the second non-negative integer E occupies. The third
word in the input specifies the number of bytes that the third non-negative integer M occupies. These three words are
followed by B, E and M . The rest of the input is discarded. Whenever the input is too short, the missing bytes are
considered to be zero. The output is encoded big-endian into the same format as M ’s.
(220) ΞEXPMOD ≡ ΞPRE except:

$ %
f max(`M , `B ) max(`0E , 1)

(221) gr =
Gquaddivisor

2
x
 if x ≤ 64

 2
 x


(222) f (x) ≡ + 96x − 3072 if 64 < x ≤ 1024
 4

x2


+ 480x − 199680 otherwise



16


 0 if È ≤ 32 ∧ E = 0

blog (E)c if È ≤ 32 ∧ E 6= 0
(223) `0E = 2


 8(` E − 32) + blog2 (i[(96 + `B )..(127 + `B )])c if 32 < È ∧ i[(96 + `B )..(127 + `B )] 6= 0
8(È − 32)

otherwise

(224) o = B E mod M ∈ N8`M
(225) `B ≡ i[0..31]
(226) È ≡ i[32..63]
(227) `M ≡ i[64..95]
(228) B ≡ i[96..(95 + `B )]
(229) E ≡ i[(96 + `B )..(95 + `B + È )]
(230) M ≡ i[(96 + `B + È )..(95 + `B + È + `M )]
(
Id [x] if x < kId k
(231) i[x] ≡
0 otherwise
E.1. zkSNARK Related Precompiled Contracts. We choose two numbers, both of which are prime.
(232) p ≡ 21888242871839275222246405745257275088696311157297823662689037894645226208583
(233) q ≡ 21888242871839275222246405745257275088548364400416034343698204186575808495617
Since p is a prime number, {0, 1, . . . , p − 1} forms a field with addition and multiplication modulo p. We call this field Fp .
We define a set C1 with
(234) C1 ≡ {(X, Y ) ∈ Fp × Fp | Y 2 = X 3 + 3} ∪ {(0, 0)}
We define a binary operation + on C1 for distinct elements (X1 , Y1 ), (X2 , Y2 ) with

(
(X, Y ) if X1 6= X2
(235) (X1 , Y1 ) + (X2 , Y2 ) ≡
(0, 0) otherwise
Y2 − Y1
λ ≡
X2 − X1
X ≡ λ2 − X1 − X2
Y ≡ λ(X1 − X) − Y1
In the case where (X1 , Y1 ) = (X2 , Y2 ), we define + on C1 with

(
(X, Y ) if Y1 6= 0
(236) (X1 , Y1 ) + (X2 , Y2 ) ≡
(0, 0) otherwise
3X12
λ ≡
2Y1
X ≡ λ2 − 2X1
Y ≡ λ(X1 − X) − Y1
(C1 , +) is known to form a group. We define scalar multiplication · with
(237) n · P ≡ (0, 0) + P + · · · + P
| {z }
n
for a natural number n and a point P in C1 .

We define P1 to be a point (1, 2) on C1 . Let G1 be the subgroup of (C1 , +) generated by P1 . G1 is known to be a
cyclic group of order q. For a point P in G1 , we define logP1 (P ) to be the smallest natural number n satisfying n · P1 = P .
logP1 (P ) is at most q − 1.
Let Fp2 be a field Fp [i]/(i2 + 1). We define a set C2 with
(238) C2 ≡ {(X, Y ) ∈ Fp2 × Fp2 | Y 2 = X 3 + 3(i + 9)−1 } ∪ {(0, 0)}
We define a binary operation + and scalar multiplication · with the same equations (235), (236) and (237). (C2 , +) is also
known to be a group. We define P2 in C2 with
(239) P2 ≡ (11559732032986387107991004021392285783925812861821192530917403151452391805634 × i
+10857046999023057135944570762232829481370756359578518086990519993285655852781,
4082367875863433681332203403145435568316851327593401208105741076214120093531 × i
+8495653923123431417604973247489272438418190587263600148770280649306958101930)
We define G2 to be the subgroup of (C2 , +) generated by P2 . G2 is known to be the only cyclic group of order q on C2 .
For a point P in G2 , we define logP2 (P ) be the smallest natural number n satisfying n · P2 = P . With this definition,
logP2 (P ) is at most q − 1.
Let GT be the multiplicative abelian group underlying Fq12 . It is known that a non-degenerate bilinear map
e : G1 × G2 → GT exists. This bilinear map is a type three pairing. There are several such bilinear maps, it does not
matter which is chosen to be e. Let PT = e(P1 , P2 ), a be a set of k points in G1 , and b be a set of k points in G2 . It
follows from the definition of a pairing that the following are equivalent
(240) logP1 (a1 ) × logP2 (b1 ) + · · · + logP1 (ak ) × logP2 (bk ) ≡ 1 mod q
k
Y
(241) e (ai , bi ) = PT
i=0
Thus the pairing operation provides a method to verify (240).

A 32 byte number x ∈ P256 might and might not represent an element of Fp .
(
x if x < p
(242) δp (x) ≡
∅ otherwise
A 64 byte data x ∈ B512 might and might not represent an element of G1 .

(
g1 if g1 ∈ G1
(243) δ1 (x) ≡
∅ otherwise
(
(x, y) if x 6= ∅ ∧ y 6= ∅
(244) g1 ≡
∅ otherwise
(245) x ≡ δp (x[0..31])
(246) y ≡ δp (x[32..63])
A 128 byte data x ∈ B1024 might and might not represent an element of G2 .
(
g2 if g2 ∈ G2
(247) δ2 (x) ≡
∅ otherwise
(
((x0 i + y0 ), (x1 i + y1 )) if x0 6= ∅ ∧ y0 6= ∅ ∧ x1 6= ∅ ∧ y1 6= ∅
(248) g2 ≡
∅ otherwise
(249) x0 ≡ δp (x[0..31])
(250) y0 ≡ δp (x[32..63])
(251) x1 ≡ δp (x[64..95])
(252) y1 ≡ δp (x[96..127])
We define ΞSNARKV as a precompiled contract which checks if (240) holds, for intended use in zkSNARK verification.
(253) ΞSNARKV ≡ ΞPRE except:

∅, 0, A0 , ()

(254) ΞSNARKV (σ, g, I) = if F
(255) F ≡ (kId k mod 192 6= 0 ∨ (∃j. aj = ∅ ∨ bj = ∅))
kId k
(256) k =
192
(257) gr = 80000k + 100000
(
0x0000000000000000000000000000000000000000000000000000000000000001 if v ∧ ¬F
(258) o[0..31] ≡
0x0000000000000000000000000000000000000000000000000000000000000000 if ¬v ∧ ¬F
(259) v ≡ (logP1 (a1 ) × logP2 (b1 ) + · · · + logP1 (ak ) × logP2 (bk ) ≡ 1 mod q)
(260) a1 ≡ δ1 (Id [0..63])
(261) b1 ≡ δ2 (Id [64..191])
..
.
(262) ak ≡ δ1 (Id [(kId k − 192)..(kId k − 129)])
(263) bk ≡ δ2 (Id [(kId k − 128)..(kId k − 1)])
We define a precompiled contract for addition on G1 .
(264) ΞBN ADD ≡ ΞBN PRE except:

0
(265) ΞBN ADD (σ, g, I) = ∅, 0, A , () if x = ∅ ∨ y = ∅
(266) gr = 500
(267) o ≡ δ1−1 (x + y) where + is the group operation in G1
δ1 I¯d [0..63]

(268) x ≡
δ1 I¯d [64..127]

(269) y ≡
(
Id [x] if x < kId k
(270) I¯d [x] ≡
0 otherwise
We define a precompiled contract for scalar multiplication on G1 , where I¯d is defined in (270).
(271) ΞBN MUL ≡ ΞPRE except:
∅, 0, A0 , ()

(272) ΞBN MUL (σ, g, I) = if x = ∅
(273) gr = 40000
(274) o ≡ δ1−1 (n · x) where · is the scalar multiplication in G1
δ1 I¯d [0..63]

(275) x ≡
(276) n ≡ I¯d [64..95]
Appendix F. Signing Transactions

Transactions are signed using recoverable ECDSA signatures. This method utilises the SECP-256k1 curve as described
by Courtois et al. [2014], and is implemented similarly to as described by Gura et al. [2004] on p. 9 of 15, para. 3.
It is assumed that the sender has a valid private key pr , which is a randomly selected positive integer (represented as a
byte array of length 32 in big-endian form) in the range [1, secp256k1n − 1].
We assume the existence of functions ECDSAPUBKEY, ECDSASIGN and ECDSARECOVER. These are formally defined in the
literature, e.g. by Johnson et al. [2001].
(277) ECDSAPUBKEY(pr ∈ B32 ) ≡ pu ∈ B64
(278) ECDSASIGN(e ∈ B32 , pr ∈ B32 ) ≡ (v ∈ B1 , r ∈ B32 , s ∈ B32 )
(279) ECDSARECOVER(e ∈ B32 , v ∈ B1 , r ∈ B32 , s ∈ B32 ) ≡ pu ∈ B64
Where pu is the public key, assumed to be a byte array of size 64 (formed from the concatenation of two positive
integers each < 2256 ), pr is the private key, a byte array of size 32 (or a single positive integer in the aforementioned
range) and e is the hash of the transaction, h(T ). It is assumed that v is the ‘recovery identifier’. The recovery identifier
is a 1 byte value specifying the parity and finiteness of the coordinates of the curve point for which r is the x-value; this
value is in the range of [27, 30], however we declare the upper two possibilities, representing infinite values, invalid. The
value 27 represents an even y value and 28 represents an odd y value.
We declare that an ECDSA signature is invalid unless all the following conditions are true5:
(280) 0 < r < secp256k1n
(281) 0 < s < secp256k1n ÷ 2 + 1
(282) v ∈ {27, 28}
where:
(283) secp256k1n = 115792089237316195423570985008687907852837564279074904382605163141518161494337
For a given private key, pr , the Ethereum address A(pr ) (a 160-bit value) to which it corresponds is defined as the
rightmost 160-bits of the Keccak hash of the corresponding ECDSA public key:

(284) A(pr ) = B96..255 KEC ECDSAPUBKEY(pr )
The message hash, h(T ), to be signed is the Keccak hash of the transaction. Two different flavors of signing schemes
are available. One operates without the latter three signature components, formally described as Tr , Ts and Tw . The
other operates on nine elements:
(
(Tn , Tp , Tg , Tt , Tv , p) if v ∈ {27, 28}
(285) LS (T ) ≡
(Tn , Tp , Tg , Tt , Tv , p, chain id, (), ()) otherwise
where (
Ti if Tt = 0
p ≡
Td otherwise
(286) h(T ) ≡ KEC(LS (T ))
The signed transaction G(T, pr ) is defined as:
(287) G(T, pr ) ≡ T except:
(288) (Tw , Tr , Ts ) = ECDSASIGN(h(T ), pr )
Reiterating from previously:
(289) Tr = r
(290) Ts = s
Tw is either the recovery identifier or ‘chain identifier doubled plus 35 or 36’. In the second case, where v is the chain
identifier doubled plus 35 or 36, the values 35 and 36 assume the role of the ‘recovery identifier’ by specifying the parity
of y, with the value 35 representing an even value and 36 representing an odd value.
We may then define the sender function S of the transaction as:

(291) S(T ) ≡ B96..255 KEC ECDSARECOVER(h(T ), v0 , Tr , Ts )
(
Tw if Tw ∈ {27, 28}
(292) v0 ≡
28 − (Tw mod 2) otherwise
The assertion that the sender of a signed transaction equals the address of the signer should be self-evident:
(293) ∀T : ∀pr : S(G(T, pr )) ≡ A(pr )
5A signature of a transaction can be valid not only with a recovery identifier but with some other numbers. See how the component T
w
of a transaction is interpreted.
Appendix G. Fee Schedule

The fee schedule G is a tuple of 31 scalar values corresponding to the relative costs, in gas, of a number of abstract
operations that a transaction may effect.
Name Value Description*
Gzero 0 Nothing paid for operations of the set Wzero .
Gbase 2 Amount of gas to pay for operations of the set Wbase .
Gverylow 3 Amount of gas to pay for operations of the set Wverylow .
Glow 5 Amount of gas to pay for operations of the set Wlow .
Gmid 8 Amount of gas to pay for operations of the set Wmid .
Ghigh 10 Amount of gas to pay for operations of the set Whigh .
Gextcode 700 Amount of gas to pay for operations of the set Wextcode .
Gbalance 400 Amount of gas to pay for a BALANCE operation.
Gsload 200 Paid for a SLOAD operation.
Gjumpdest 1 Paid for a JUMPDEST operation.
Gsset 20000 Paid for an SSTORE operation when the storage value is set to non-zero from zero.
Gsreset 5000 Paid for an SSTORE operation when the storage value’s zeroness remains unchanged or
is set to zero.
Rsclear 15000 Refund given (added into refund counter) when the storage value is set to zero from
non-zero.
Rself destruct 24000 Refund given (added into refund counter) for self-destructing an account.
Gself destruct 5000 Amount of gas to pay for a SELFDESTRUCT operation.
Gcreate 32000 Paid for a CREATE operation.
Gcodedeposit 200 Paid per byte for a CREATE operation to succeed in placing code into state.
Gcall 700 Paid for a CALL operation.
Gcallvalue 9000 Paid for a non-zero value transfer as part of the CALL operation.
Gcallstipend 2300 A stipend for the called contract subtracted from Gcallvalue for a non-zero value transfer.
Gnewaccount 25000 Paid for a CALL or SELFDESTRUCT operation which creates an account.
Gexp 10 Partial payment for an EXP operation.
Gexpbyte 50 Partial payment when multiplied by dlog256 (exponent)e for the EXP operation.
Gmemory 3 Paid for every additional word when expanding memory.
Gtxcreate 32000 Paid by all contract-creating transactions after the Homestead transition.
Gtxdatazero 4 Paid for every zero byte of data or code for a transaction.
Gtxdatanonzero 68 Paid for every non-zero byte of data or code for a transaction.
Gtransaction 21000 Paid for every transaction.
Glog 375 Partial payment for a LOG operation.
Glogdata 8 Paid for each byte in a LOG operation’s data.
Glogtopic 375 Paid for each topic of a LOG operation.
Gsha3 30 Paid for each SHA3 operation.
Gsha3word 6 Paid for each word (rounded up) for input data to a SHA3 operation.
Gcopy 3 Partial payment for *COPY operations, multiplied by words copied, rounded up.
Gblockhash 20 Payment for BLOCKHASH operation.
Gquaddivisor 20 The quadratic coefficient of the input sizes of the exponentiation-over-modulo precompiled
contract.
Appendix H. Virtual Machine Specification

When interpreting 256-bit binary values as integers, the representation is big-endian.
When a 256-bit machine datum is converted to and from a 160-bit address or hash, the rightwards (low-order for BE)
20 bytes are used and the leftmost 12 are discarded or filled with zeroes, thus the integer values (when the bytes are
interpreted as big-endian) are equivalent.
H.1. Gas Cost. The general gas cost function, C, is defined as:
(294) 


 CSSTORE (σ, µ) if w = SSTORE
= EXP ∧ µs [1] = 0



 Gexp if w

Gexp + Gexpbyte × (1 + blog256 (µs [1])c) = EXP ∧ µs [1] > 0


 if w

Gverylow + Gcopy × dµs [2] ÷ 32e if w = CALLDATACOPY ∨




CODECOPY ∨ RETURNDATACOPY





Gextcode + Gcopy × dµs [3] ÷ 32e if w = EXTCODECOPY





G log + Glogdata × µs [1] if w = LOG0





Glog + Glogdata × µs [1] + Glogtopic

 if w = LOG1





Glog + Glogdata × µs [1] + 2Glogtopic if w = LOG2




Glog + Glogdata × µs [1] + 3Glogtopic if w = LOG3
Glog + Glogdata × µs [1] + 4Glogtopic


 if w = LOG4

w = CALL ∨ CALLCODE ∨



CCALL (σ, µ) if




 DELEGATECALL
C(σ, µ, I) ≡ Cmem (µ0i ) − Cmem (µi ) + CSELFDESTRUCT (σ, µ) if w = SELFDESTRUCT

Gcreate

 if w = CREATE


Gsha3 + Gsha3word ds[1] ÷ 32e if w = SHA3








Gjumpdest if w = JUMPDEST

Gsload

 if w = SLOAD





Gzero if w ∈ Wzero
∈ Wbase



Gbase if w

∈ Wverylow

Gverylow

 if w

Glow if w ∈ Wlow





Gmid if w ∈ Wmid





Ghigh if w ∈ Whigh





Gextcode if w ∈ Wextcode








Gbalance if w = BALANCE

G
blockhash if w = BLOCKHASH
(
Ib [µpc ] if µpc < kIb k
(295) w≡
STOP otherwise
where:
a2

(296) Cmem (a) ≡ Gmemory · a +
512
with CCALL , CSELFDESTRUCT and CSSTORE as specified in the appropriate section below. We define the following subsets
of instructions:
Wzero = {STOP, RETURN, REVERT}
Wbase = {ADDRESS, ORIGIN, CALLER, CALLVALUE, CALLDATASIZE, CODESIZE, GASPRICE, COINBASE,
TIMESTAMP, NUMBER, DIFFICULTY, GASLIMIT, RETURNDATASIZE, POP, PC, MSIZE, GAS}
Wverylow = {ADD, SUB, NOT, LT, GT, SLT, SGT, EQ, ISZERO, AND, OR, XOR, BYTE, CALLDATALOAD,
MLOAD, MSTORE, MSTORE8, PUSH*, DUP*, SWAP*}
Wlow = {MUL, DIV, SDIV, MOD, SMOD, SIGNEXTEND}
Wmid = {ADDMOD, MULMOD, JUMP}
Whigh = {JUMPI}
Wextcode = {EXTCODESIZE}
Note the memory cost component, given as the product of Gmemory and the maximum of 0 & the ceiling of the number
of words in size that the memory must be over the current number of words, µi in order that all accesses reference valid
memory whether for read or write. Such accesses must be for non-zero number of bytes.
Referencing a zero length range (e.g. by attempting to pass it as the input range to a CALL) does not require memory
to be extended to the beginning of the range. µ0i is defined as this new maximum number of words of active memory;
special-cases are given where these two are not equal.
Note also that Cmem is the memory cost function (the expansion function being the difference between the cost before
and after). It is a polynomial, with the higher-order coefficient divided and floored, and thus linear up to 724B of memory
used, after which it costs substantially more.
While defining the instruction set, we defined the memory-expansion for range function, M , thus:
(
s if l = 0
(297) M (s, f, l) ≡
max(s, d(f + l) ÷ 32e) otherwise
Another useful function is “all but one 64th” function L defined as:
(298) L(n) ≡ n − bn/64c
H.2. Instruction Set. As previously specified in section 9, these definitions take place in the final context there. In
particular we assume O is the EVM state-progression function and define the terms pertaining to the next cycle’s state
(σ 0 , µ0 ) such that:
(299) O(σ, µ, A, I) ≡ (σ 0 , µ0 , A0 , I) with exceptions, as noted
Here given are the various exceptions to the state transition rules given in section 9 specified for each instruction,
together with the additional instruction-specific definitions of J and C. For each instruction, also specified is α, the
additional items placed on the stack and δ, the items removed from stack, as defined in section 9.
0s: Stop and Arithmetic Operations

All arithmetic is modulo 2256 unless otherwise noted. The zero-th power of zero 00 is defined to be one.
Value Mnemonic δ α Description
0x00 STOP 0 0 Halts execution.
0x01 ADD 2 1 Addition operation.
µ0s [0] ≡ µs [0] + µs [1]
0x02 MUL 2 1 Multiplication operation.
µ0s [0] ≡ µs [0] × µs [1]
0x03 SUB 2 1 Subtraction operation.
µ0s [0] ≡ µs [0] − µs [1]
0x04 DIV 2 1 Integer division
( operation.
0 if µs [1] = 0
µ0s [0] ≡
bµs [0] ÷ µs [1]c otherwise
0x05 SDIV 2 1 Signed integer
 division operation (truncated).
0
 if µs [1] = 0
µ0s [0] ≡ −2255 if µs [0] = −2255 ∧ µs [1] = −1

sgn(µs [0] ÷ µs [1])b|µs [0] ÷ µs [1]|c otherwise

Where all values are treated as two’s complement signed 256-bit integers.
Note the overflow semantic when −2255 is negated.
0x06 MOD 2 1 Modulo ( remainder operation.
0 0 if µs [1] = 0
µs [0] ≡
µs [0] mod µs [1] otherwise
0x07 SMOD 2 1 Signed modulo
( remainder operation.
0 if µs [1] = 0
µ0s [0] ≡
sgn(µs [0])(|µs [0]| mod |µs [1]|) otherwise
0x08 ADDMOD 3 1 Modulo ( addition operation.
0 0 if µs [2] = 0
µs [0] ≡
(µs [0] + µs [1]) mod µs [2] otherwise
All intermediate calculations of this operation are not subject to the 2256
modulo.
0x09 MULMOD 3 1 Modulo ( multiplication operation.
0 0 if µs [2] = 0
µs [0] ≡
(µs [0] × µs [1]) mod µs [2] otherwise
All intermediate calculations of this operation are not subject to the 2256
modulo.
0x0a EXP 2 1 Exponential operation.
µ0s [0] ≡ µs [0]µs [1]
0x0b SIGNEXTEND 2 1 Extend length of two’s(complement signed integer.
µs [1]t if i 6 t where t = 256 − 8(µs [0] + 1)
∀i ∈ [0..255] : µ0s [0]i ≡
µs [1]i otherwise
µs [x]i gives the ith bit (counting from zero) of µs [x]
10s: Comparison & Bitwise Logic Operations

0x10 LT 2 1 Less-than ( comparison.
1 if µs [0] < µs [1]
µ0s [0] ≡
0 otherwise
0x11 GT 2 1 Greater-than
( comparison.
1 if µs [0] > µs [1]
µ0s [0] ≡
0 otherwise
0x12 SLT 2 1 Signed less-than
( comparison.
1 if µs [0] < µs [1]
µ0s [0] ≡
0 otherwise
0x13 SGT 2 1 Signed greater-than
( comparison.
1 if µ [0] > µs [1]
µ0s [0] ≡ s
0 otherwise
0x14 EQ 2 1 Equality(comparison.
1 if µs [0] = µs [1]
µ0s [0] ≡
0 otherwise
0x15 ISZERO 1 1 Simple not
( operator.
0 1 if µs [0] = 0
µs [0] ≡
0 otherwise
0x16 AND 2 1 Bitwise AND operation.
∀i ∈ [0..255] : µ0s [0]i ≡ µs [0]i ∧ µs [1]i
0x17 OR 2 1 Bitwise OR operation.
∀i ∈ [0..255] : µ0s [0]i ≡ µs [0]i ∨ µs [1]i
0x18 XOR 2 1 Bitwise XOR operation.
∀i ∈ [0..255] : µ0s [0]i ≡ µs [0]i ⊕ µs [1]i
0x19 NOT 1 1 Bitwise NOT operation.
(
1 if µs [0]i = 0
∀i ∈ [0..255] : µ0s [0]i ≡
0 otherwise
0x1a BYTE 2 1 Retrieve single byte from ( word.
0 µs [1](i+8µs [0]) if i < 8 ∧ µs [0] < 32
∀i ∈ [0..255] : µs [0]i ≡
0 otherwise
For the Nth byte, we count from the left (i.e. N=0 would be the most significant
in big endian).
20s: SHA3
0x20 SHA3 2 1 Compute Keccak-256 hash.
µ0s [0] ≡ Keccak(µm [µs [0] . . . (µs [0] + µs [1] − 1)])
µ0i ≡ M (µi , µs [0], µs [1])
30s: Environmental Information

0x30 ADDRESS 0 1 Get address of currently executing account.
µ0s [0] ≡ Ia
0x31 BALANCE 1 1 Get balance
( of the given account.
σ[µs [0]]b if σ[µs [0] mod 2160 ] 6= ∅
µ0s [0] ≡
0 otherwise
0x32 ORIGIN 0 1 Get execution origination address.
µ0s [0] ≡ Io
This is the sender of original transaction; it is never an account with
non-empty associated code.
0x33 CALLER 0 1 Get caller address.
µ0s [0] ≡ Is
This is the address of the account that is directly responsible for
this execution.
0x34 CALLVALUE 0 1 Get deposited value by the instruction/transaction responsible for
this execution.
µ0s [0] ≡ Iv
0x35 CALLDATALOAD 1 1 Get input data of current environment.
µ0s [0] ≡ Id [µs [0] . . . (µs [0] + 31)] with Id [x] = 0 if x > kId k
This pertains to the input data passed with the message call
instruction or transaction.
0x36 CALLDATASIZE 0 1 Get size of input data in current
environment.
µ0s [0] ≡ kId k
This pertains to the input data passed with the message call
instruction or transaction.
0x37 CALLDATACOPY 3 0 Copy input data in current environment ( to memory.
Id [µs [1] + i] if µs [1] + i < kId k
∀i ∈ {0 . . . µs [2] − 1} : µ0m [µs [0] + i] ≡
0 otherwise
The additions in µs [1] + i are not subject to the 2256 modulo.
µ0i ≡ M (µi , µs [0], µs [2])
This pertains to the input data passed with the message call instruction
or transaction.
0x38 CODESIZE 0 1 Get size of code running in current environment.
µ0s [0] ≡ kIb k
0x39 CODECOPY 3 0 Copy code running in current environment ( to memory.
Ib [µs [1] + i] if µs [1] + i < kIb k
∀i ∈ {0 . . . µs [2] − 1} : µ0m [µs [0] + i] ≡
STOP otherwise
µ0i ≡ M (µi , µs [0], µs [2])
0x3a GASPRICE 0 1 Get price of gas in current environment.
µ0s [0] ≡ Ip
This is gas price specified by the originating transaction.
0x3b EXTCODESIZE 1 1 Get size of an account’s code.
µ0s [0] ≡ kσ[µs [0] mod 2160 ]c k
0x3c EXTCODECOPY 4 0 Copy an account’s code to memory. (
c[µs [2] + i] if µs [2] + i < kck
∀i ∈ {0 . . . µs [3] − 1} : µ0m [µs [1] + i] ≡
STOP otherwise
where c ≡ σ[µs [0] mod 2160 ]c
µ0i ≡ M (µi , µs [1], µs [3])
0x3d RETURNDATASIZE 0 1 Get size of output data from the previous call from the current
environment.
µ0s [0] ≡ kµo k
0x3e RETURNDATACOPY 3 0 Copy output data from the previous call ( to memory.
µo [µs [1] + i] if µs [1] + i < kµo k
∀i ∈ {0 . . . µs [2] − 1} : µ0m [µs [0] + i] ≡
0 otherwise
µ0i ≡ M (µi , µs [0], µs [2])
40s: Block Information

0x40 BLOCKHASH 1 1 Get the hash of one of the 256 most recent complete blocks.
µ0s [0] ≡ P (IHp , µs [0], 0)
where P is the hash of a block of a particular number, up to a maximum
age. 0 is left on the stack if the looked for block number is greater than
the current block
 number or more than 256 blocks behind the current block.
0
 if n > Hi ∨ a = 256 ∨ h = 0
P (h, n, a) ≡ h if n = Hi

P (Hp , n, a + 1) otherwise

and we assert the header H can be determined from its hash h unless as its hash is the parent
h is zero.
0x41 COINBASE 0 1 Get the block’s beneficiary address.
µ0s [0] ≡ IH c
0x42 TIMESTAMP 0 1 Get the block’s timestamp.
µ0s [0] ≡ IH s
0x43 NUMBER 0 1 Get the block’s number.
µ0s [0] ≡ IH i
0x44 DIFFICULTY 0 1 Get the block’s difficulty.
µ0s [0] ≡ IH d
0x45 GASLIMIT 0 1 Get the block’s gas limit.
µ0s [0] ≡ IH l
50s: Stack, Memory, Storage and Flow Operations

0x50 POP 1 0 Remove item from stack.
0x51 MLOAD 1 1 Load word from memory.
µ0s [0] ≡ µm [µs [0] . . . (µs [0] + 31)]
µ0i ≡ max(µi , d(µs [0] + 32) ÷ 32e)
The addition in the calculation of µ0i is not subject to the 2256 modulo.
0x52 MSTORE 2 0 Save word to memory.
µ0m [µs [0] . . . (µs [0] + 31)] ≡ µs [1]
µ0i ≡ max(µi , d(µs [0] + 32) ÷ 32e)
0x53 MSTORE8 2 0 Save byte to memory.
µ0m [µs [0]] ≡ (µs [1] mod 256)
µ0i ≡ max(µi , d(µs [0] + 1) ÷ 32e)
0x54 SLOAD 1 1 Load word from storage.
µ0s [0] ≡ σ[Ia ]s [µs [0]]
0x55 SSTORE 2 0 Save word to storage.
σ 0 [Ia ]s [µs [0]] ≡ µs([1]
Gsset if µs [1] 6= 0 ∧ σ[Ia ]s [µs [0]] = 0
CSSTORE (σ, µ) ≡
Gsreset otherwise
(
Rsclear if µs [1] = 0 ∧ σ[Ia ]s [µs [0]] 6= 0
A0r ≡ Ar +
0 otherwise
0x56 JUMP 1 0 Alter the program counter.
JJUMP (µ) ≡ µs [0]
This has the effect of writing said value to µpc . See section 9.
0x57 JUMPI 2 0 Conditionally(alter the program counter.
µs [0] if µs [1] 6= 0
JJUMPI (µ) ≡
µpc + 1 otherwise
This has the effect of writing said value to µpc . See section 9.
0x58 PC 0 1 Get the value of the program counter prior to the increment
corresponding to this instruction.
µ0s [0] ≡ µpc
0x59 MSIZE 0 1 Get the size of active memory in bytes.
µ0s [0] ≡ 32µi
0x5a GAS 0 1 Get the amount of available gas, including the corresponding reduction
for the cost of this instruction.
µ0s [0] ≡ µg
0x5b JUMPDEST 0 0 Mark a valid destination for jumps.
This operation has no effect on machine state during execution.
60s & 70s: Push Operations

0x60 PUSH1 0 1 Place 1 byte item on stack.
µ0s [0] ≡ c(µpc +(1)
Ib [x] if x < kIb k
where c(x) ≡
0 otherwise
The bytes are read in line from the program code’s bytes array.
The function c ensures the bytes default to zero if they extend past the limits.
The byte is right-aligned (takes the lowest significant place in big endian).
0x61 PUSH2 0 1 Place 2-byte item on stack.
µ0s [0] ≡ c (µpc + 1) . . . (µpc + 2)

with c(x) ≡ (c(x0 ), ..., c(xkxk−1 )) with c as defined as above.

The bytes are right-aligned (takes the lowest significant place in big endian).
.. .. .. .. ..
. . . . .
0x7f PUSH32 0 1 Place 32-byte (full word) item on stack.
µ0s [0] ≡ c (µpc + 1) . . . (µpc + 32)
where c is defined as above.
The bytes are right-aligned (takes the lowest significant place in big endian).
80s: Duplication Operations
0x80 DUP1 1 2 Duplicate 1st stack item.
µ0s [0] ≡ µs [0]
0x81 DUP2 2 3 Duplicate 2nd stack item.
µ0s [0] ≡ µs [1]
.. .. .. .. ..
. . . . .
0x8f DUP16 16 17 Duplicate 16th stack item.
µ0s [0] ≡ µs [15]
90s: Exchange Operations
0x90 SWAP1 2 2 Exchange 1st and 2nd stack items.
µ0s [0] ≡ µs [1]
µ0s [1] ≡ µs [0]
0x91 SWAP2 3 3 Exchange 1st and 3rd stack items.
µ0s [0] ≡ µs [2]
µ0s [2] ≡ µs [0]
.. .. .. .. ..
. . . . .
0x9f SWAP16 17 17 Exchange 1st and 17th stack items.
µ0s [0] ≡ µs [16]
µ0s [16] ≡ µs [0]
a0s: Logging Operations

For all logging operations, the state change is to append an additional log entry on to the substate’s log series:
A0l ≡ Al · (Ia , t, µm [µs [0] . . . (µs [0] + µs [1] − 1)])
and to update the memory consumption counter:
µ0i ≡ M (µi , µs [0], µs [1])
The entry’s topic series, t, differs accordingly:
0xa0 LOG0 2 0 Append log record with no topics.
t ≡ ()
0xa1 LOG1 3 0 Append log record with one topic.
t ≡ (µs [2])
.. .. .. .. ..
. . . . .
0xa4 LOG4 6 0 Append log record with four topics.
t ≡ (µs [2], µs [3], µs [4], µs [5])
f0s: System operations

0xf0 CREATE 3 1 Create a new account with associated code.
i ≡ µm [µs [1] . . . (µs [1] + µs [2] − 1)]
∗
Λ(σ , Ia , Io , L(µg ), Ip , µs [0], i, Ie + 1, Iw ) if µs [0] 6 σ[Ia ]b

(σ 0 , µ0g , A+ , o) ≡ ∧ Ie < 1024

σ, µg , ∅ otherwise

σ ∗ ≡ σ except σ ∗ [Ia ]n = σ[Ia ]n + 1
A0 ≡ A d A+ which abbreviates: A0s ≡ As ∪ A+ s ∧ A0l ≡ Al · A+ l ∧
A0t ≡ At ∪ A+ t ∧ A 0
r ≡ Ar + A+
r
µ0s [0] ≡ x
where x = 0 if the code execution for this operation failed due to an
exceptional halting (or for a REVERT) σ 0 = ∅, or Ie = 1024
(the maximum call depth limit is reached) or µs [0] > σ[Ia ]b (balance of the caller
is too low to fulfil the value transfer); and otherwise x = A(Ia , σ[Ia ]n ), the
address of the newly created account.
µ0i ≡ M (µi , µs [1], µs [2])
µ0o ≡ ()
Thus the operand order is: value, input offset, input size.
0xf1 CALL 7 1 Message-call into an account.
i ≡ µm [µs [3] . . . (µ s [3] + µs [4] − 1)]
 Θ(σ, Ia , Io , t, t, CCALLGAS (µ),
 if µs [2] 6 σ[Ia ]b ∧
(σ 0 , g 0 , A+ , o) ≡ Ip , µs [2], µs [2], i, Ie + 1, Iw ) Ie < 1024

(σ, g, ∅, ()) otherwise

n ≡ min({µs [6], kok})
µ0m [µs [5] . . . (µs [5] + n − 1)] = o[0 . . . (n − 1)]
µ0o = o
µ0g ≡ µg + g 0
µ0s [0] ≡ x
A0 ≡ A d A+
t ≡ µs [1] mod 2160
where x = 0 if the code execution for this operation failed due to an
exceptional halting (or for a REVERT) σ 0 = ∅ or if
µs [2] > σ[Ia ]b (not enough funds) or Ie = 1024 (call depth limit reached); x = 1
otherwise.
µ0i ≡ M (M (µi , µs [3], µs [4]), µs [5], µs [6])
Thus the operand order is: gas, to, value, in offset, in size, out offset, out size.
CCALL (σ, µ) ≡ CGASCAP ( (σ, µ) + CEXTRA (σ, µ)
CGASCAP (σ, µ) + Gcallstipend if µs [2] 6= 0
CCALLGAS (σ, µ) ≡
C (σ, µ) otherwise
( GASCAP
min{L(µg − CEXTRA (σ, µ)), µs [0]} if µg ≥ CEXTRA (σ, µ)
CGASCAP (σ, µ) ≡
µs [0] otherwise
CEXTRA (σ, µ)(≡ Gcall + CXFER (µ) + CNEW (σ, µ)
Gcallvalue if µs [2] 6= 0
CXFER (µ) ≡
0 otherwise
(
Gnewaccount if DEAD(σ, µs [1] mod 2160 ) ∧ µs [2] 6= 0
CNEW (σ, µ) ≡
0 otherwise
0xf2 CALLCODE 7 1 Message-call into this account with an alternative account’s code.
Exactly equivalent to CALL except:
∗
 Θ(σ , Ia , Io , Ia , t, CCALLGAS (µ),
 if µs [2] 6 σ[Ia ]b ∧
0 0 +
(σ , g , A , o) ≡ Ip , µs [2], µs [2], i, Ie + 1, Iw ) Ie < 1024


Note the change in the fourth parameter to the call Θ from the 2nd stack value
µs [1] (as in CALL) to the present address Ia . This means that the recipient is in
fact the same account as at present, simply that the code is overwritten.
0xf3 RETURN 2 0 Halt execution returning output data.
HRETURN (µ) ≡ µm [µs [0] . . . (µs [0] + µs [1] − 1)]
This has the effect of halting the execution at this point with output defined.
See section 9.
µ0i ≡ M (µi , µs [0], µs [1])
0xf4 DELEGATECALL 6 1 Message-call into this account with an alternative account’s code, but
persisting the current values for sender and value.
Compared with CALL, DELEGATECALL takes one fewer arguments. The
omitted argument is µs [2]. As a result, µs [3], µs [4], µs [5] and µs [6] in the
definition of CALL should respectively be replaced with µs [2], µs [3], µs [4] and
µs [5]. Otherwise it is equivalent to CALL except:
Θ(σ ∗ , Is , Io , Ia , t, CCALLGAS (µ),

if Iv 6 σ[Ia ]b ∧



 Ip , 0, Iv , i, Ie + 1, Iw )
(σ 0 , g 0 , A+ , o) ≡


 Ie < 1024

Note the changes (in addition to that of the fourth parameter) to the second
and ninth parameters to the call Θ.
This means that the recipient is in fact the same account as at present, simply
that the code is overwritten and the context is almost entirely identical.
0xfa STATICCALL 6 1 Static message-call into an account.
Exactly equivalent to CALL except:
The argument µs [2] is replaced with 0.
The deeper argument µs [3], µs [4], µs [5] and µs [6] are respectively replaced
with µs [2], µs [3], µs [4] and µs [5].
The last argument of Θ is ⊥.
0xfd REVERT 2 0 Halt execution reverting state changes but returning data and remaining gas.
The effect of this operation is described in (131).
For the gas calculation, we use the memory expansion function,
µ0i ≡ M (µi , µs [0], µs [1])
0xfe INVALID ∅ ∅ Designated invalid instruction.
0xff SELFDESTRUCT 1 0 Halt execution and register account for later deletion.
A0s ≡ As∪ {Ia }
∅
 if σ[r] = ∅ ∧ σ[Ia ]b = 0
σ 0 [r] ≡ (σ[r]n , σ[r]b + σ[Ia ]b , σ[r]s , σ[r]c ) if r 6= Ia

(σ[r]n , 0, σ[r]s , σ[r]c ) otherwise

where r = µs [0] mod 2160
σ 0 [Ia ]b = 0 (
Gnewaccount if n
CSELFDESTRUCT (σ, µ) ≡ Gself destruct +
0 otherwise
n ≡ DEAD(σ, µs [0] mod 2160 ) ∧ σ[Ia ]b =
6 0
Appendix I. Genesis Block

The genesis block is 15 items, and is specified thus:
0256 , KEC RLP () , 0160 , stateRoot, 0, 0, 02048 , 217 , 0, 0, 3141592, time, 0, 0256 , KEC (42) , (), ()

(300)
Where 0256 refers to the parent hash, a 256-bit hash which is all zeroes; 0160 refers to the beneficiary address, a 160-bit
hash which is all zeroes; 02048 refers to the log bloom, 2048-bit of all zeros; 217 refers to the difficulty; the transaction trie
root, receipt trie root, gas used, block number and extradata are both 0, being equivalent to the empty byte array. The
sequences of both ommers and transactions are empty and represented by (). KEC (42) refers to the Keccak hash of a

byte array of length one whose first and only byte is of value 42, used for the nonce. KEC RLP () value refers to the
hash of the ommer list in RLP, both empty lists.
The proof-of-concept series include a development premine, making the state root hash some value stateRoot. Also
time will be set to the initial timestamp of the genesis block. The latest documentation should be consulted for those
values.
Appendix J. Ethash
J.1. Definitions. We employ the following definitions:
Name Value Description

Jwordbytes 4 Bytes in word.
Jdatasetinit 230 Bytes in dataset at genesis.
Jdatasetgrowth 223 Dataset growth per epoch.
Jcacheinit 224 Bytes in cache at genesis.
Jcachegrowth 217 Cache growth per epoch.
Jepoch 30000 Blocks per epoch.
Jmixbytes 128 mix length in bytes.
Jhashbytes 64 Hash length in bytes.
Jparents 256 Number of parents of each dataset element.
Jcacherounds 3 Number of rounds in cache production.
Jaccesses 64 Number of accesses in hashimoto loop.
J.2. Size of dataset and cache. The size for Ethash’s cache c ∈ B and dataset d ∈ B depend on the epoch, which in
turn depends on the block number.

Hi
(301) Eepoch (Hi ) =
Jepoch
The size of the dataset growth by Jdatasetgrowth bytes, and the size of the cache by Jcachegrowth bytes, every epoch. In
order to avoid regularity leading to cyclic behavior, the size must be a prime number. Therefore the size is reduced by a
multiple of Jmixbytes , for the dataset, and Jhashbytes for the cache. Let dsize = kdk be the size of the dataset. Which is
calculated using
(302) dsize = Eprime (Jdatasetinit + Jdatasetgrowth · Eepoch − Jmixbytes , Jmixbytes )
The size of the cache, csize , is calculated using
(303) csize = Eprime (Jcacheinit + Jcachegrowth · Eepoch − Jhashbytes , Jhashbytes )
(
x if x/y ∈ N
(304) Eprime (x, y) =
Eprime (x − 2 · y, y) otherwise
J.3. Dataset generation. In order to generate the dataset we need the cache c, which is an array of bytes. It depends
on the cache size csize and the seed hash s ∈ B32 .
J.3.1. Seed hash. The seed hash is different for every epoch. For the first epoch it is the Keccak-256 hash of a series of 32
bytes of zeros. For every other epoch it is always the Keccak-256 hash of the previous seed hash:
(305) s = Cseedhash (Hi )
(
032 if Eepoch (Hi ) = 0
(306) Cseedhash (Hi ) =
KEC(Cseedhash (Hi − Jepoch )) otherwise
With 032 being 32 bytes of zeros.
J.3.2. Cache. The cache production process involves using the seed hash to first sequentially filling up csize bytes of
memory, then performing Jcacherounds passes of the RandMemoHash algorithm created by Lerner [2014]. The initial
cache c0 , being an array of arrays of single bytes, will be constructed as follows.
We define the array ci , consisting of 64 single bytes, as the ith element of the initial cache:
(
KEC512(s) if i = 0
(307) ci =
KEC512(ci−1 ) otherwise
Therefore c0 can be defined as
(308) c0 [i] = ci ∀ i < n

csize
(309) n=
Jhashbytes
The cache is calculated by performing Jcacherounds rounds of the RandMemoHash algorithm to the initial cache c0 :
(310) c = Ecacherounds (c0 , Jcacherounds )

x
 if y = 0
(311) Ecacherounds (x, y) = ERMH (x) if y = 1

Ecacherounds (ERMH (x), y − 1) otherwise

Where a single round modifies each subset of the cache as follows:

(312) ERMH (x) = Ermh (x, 0), Ermh (x, 1), ..., Ermh (x, n − 1)
(313) Ermh (x, i) = KEC512(x0 [(i − 1 + n) mod n] ⊕ x0 [x0 [i][0] mod n])
with x0 = x except x0 [j] = Ermh (x, j) ∀ j<i
J.3.3. Full dataset calculation. Essentially, we combine data from Jparents pseudorandomly selected cache nodes, and hash
that to compute the dataset. The entire dataset is then generated by a number of items, each Jhashbytes bytes in size:

dsize
(314) d[i] = Edatasetitem (c, i) ∀ i <
Jhashbytes
In order to calculate the single item we use an algorithm inspired by the FNV hash (Glenn Fowler [1991]) in some cases
as a non-associative substitute for XOR.
(315) EFNV (x, y) = (x · (0x01000193 ⊕ y)) mod 232
The single item of the dataset can now be calculated as:
(316) Edatasetitem (c, i) = Eparents (c, i, −1, ∅)
(
Eparents (c, i, p + 1, Emix (m, c, i, p + 1)) if p < Jparents − 2
(317) Eparents (c, i, p, m) =
Emix (m, c, i, p + 1) otherwise
(
KEC512(c[i mod csize ] ⊕ i) if p = 0
(318) Emix (m, c, i, p) =
EFNV m, c[EFNV (i ⊕ p, m[p mod bJhashbytes /Jwordbytes c]) mod csize ] otherwise
J.4. Proof-of-work function. Essentially, we maintain a “mix” Jmixbytes bytes wide, and repeatedly sequentially fetch
Jmixbytes bytes from the full dataset and use the EFNV function to combine it with the mix. Jmixbytes bytes of sequential
access are used so that each round of the algorithm always fetches a full page from RAM, minimizing translation lookaside
buffer misses which ASICs would theoretically be able to avoid.
If the output of this algorithm is below the desired target, then the nonce is valid. Note that the extra application
of KEC at the end ensures that there exists an intermediate nonce which can be provided to prove that at least a small
amount of work was done; this quick outer PoW verification can be used for anti-DDoS purposes. It also serves to provide
statistical assurance that the result is an unbiased, 256 bit number.
The PoW-function returns an array with the compressed mix as its first item and the Keccak-256 hash of the
concatenation of the compressed mix with the seed hash as the second item:
(319)
PoW(Hn , Hn , d) = {mc (KEC(RLP(LH (Hn ))), Hn , d), KEC(sh (KEC(RLP(LH (Hn ))), Hn ) + mc (KEC(RLP(LH (Hn ))), Hn , d))}
With Hn being the hash of the header without the nonce. The compressed mix mc is obtained as follows:
nmix
X
(320) mc (h, n, d) = Ecompress (Eaccesses (d, sh (h, n), sh (h, n), −1), −4)
i=0
The seed hash being:

(321) sh (h, n) = KEC512(h + Erevert (n))
Erevert (n) returns the reverted bytes sequence of the nonce n:
(322) Erevert (n)[i] = n[knk − i]
We note that the “+”-operator between two byte sequences results in the concatenation of both sequences.
The dataset d is obtained as described in section J.3.3.
The number of replicated sequences in the mix is:

Jmixbytes
(323) nmix =
Jhashbytes
In order to add random dataset nodes to the mix, the Eaccesses function is used:
(
Emixdataset (d, m, s, i) if i = Jaccesses − 2
(324) Eaccesses (d, m, s, i) =
Eaccesses (Emixdataset (d, m, s, i), s, i + 1) otherwise
(325) Emixdataset (d, m, s, i) = EFNV (m, Enewdata (d, m, s, i))

Enewdata returns an array with nmix elements:
(326)
Jmixbytes dsize /Jhashbytes
Enewdata (d, m, s, i)[j] = d[EFNV (i ⊕ s[0], m[i mod ]) mod · nmix + j] ∀ j < nmix
Jwordbytes nmix
The mix is compressed as follows:
(327) (
m if i > kmk − 8
Ecompress (m, i) =
Ecompress (EFNV (EFNV (EFNV (m[i + 4], m[i + 5]), m[i + 6]), m[i + 7]), i + 8) otherwise
Appendix K. Anomalies on the Main Network

K.1. Deletion of an Account Despite Out-of-gas. At block 2675119, in the transaction 0xcf416c536ec1a19ed1fb89e
4ec7ffb3cf73aa413b3aa9b77d60e4fd81a4296ba, an account at address 0x03 was called and an out-of-gas occurred during
the call. Against the equation (195), this added 0x03 in the set of touched addresses, and this transaction turned σ[0x03]
into ∅.
Appendix L. List of mathematical symbols

Symbol Latex Command Description
W
\bigvee This is the least upper bound, supremum, or join of all elements operated on. Thus it
is the greatest element of such elements (Davey and Priestley [2002]).

Paper

Uploaded by

Copyright:

Available Formats

Paper

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Paper

Uploaded by

Copyright:

Available Formats

ETHEREUM: A SECURE DECENTRALISED GENERALISED TRANSACTION LEDGER

BYZANTIUM VERSION 7e819ec - 2019-10-20

DR. GAVIN WOOD

1. Introduction is often lacking, and plain old prejudices are difficult to

the first three pairs of bytes in a Keccak-256 hash of the where

7. Contract Creation where I contains the parameters of the execution environ-

We define σ 1 , the first transitional state as the orig-

where the transaction processor or, recursively, the spawning

where: heaviest path is the block number of the leaf, equivalent

10. Blocktree to Blockchain 11.2. Transaction Validation. The given gasUsed

11.3. Reward Application. The application of rewards such transaction):

Appendix B. Recursive Length Prefix

We define the set of possible structures T:

There is no specific canonical encoding format for signed or floating-point values.

Appendix C. Hex-Prefix Encoding

Appendix D. Modified Merkle Patricia Tree

Appendix E. Precompiled Contracts

(196) ΞECREC ≡ ΞPRE where:

(208) ΞSHA256 ≡ ΞPRE where:

(215) SHA256(i ∈ B) ≡ o ∈ B32

(220) ΞEXPMOD ≡ ΞPRE except:

We define a set C1 with

(234) C1 ≡ {(X, Y ) ∈ Fp × Fp | Y 2 = X 3 + 3} ∪ {(0, 0)}

We define a binary operation + on C1 for distinct elements (X1 , Y1 ), (X2 , Y2 ) with

In the case where (X1 , Y1 ) = (X2 , Y2 ), we define + on C1 with

(C1 , +) is known to form a group. We define scalar multiplication · with

for a natural number n and a point P in C1 .

(238) C2 ≡ {(X, Y ) ∈ Fp2 × Fp2 | Y 2 = X 3 + 3(i + 9)−1 } ∪ {(0, 0)}

Thus the pairing operation provides a method to verify (240).

A 64 byte data x ∈ B512 might and might not represent an element of G1 .

(253) ΞSNARKV ≡ ΞPRE except:

(264) ΞBN ADD ≡ ΞBN PRE except:

Appendix F. Signing Transactions

Appendix G. Fee Schedule

Appendix H. Virtual Machine Specification

(298) L(n) ≡ n − bn/64c

(299) O(σ, µ, A, I) ≡ (σ 0 , µ0 , A0 , I) with exceptions, as noted

0s: Stop and Arithmetic Operations

10s: Comparison & Bitwise Logic Operations

30s: Environmental Information

40s: Block Information

50s: Stack, Memory, Storage and Flow Operations

60s & 70s: Push Operations

with c(x) ≡ (c(x0 ), ..., c(xkxk−1 )) with c as defined as above.

a0s: Logging Operations

f0s: System operations

where r = µs [0] mod 2160

Appendix I. Genesis Block

Name Value Description

Where a single round modifies each subset of the cache as follows:

The seed hash being:

(325) Emixdataset (d, m, s, i) = EFNV (m, Enewdata (d, m, s, i))

Appendix K. Anomalies on the Main Network

Appendix L. List of mathematical symbols

You might also like