Baixe Ethereum: a secure decentralised generalised transaction ledger e outras Resumos em PDF para Cálculo para Engenheiros, somente na Docsity!
ETHEREUM: A SECURE DECENTRALISED GENERALISED TRANSACTION LEDGER
BERLIN VERSION 61f6d40 – 2022-01-
DR. GAVIN WOOD FOUNDER, ETHEREUM & PARITY GAVIN@PARITY.IO
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.
- Introduction
With ubiquitous internet connections in most places of the world, global information transmission has become incredibly cheap. Technology-rooted movements like Bit- coin have demonstrated through the power of the default, consensus mechanisms, and voluntary respect of the social contract, that it is possible to use the internet to make a decentralised value-transfer system that can be shared across the world and virtually free to use. This system can be said to be a very specialised version of a cryptographi- cally secure, transaction-based state machine. Follow-up systems such as Namecoin adapted this original “currency application” of the technology into other applications albeit rather simplistic ones. Ethereum is a project which attempts to build the gen- eralised technology; technology on which all transaction- based state machine concepts may be built. Moreover it aims to provide to the end-developer a tightly integrated end-to-end system for building software on a hitherto un- explored compute paradigm in the mainstream: a trustful object messaging compute framework.
1.1. Driving Factors. There are many goals of this project; one key goal is to facilitate transactions between consenting individuals who would otherwise have no means to trust one another. This may be due to geographical separation, interfacing difficulty, or perhaps the incompati- bility, incompetence, unwillingness, expense, uncertainty, inconvenience, or corruption of existing legal systems. By specifying a state-change system through a rich and unam- biguous language, and furthermore architecting a system such that we can reasonably expect that an agreement will be thus enforced autonomously, we can provide a means to this end. Dealings in this proposed system would have several attributes not often found in the real world. The incorrupt- ibility of judgement, often difficult to find, comes naturally from a disinterested algorithmic interpreter. Transparency, or being able to see exactly how a state or judgement came about through the transaction log and rules or instructional codes, never happens perfectly in human-based systems since natural language is necessarily vague, information
is often lacking, and plain old prejudices are difficult to shake. Overall, we wish to provide a system such that users can be guaranteed that no matter with which other indi- viduals, systems or organisations they interact, they can do so with absolute confidence in the possible outcomes and how those outcomes might come about.
1.2. Previous Work. Buterin [2013a] first proposed the kernel of this work in late November, 2013. Though now evolved in many ways, the key functionality of a block- chain with a Turing-complete language and an effectively unlimited inter-transaction storage capability remains un- changed. Dwork and Naor [1992] provided the first work into the usage of a cryptographic proof of computational expendi- ture (“proof-of-work”) as a means of transmitting a value signal over the Internet. The value-signal was utilised here as a spam deterrence mechanism rather than any kind of currency, but critically demonstrated the potential for a basic data channel to carry a strong economic signal, allowing a receiver to make a physical assertion without having to rely upon trust. Back [2002] later produced a system in a similar vein. The first example of utilising the proof-of-work as a strong economic signal to secure a currency was by Vish- numurthy et al. [2003]. In this instance, the token was used to keep peer-to-peer file trading in check, providing “consumers” with the ability to make micro-payments to “suppliers” for their services. The security model afforded by the proof-of-work was augmented with digital signatures and a ledger in order to ensure that the historical record couldn’t be corrupted and that malicious actors could not spoof payment or unjustly complain about service deliv- ery. Five years later, Nakamoto [2008] introduced another such proof-of-work-secured value token, somewhat wider in scope. The fruits of this project, Bitcoin, became the first widely adopted global decentralised transaction ledger. Other projects built on Bitcoin’s success; the alt-coins introduced numerous other currencies through alteration to the protocol. Some of the best known are Litecoin and Primecoin, discussed by Sprankel [2013]. Other projects sought to take the core value content mechanism of the pro- tocol and repurpose it; Aron [2012] discusses, for example, 1
the Namecoin project which aims to provide a decentralised name-resolution system. Other projects still aim to build upon the Bitcoin net- work itself, leveraging the large amount of value placed in the system and the vast amount of computation that goes into the consensus mechanism. The Mastercoin project, first proposed by Willett [2013], aims to build a richer protocol involving many additional high-level features on top of the Bitcoin protocol through utilisation of a number of auxiliary parts to the core protocol. The Coloured Coins project, proposed by Rosenfeld et al. [2012], takes a similar but more simplified strategy, embellishing the rules of a transaction in order to break the fungibility of Bitcoin’s base currency and allow the creation and tracking of tokens through a special “chroma-wallet”-protocol-aware piece of software. Additional work has been done in the area with discard- ing the decentralisation foundation; Ripple, discussed by Boutellier and Heinzen [2014], has sought to create a “fed- erated” system for currency exchange, effectively creating a new financial clearing system. It has demonstrated that high efficiency gains can be made if the decentralisation premise is discarded. Early work on smart contracts has been done by Szabo [1997] and Miller [1997]. Around the 1990s it became clear that algorithmic enforcement of agreements could become a significant force in human cooperation. Though no specific system was proposed to implement such a system, it was proposed that the future of law would be heavily affected by such systems. In this light, Ethereum may be seen as a general implementation of such a crypto-law system. For a list of terms used in this paper, refer to Appen- dix A.
- The Blockchain Paradigm Ethereum, taken as a whole, can be viewed as a transaction-based state machine: we begin with a gen- esis state and incrementally execute transactions to morph it into some current state. It is this current state which we accept as the canonical “version” of the world of Ethereum. The state can include such information as account bal- ances, reputations, trust arrangements, data pertaining to information of the physical world; in short, anything that can currently be represented by a computer is admis- sible. Transactions thus represent a valid arc between two states; the ‘valid’ part is important—there exist far more invalid state changes than valid state changes. Invalid state changes might, e.g., be things such as reducing an account balance without an equal and opposite increase elsewhere. A valid state transition is one which comes about through a transaction. Formally: (1) σt+1 ≡ Υ(σt, T ) where Υ is the Ethereum state transition function. In Ethereum, Υ, together with σ are considerably more pow- erful than any existing comparable system; Υ allows com- ponents to carry out arbitrary computation, while σ allows components to store arbitrary state between transactions. Transactions are collated into blocks; blocks are chained together using a cryptographic hash as a means of refer- ence. Blocks function as a journal, recording a series of transactions together with the previous block and an iden- tifier for the final state (though do not store the final state
itself—that would be far too big). They also punctuate the transaction series with incentives for nodes to mine. This incentivisation takes place as a state-transition function, adding value to a nominated account. Mining is the process of dedicating effort (working) to bolster one series of transactions (a block) over any other potential competitor block. It is achieved thanks to a cryptographically secure proof. This scheme is known as a proof-of-work and is discussed in detail in section 11.5. Formally, we expand to: (2) σt+1 ≡ Π(σt, B) (3) B ≡ (..., (T 0 , T 1 , ...), ...) (4) Π(σ, B) ≡ Ω(B, Υ(Υ(σ, T 0 ), T 1 )...) Where Ω is the block-finalisation state transition func- tion (a function that rewards a nominated party); B is this block, which includes a series of transactions amongst some other components; and Π is the block-level state-transition function. This is the basis of the blockchain paradigm, a model that forms the backbone of not only Ethereum, but all decentralised consensus-based transaction systems to date.
2.1. Value. In order to incentivise computation within the network, there needs to be an agreed method for transmit- ting value. To address this issue, Ethereum has an intrinsic currency, Ether, known also as ETH and sometimes referred to by the Old English (^) ¯D. The smallest subdenomination of Ether, and thus the one in which all integer values of the currency are counted, is the Wei. One Ether is defined as being 10^18 Wei. There exist other subdenominations of Ether: Multiplier Name 100 Wei 1012 Szabo 1015 Finney 1018 Ether Throughout the present work, any reference to value, in the context of Ether, currency, a balance or a payment, should be assumed to be counted in Wei.
2.2. Which History? Since the system is decentralised and all parties have an opportunity to create a new block on some older pre-existing block, the resultant structure is necessarily a tree of blocks. In order to form a consensus as to which path, from root (the genesis block) to leaf (the block containing the most recent transactions) through this tree structure, known as the blockchain, there must be an agreed-upon scheme. If there is ever a disagreement between nodes as to which root-to-leaf path down the block tree is the ‘best’ blockchain, then a fork occurs. This would mean that past a given point in time (block), multiple states of the system may coexist: some nodes be- lieving one block to contain the canonical transactions, other nodes believing some other block to be canonical, potentially containing radically different or incompatible transactions. This is to be avoided at all costs as the un- certainty that would ensue would likely kill all confidence in the entire system. The scheme we use in order to generate consensus is a simplified version of the GHOST protocol introduced by Sompolinsky and Zohar [2013]. This process is described in detail in section 10.
The account state, σ[a], comprises the following four fields: nonce: A scalar value equal to the number of trans- actions sent from this address or, in the case of accounts with associated code, the number of contract-creations made by this account. For ac- count of address a in state σ, this would be for- mally denoted σ[a]n. balance: A scalar value equal to the number of Wei owned by this address. Formally denoted σ[a]b. storageRoot: A 256-bit hash of the root node of a Merkle Patricia tree that encodes the storage con- tents of the account (a mapping between 256-bit integer values), encoded into the trie as a mapping from the Keccak 256-bit hash of the 256-bit integer keys to the RLP-encoded 256-bit integer values. The hash is formally denoted σ[a]s. codeHash: The hash of the EVM code of this account—this is the code that gets executed should this address receive a message call; it is immutable and thus, unlike all other fields, cannot be changed after construction. All such code fragments are contained in the state database under their corre- sponding hashes for later retrieval. This hash is formally denoted σ[a]c, and thus the code may be denoted as b, given that KEC(b) = σ[a]c. Since we typically wish to refer not to the trie’s root hash but to the underlying set of key/value pairs stored within, we define a convenient equivalence:
(7) TRIE
L∗ I (σ[a]s)
≡ σ[a]s
The collapse function for the set of key/value pairs in the trie, L∗ I , is defined as the element-wise transformation of the base function LI, given as:
(8) LI
(k, v)
KEC(k), RLP(v)
where:
(9) k ∈ B 32 ∧ v ∈ N
It shall be understood that σ[a]s is not a ‘physical’ member of the account and does not contribute to its later serialisation. If the codeHash field is the Keccak-256 hash of the empty string, i.e. σ[a]c = KEC
, then the node represents a simple account, sometimes referred to as a “non-contract” account. Thus we may define a world-state collapse function LS:
(10) LS(σ) ≡ {p(a) : σ[a] 6 = ∅}
where
(11) p(a) ≡
KEC(a), RLP
(σ[a]n, σ[a]b, σ[a]s, σ[a]c)
This function, LS, is used alongside the trie function to provide a short identity (hash) of the world state. We assume:
(12) ∀a : σ[a] = ∅ ∨ (a ∈ B 20 ∧ v(σ[a]))
where v is the account validity function:
(13) v(x) ≡ xn ∈ N 256 ∧xb ∈ N 256 ∧xs ∈ B 32 ∧xc ∈ B 32
An account is empty when it has no code, zero nonce and zero balance: (14) EMPTY(σ, a) ≡ σ[a]c = KEC
∧σ[a]n = 0∧σ[a]b = 0
Even callable precompiled contracts can have an empty account state. This is because their account states do not usually contain the code describing its behavior. An account is dead when its account state is non-existent or empty:
(15) DEAD(σ, a) ≡ σ[a] = ∅ ∨ EMPTY(σ, a)
4.2. The Transaction. A transaction (formally, T ) is a single cryptographically-signed instruction constructed by an actor externally to the scope of Ethereum. The sender of a transaction cannot be a contract. While it is assumed that the ultimate external actor will be human in nature, software tools will be used in its construction and dissemi- nation^1. EIP-2718 by Zoltu [2020] introduced the notion of different transaction types. As of the Berlin version of the protocol, there are two transaction types: 0 (legacy) and 1 (EIP-2930 by Buterin and Swende [2020b]). Further, there are two subtypes of transactions: those which result in message calls and those which result in the creation of new accounts with associated code (known informally as ‘contract creation’). All transaction types specify a number of common fields: type: EIP-2718 transaction type; formally Tx. nonce: A scalar value equal to the number of trans- actions sent by the sender; formally Tn. gasPrice: A scalar value equal to the number of Wei to be paid per unit of gas for all computation costs incurred as a result of the execution of this transaction; formally Tp. gasLimit: A scalar value equal to the maximum amount of gas that should be used in executing this transaction. This is paid up-front, before any computation is done and may not be increased later; formally Tg. to: The 160-bit address of the message call’s recipi- ent or, for a contract creation transaction, ∅, used here to denote the only member of B 0 ; formally Tt. value: A scalar value equal to the number of Wei to be transferred to the message call’s recipient or, in the case of contract creation, as an endowment to the newly created account; formally Tv. r, s: Values corresponding to the signature of the transaction and used to determine the sender of the transaction; formally Tr and Ts. This is ex- panded in Appendix F. EIP-2930 (type 1) transactions also have: accessList: List of access entries to warm up; for- mally TA. Each access list entry E is a tuple of an account address and a list of storage keys: E ≡ (Ea, Es). chainId: Chain ID; formally Tc. Must be equal to the network chain ID β. yParity: Signature Y parity; formally Ty. (^1) Notably, 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.
Legacy transactions do not have an accessList (TA = ()), while chainId and yParity for legacy transactions are combined into a single value: w: A scalar value encoding Y parity and possi- bly chain ID; formally Tw. Tw = 27 + Ty or Tw = 2β+35+Ty (see EIP-155 by Buterin [2016b]). Additionally, a contract creation transaction (regardless whether legacy or EIP-2930) contains:
init: An unlimited size byte array specifying the EVM-code for the account initialisation procedure, formally Ti. init is an EVM-code fragment; it returns the body, a second fragment of code that executes each time the account receives a message call (either through a trans- action or due to the internal execution of code). init is executed only once at account creation and gets discarded immediately thereafter. In contrast, a message call transaction contains: data: An unlimited size byte array specifying the input data of the message call, formally Td. Appendix F specifies the function, S, which maps trans- actions to the sender, and happens through the ECDSA of the SECP-256k1 curve, using the hash of the transaction (excepting the latter three signature fields) as the datum to sign. For the present we simply assert that the sender of a given transaction T can be represented with S(T ).
(16)
LT(T ) ≡
(Tn, Tp, Tg, Tt, Tv, p, Tw, Tr, Ts) if Tx = 0 (Tc, Tn, Tp, Tg, Tt, Tv, p, TA, Ty, Tr, Ts) if Tx = 1
where
(17) p ≡
Ti if Tt = ∅ Td otherwise Here, we assume all components are interpreted by the RLP as integer values, with the exception of the access list TA and the arbitrary length byte arrays Ti and Td. (18) Tx ∈ { 0 , 1 } ∧ Tc = β ∧ Tn ∈ N 256 ∧ Tp ∈ N 256 ∧ Tg ∈ N 256 ∧ Tv ∈ N 256 ∧ Tw ∈ N 256 ∧ Tr ∈ N 256 ∧ Ts ∈ N 256 ∧ Ty ∈ N 1 ∧ Td ∈ B ∧ Ti ∈ B
where
(19) Nn = {P : P ∈ N ∧ P < 2 n} The address hash Tt is slightly different: it is either a 20-byte address hash or, in the case of being a contract- creation transaction (and thus formally equal to ∅), it is the RLP empty byte sequence and thus the member of B 0 :
(20) Tt ∈
B 20 if Tt 6 = ∅ B 0 otherwise
4.3. The Block. The block in Ethereum is the collec- tion of relevant pieces of information (known as the block header ), H, together with information corresponding to the comprised transactions, T, and a set of other block headers U that are known to have a parent equal to the present block’s parent’s parent (such blocks are known as ommers^2 ). The block header contains several pieces of information:
parentHash: The Keccak 256-bit hash of the parent block’s header, in its entirety; formally Hp. ommersHash: The Keccak 256-bit hash of the om- mers list portion of this block; formally Ho. beneficiary: The 160-bit address to which all fees collected from the successful mining of this block be transferred; formally Hc. stateRoot: The Keccak 256-bit hash of the root node of the state trie, after all transactions are executed and finalisations applied; formally Hr. transactionsRoot: The Keccak 256-bit hash of the root node of the trie structure populated with each transaction in the transactions list portion of the block; formally Ht. receiptsRoot: The Keccak 256-bit hash of the root node of the trie structure populated with the re- ceipts of each transaction in the transactions list portion of the block; formally He. logsBloom: The Bloom filter composed from index- able information (logger address and log topics) contained in each log entry from the receipt of each transaction in the transactions list; formally Hb. difficulty: A scalar value corresponding to the dif- ficulty level of this block. This can be calculated from the previous block’s difficulty level and the timestamp; formally Hd. number: A scalar value equal to the number of an- cestor blocks. The genesis block has a number of zero; formally Hi. gasLimit: A scalar value equal to the current limit of gas expenditure per block; formally Hl. gasUsed: A scalar value equal to the total gas used 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; formally Hs. extraData: An arbitrary byte array containing data relevant to this block. This must be 32 bytes or fewer; formally Hx. mixHash: A 256-bit hash which, combined with the nonce, proves that a sufficient amount of compu- tation has been carried out on this block; formally Hm. 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 Hn.
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 refer to a block B:
(21) B ≡ (BH, BT, BU)
(^2) ommer is a gender-neutral term to mean “sibling of parent”; see https://nonbinary.miraheze.org/wiki/Gender_neutral_language_in_ English#Aunt/Uncle
The component types are defined thus: (41) Hp ∈ B 32 ∧ Ho ∈ B 32 ∧ Hc ∈ B 20 ∧ Hr ∈ B 32 ∧ Ht ∈ B 32 ∧ He ∈ B 32 ∧ Hb ∈ B 256 ∧ Hd ∈ N ∧ Hi ∈ N ∧ Hl ∈ N ∧ Hg ∈ N ∧ Hs ∈ N 256 ∧ Hx ∈ B ∧ Hm ∈ B 32 ∧ Hn ∈ B 8 where (42) Bn = {B : B ∈ B ∧ ‖B‖ = n} We now have a rigorous specification for the construc- tion of a formal block structure. The RLP function RLP (see Appendix B) provides the canonical method for trans- forming this structure into a sequence of bytes ready for transmission over the wire or storage locally.
4.3.4. Block Header Validity. We define P (BH) to be the parent block of B, formally: (43) P (H) ≡ B′^ : KEC(RLP(B′ H)) = Hp The block number is the parent’s block number incre- mented by one: (44) Hi ≡ P (H)Hi + 1 The canonical difficulty of a block of header H is defined as D(H): (45)
D(H) ≡
234 if Hi = 0 max
Dmin, P (H)Hd + x × ς 2 +
otherwise
where:
(46) Dmin ≡ 217
x ≡
P (H)Hd 2048
ς 2 ≡ max
y −
Hs − P (H)Hs 9
y ≡
1 if ‖P (H)U‖ = 0 2 otherwise
2 bH i′ ÷^100000 c−^2 ⌋ (50)
(51) H i′ ≡ max(Hi − κ, 0) (52)
κ ≡
3000000 if FByzantium 6 Hi < FConstantinople 5000000 if FConstantinople 6 Hi < FMuirGlacier 9000000 if FMuirGlacier 6 Hi < FLondon 9700000 if FLondon 6 Hi < FArrowGlacier 10700000 if Hi > FArrowGlacier The Homestead difficulty parameter, ς 2 , is used to affect a dynamic homeostasis of time between blocks, as the time between blocks varies, as discussed below, as implemented in EIP-2 by Buterin [2015]. In the Homestead release, the exponential difficulty symbol, causes the difficulty to slowly increase (every 100,000 blocks) at an exponential rate, and thus increasing the block time difference, and putting time pressure on transitioning to proof-of-stake. This effect, known as the “difficulty bomb”, or “ice age”, was explained in EIP-649 by Schoedon and Buterin [2017] and delayed and implemented earlier in EIP-2. ς 2 was also modified in EIP-100 with the use of x, the adjustment factor above, and the denominator 9, in order to target the mean block time including uncle blocks by Buterin
[2016a]. In the Byzantium release, with EIP-649, the ice age was delayed by creating a fake block number, H i′ , which is obtained by subtracting three million from the actual block number, which in other words reduced and the time difference between blocks, in order to allow more time to develop proof-of-stake and preventing the network from “freezing” up. Subsequently, EIP-1234 by Schoedon [2018], EIP-2384 by Conner [2019], EIP-3554 by Hancock [2021], and EIP-4345 by Beiko et al. [2021a] increased the subtrahend κ. The canonical gas limit Hl of a block of header H must fulfil the relation:
Hl < P (H)Hl +
P (H)Hl 1024
Hl > P (H)Hl −
P (H)Hl 1024
Hl > 5000
Hs is the timestamp (in Unix’s time()) of block H and must fulfil the relation:
(54) Hs > P (H)Hs
This mechanism enforces a homeostasis in terms of the time between blocks; a smaller period between the last two blocks results in an increase in the difficulty level and thus additional computation required, lengthening the likely next period. Conversely, if the period is too large, the difficulty, and expected time to the next block, is reduced. The nonce, Hn, must satisfy the relations:
(55) n 6
Hd
∧ m = Hm
with (n, m) = PoW(Hn, Hn, d). Where Hn is the new block’s header H, but without the nonce and mix-hash components, d being the current DAG, a large data set needed to compute the mix-hash, and PoW is the proof-of-work function (see section 11.5): this evalu- ates to an array with the first item being the mix-hash, to prove that a correct DAG has been used, and the second item being a pseudo-random number cryptographically dependent on H and d. Given an approximately uniform distribution in the range [0, 264 ), the expected time to find a solution is proportional to the difficulty, Hd. This is the foundation of the security of the blockchain and is the fundamental reason why a malicious node can- not propagate newly created blocks that would otherwise overwrite (“rewrite”) history. Because the nonce must sat- isfy this requirement, and because its satisfaction depends on the contents of the block and in turn its composed transactions, creating new, valid, blocks is difficult and,
over time, requires approximately the total compute power of the trustworthy portion of the mining peers. Thus we are able to define the block header validity function V (H):
V (H) ≡ n 6
Hd
(56) ∧ m = Hm ∧
Hd = D(H) ∧ Hg ≤ Hl ∧
Hl < P (H)Hl +
P (H)Hl 1024
Hl > P (H)Hl −
P (H)Hl 1024
Hl > 5000 ∧ Hs > P (H)Hs ∧ Hi = P (H)Hi + 1 ∧ ‖Hx‖ ≤ 32
where (n, m) = PoW(Hn, Hn, d) Noting additionally that extraData must be at most 32 bytes.
- Gas and Payment In order to avoid issues of network abuse and to sidestep the inevitable questions stemming from Turing complete- ness, all programmable computation in Ethereum is subject to fees. The fee schedule is specified in units of gas (see Ap- pendix G for the fees associated with various computation). Thus any given fragment of programmable computation (this includes creating contracts, making message calls, utilising and accessing account storage and executing op- erations on the virtual machine) has a universally agreed cost in terms of gas. Every transaction has a specific amount of gas associ- ated with it: gasLimit. This is the amount of gas which is implicitly purchased from the sender’s account balance. The purchase happens at the according gasPrice, also specified in the transaction. The transaction is consid- ered invalid if the account balance cannot support such a purchase. It is named gasLimit since any unused gas at the end of the transaction is refunded (at the same rate of purchase) to the sender’s account. Gas does not exist outside of the execution of a transaction. Thus for accounts with trusted code associated, a relatively high gas limit may be set and left alone. In general, Ether used to purchase gas that is not re- funded is delivered to the beneficiary address, the address of an account typically under the control of the miner. Transactors are free to specify any gasPrice that they wish, however miners are free to ignore transactions as they choose. A higher gas price on a transaction will there- fore cost the sender more in terms of Ether and deliver a greater value to the miner and thus will more likely be selected for inclusion by more miners. Miners, in general, will choose to advertise the minimum gas price for which they will execute transactions and transactors will be free to canvas these prices in determining what gas price to offer. Since there will be a (weighted) distribution of min- imum acceptable gas prices, transactors will necessarily have a trade-off to make between lowering the gas price and maximising the chance that their transaction will be mined in a timely manner.
- Transaction Execution The execution of a transaction is the most complex part of the Ethereum protocol: it defines the state transition function Υ. It is assumed that any transactions executed first pass the initial tests of intrinsic validity. These include:
(1) The transaction is well-formed RLP, with no addi- tional trailing bytes; (2) the transaction signature is valid; (3) the transaction nonce is valid (equivalent to the sender account’s current nonce); (4) the sender account has no contract code deployed (see EIP-3607 by Feist et al. [2021]); (5) the gas limit is no smaller than the intrinsic gas, g 0 , used by the transaction; and (6) the sender account balance contains at least the cost, v 0 , required in up-front payment.
Formally, we consider the function Υ, with T being a transaction and σ the state:
(57) σ′^ = Υ(σ, T )
Thus σ′^ is the post-transactional state. We also define Υg^ to evaluate to the amount of gas used in the execution of a transaction, Υl^ to evaluate to the transaction’s accrued log items and Υz^ to evaluate to the status code resulting from the transaction. These will be formally defined later.
6.1. Substate. Throughout transaction execution, we ac- crue certain information that is acted upon immediately following the transaction. We call this the accrued transac- tion substate, or accrued substate for short, and represent it as A, which is a tuple:
(58) A ≡ (As, Al, At, Ar, Aa, AK)
The tuple contents include As, the self-destruct set: a set of accounts that will be discarded following the trans- action’s completion. Al is the log series: this is a series of archived and indexable ‘checkpoints’ in VM code execution that allow for contract-calls to be easily tracked by onlook- ers external to the Ethereum world (such as decentralised application front-ends). At is the set of touched accounts, of which the empty ones are deleted at the end of a transac- tion. Ar is the refund balance, increased through using the SSTORE instruction in order to reset contract storage to zero from some non-zero value. Though not immediately refunded, it is allowed to partially offset the total execution costs. Finally, EIP-2929 by Buterin and Swende [2020a] introduced Aa, the set of accessed account addresses, and AK, the set of accessed storage keys (more accurately, each element of AK is a tuple of a 20-byte account address and a 32-byte storage slot). We define the empty accrued substate A^0 to have no self-destructs, no logs, no touched accounts, zero refund bal- ance, all precompiled contracts in the accessed addresses, and no accessed storage:
(59) A^0 ≡ (∅, (), ∅, 0 , π, ∅)
where π is the set of all precompiled addresses.
Υz, the status code of this transaction:
(80) Υg(σ, T ) ≡ Tg − g∗ (81) Υl(σ, T ) ≡ Al (82) Υz(σ, T ) ≡ z
These are used to help define the transaction receipt and are also used later for state and nonce validation.
- Contract Creation There are a number of intrinsic parameters used when creating an account: sender (s), original transactor^4 (o), available gas (g), gas price (p), endowment (v) together with an arbitrary length byte array, i, the initialisation EVM code, the present depth of the message-call/contract- creation stack (e), the salt for new account’s address (ζ) and finally the permission to make modifications to the state (w). The salt ζ might be missing (ζ = ∅); formally,
(83) ζ ∈ B 32 ∪ B 0
If the creation was caused by CREATE2, then ζ 6 = ∅. We define the creation function formally as the function Λ, which evaluates from these values, together with the state σ and the accrued substate A, to the tuple containing the new state, remaining gas, new accrued substate, status code and output (σ′, g′, A′, z, o):
(84) (σ′, g′, A′, z, o) ≡ Λ(σ, A, s, o, g, p, v, i, e, ζ, w)
The address of the new account is defined as being the rightmost 160 bits of the Keccak-256 hash of the RLP encoding of the structure containing only the sender and the account nonce. For CREATE2 the rule is different and is described in EIP-1014 by Buterin [2018]. Combining the two cases, we define the resultant address for the new account a:
(85) a ≡ ADDR(s, σ[s]n − 1 , ζ, i)
ADDR(s, n, ζ, i) ≡ B 96 .. 255
KEC
LA(s, n, ζ, i)
LA(s, n, ζ, i) ≡
RLP
(s, n)
if ζ = ∅ (255) · s · ζ · KEC(i) otherwise
where · is the concatenation of byte arrays, Ba..b(X) evalu- ates to a binary value containing the bits of indices in the range [a, b] of the binary data X, and σ[x] is the address state of x, or ∅ if none exists. Note we use one fewer than the sender’s nonce value; we assert that we have incre- mented the sender account’s nonce prior to this call, and so the value used is the sender’s nonce at the beginning of the responsible transaction or VM operation. The address of the new account is added to the set of accessed accounts:
(88) A∗^ ≡ A except A∗ a ≡ Aa ∪ {a}
The account’s nonce is initially defined as one, the bal- ance as the value passed, the storage as empty and the code hash as the Keccak 256-bit hash of the empty string; the sender’s balance is also reduced by the value passed. Thus the mutated state becomes σ∗:
(89) σ∗^ ≡ σ except:
σ∗[a] =
1 , v + v′, TRIE(∅), KEC
σ∗[s] =
∅ if σ[s] = ∅ ∧ v = 0 a∗^ otherwise
(92) a∗^ ≡ (σ[s]n, σ[s]b − v, σ[s]s, σ[s]c) where v′^ is the account’s pre-existing value, in the event it was previously in existence:
(93) v′^ ≡
0 if σ[a] = ∅ σ[a]b otherwise Finally, the account is initialised through the execution of the initialising EVM code i according to the execution model (see section 9). Code execution can effect several events that are not internal to the execution state: the account’s storage can be altered, further accounts can be created and further message calls can be made. As such, the code execution function Ξ evaluates to a tuple of the resultant state σ∗∗, available gas remaining g∗∗, the re- sultant accrued substate A∗∗^ and the body code of the account o.
(94) (σ∗∗, g∗∗, A∗∗, o) ≡ Ξ(σ∗, g, A∗, I) where I contains the parameters of the execution environ- ment, that is: (95) Ia ≡ a (96) Io ≡ o (97) Ip ≡ p (98) Id ≡ () (99) Is ≡ s (100) Iv ≡ v (101) Ib ≡ i (102) Ie ≡ e (103) Iw ≡ w Id evaluates to the empty tuple as there is no input data to this call. IH has no special treatment and is determined from the blockchain. Code execution depletes gas, and gas may not go below zero, thus execution may exit before the code has come to a natural halting state. In this (and several other) ex- ceptional cases we say an out-of-gas (OOG) exception has occurred: The evaluated state is defined as being the empty set, ∅, and the entire create operation should have no effect on the state, effectively leaving it as it was immediately prior to attempting the creation. If the initialization code completes successfully, a final contract-creation cost is paid, the code-deposit cost, c, proportional to the size of the created contract’s code: (104) c ≡ Gcodedeposit × ‖o‖ If there is not enough gas remaining to pay this, i.e. g∗∗^ < c, then we also declare an out-of-gas exception. The gas remaining will be zero in any such exceptional condition, i.e. if the creation was conducted as the recep- tion of a transaction, then this doesn’t affect payment of the intrinsic cost of contract creation; it is paid regardless. However, the value of the transaction is not transferred to the aborted contract’s address when we are out-of-gas. (^4) which can differ from the sender in the case of a message call or contract creation not directly triggered by a transaction but coming from the execution of EVM-code
If such an exception does not occur, then the remaining gas is refunded to the originator and the now-altered state is allowed to persist. Thus formally, we may specify the resultant state, gas, accrued substate and status code as (σ′, g′, A′, z) where:
g′^ ≡
0 if F g∗∗^ − c otherwise
σ′^ ≡
σ if F ∨ σ∗∗^ = ∅ σ∗∗^ except: σ′[a] = ∅ if DEAD(σ∗∗, a) σ∗∗^ except: σ′[a]c = KEC(o) otherwise
A′^ ≡
A∗^ if F ∨ σ∗∗^ = ∅ A∗∗^ otherwise
z ≡
0 if F ∨ σ∗∗^ = ∅ 1 otherwise
where
F ≡
σ[a] 6 = ∅ ∧
σ[a]c 6 = KEC
∨ σ[a]n 6 = 0
(σ∗∗^ = ∅ ∧ o = ∅) ∨ g∗∗^ < c ∨ ‖o‖ > 24576 The exception in the determination of σ′^ dictates that o, the resultant byte sequence from the execution of the initialisation code, specifies the final body code for the newly-created account. Note that intention is that the result is either a suc- cessfully created new contract with its endowment, or no new contract with no transfer of value. In addition, ob- serve that if the execution of the initialising code reverts (σ∗∗^ = ∅ ∧ o 6 = ∅), the resultant gas g′^ is not depleted (provided there was no other exception), but no new ac- count is created.
7.1. Subtleties. Note that while the initialisation code is executing, the newly created address exists but with no intrinsic body code^5. Thus any message call received by it during this time causes no code to be executed. If the initialisation execution ends with a SELFDESTRUCT instruction, the matter is moot since the account will be deleted before the transaction is completed. For a normal 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.
- Message Call In the case of executing a message call, several param- eters are required: sender (s), transaction originator (o), recipient (r), the account whose code is to be executed (c,
usually the same as recipient), available gas (g), value (v) and gas price (p) together with an arbitrary length byte array, d, the input data of the call, the present depth of the message-call/contract-creation stack (e) and finally the permission to make modifications to the state (w). Aside from evaluating to a new state and accrued transaction substate, message calls also have an extra component—the output data denoted by the byte array o. This is ignored when executing transactions, however mes- sage calls can be initiated due to VM-code execution and in this case this information is used. (110) (σ′, g′, A′, z, o) ≡ Θ(σ, A, s, o, r, c, g, p, v, v,˜ d, e, w)
Note that we need to differentiate between the value that is to be transferred, v, from the value apparent in the execution context, ˜v, for the DELEGATECALL instruction. We define σ 1 , the first transitional state as the orig- inal state but with the value transferred from sender to recipient:
(111) σ 1 [r]b ≡ σ[r]b + v ∧ σ 1 [s]b ≡ σ[s]b − v
unless s = r. Throughout the present work, it is assumed that if σ 1 [r] was originally undefined, it will be created as an account with no code or state and zero balance and nonce. Thus the previous equation should be taken to mean:
(112) σ 1 ≡ σ′ 1 except:
(113) σ 1 [s] ≡
∅ if σ′ 1 [s] = ∅ ∧ v = 0 a 1 otherwise
(114) a 1 ≡
σ′ 1 [s]n, σ′ 1 [s]b − v, σ′ 1 [s]s, σ′ 1 [s]c
(115) and σ′ 1 ≡ σ except:
σ′ 1 [r] ≡ (0, v, TRIE(∅), KEC(())) if σ[r] = ∅ ∧ v 6 = 0 σ′ 1 [r] ≡ ∅ if σ[r] = ∅ ∧ v = 0 σ′ 1 [r] ≡ a′ 1 otherwise
(117) a′ 1 ≡ (σ[r]n, σ[r]b + v, σ[r]s, σ[r]c)
The account’s associated code (identified as the frag- ment whose Keccak-256 hash is σ[c]c) is executed according to the execution model (see section 9). Just as with con- tract creation, if the execution halts in an exceptional fashion (i.e. due to an exhausted gas supply, stack under- flow, invalid jump destination or invalid instruction), then no gas is refunded to the caller and the state is reverted to the point immediately prior to balance transfer (i.e. σ). (^5) During 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).
9.3. Execution Environment. In addition to the sys- tem state σ, the remaining gas for computation g, and the accrued substate A, there are several pieces of important information used in the execution environment that the execution agent must provide; these are contained in the tuple I:
- Ia, the address of the account which owns the code that is executing.
- Io, the sender address of the transaction that orig- inated this execution.
- Ip, the price of gas in the transaction that origi- nated this execution.
- Id, the byte array that is the input data to this execution; if the execution agent is a transaction, this would be the transaction data.
- Is, the address of the account which caused the code to be executing; if the execution agent is a transaction, this would be the transaction sender.
- Iv, the value, in Wei, passed to this account as part of the same procedure as execution; if the execution agent is a transaction, this would be the transaction value.
- Ib, the byte array that is the machine code to be executed.
- IH, the block header of the present block.
- Ie, the depth of the present message-call or contract-creation (i.e. the number of CALLs or CREATE(2)s being executed at present).
- Iw, the permission to make modifications to the state.
The execution model defines the function Ξ, which can compute the resultant state σ′, the remaining gas g′, the resultant accrued substate A′^ and the resultant output, o, given these definitions. For the present context, we will define it as:
(134) (σ′, g′, A′, o) ≡ Ξ(σ, g, A, I)
where we will remember that A, the accrued substate, is defined in section 6.1.
9.4. Execution Overview. We must now define the Ξ function. In most practical implementations this will be modelled as an iterative progression of the pair comprising the full system state, σ and the machine state, μ. For- mally, we define it recursively with a function X. This uses an iterator function O (which defines the result of a single cycle of the state machine) together with functions Z which determines if the present state is an exceptional halting state of the machine and H, specifying the output data of the instruction if and only if the present state is a normal halting state of the machine. The empty sequence, denoted (), is not equal to the empty set, denoted ∅; this is important when interpreting the output of H, which evaluates to ∅ when execution is to continue but a series (potentially empty) when execution
should halt.
(135) Ξ(σ, g, A, I) ≡ (σ′, μ′ g, A′, o) (σ′, μ′, A′, ..., o) ≡ X
(σ, μ, A, I)
(137) μg ≡ g (138) μpc ≡ 0 (139) μm ≡ (0, 0 , ...) (140) μi ≡ 0 (141) μs ≡ () (142) μo ≡ ()
X
(σ, μ, A, I)
∅, μ, A, I, ∅
if Z(σ, μ, A, I) ( ∅, μ′, A, I, o
if w = REVERT O(σ, μ, A, I) · o if o 6 = ∅ X
O(σ, μ, A, I)
otherwise
where
(144) o ≡ H(μ, I) (145) (a, b, c, d) · e ≡ (a, b, c, d, e) (146) μ′^ ≡ μ except: (147) μ′ g ≡ μg − C(σ, μ, A, I)
Note that, when we evaluate Ξ, we drop the fourth element I′^ and extract the remaining gas μ′ g from the resultant machine state μ′. X is thus cycled (recursively here, but implementations are generally expected to use a simple iterative loop) until either Z becomes true indicating that the present state is exceptional and that the machine must be halted and any changes discarded or until H becomes a series (rather than the empty set) indicating that the machine has reached a controlled halt.
9.4.1. Machine State. The machine state μ is defined as the tuple (g, pc, m, i, s) which are the gas available, the program counter pc ∈ N 256 , the memory contents, the active number of words in memory (counting continuously from position 0), and the stack contents. The memory contents μm are a series of zeroes of size 2^256. For the ease of reading, the instruction mnemonics, written in small-caps (e.g. ADD), should be interpreted as their numeric equivalents; the full table of instructions and their specifics is given in Appendix H. For the purposes of defining Z, H and O, we define w as the current operation to be executed:
(148) w ≡
Ib[μpc] if μpc < ‖Ib‖ STOP otherwise
We also assume the fixed amounts of δ and α, specifying the stack items removed and added, both subscriptable on the instruction and an instruction cost function C eval- uating to the full cost, in gas, of executing the given instruction.
9.4.2. Exceptional Halting. The exceptional halting func- tion Z is defined as: (149) Z(σ, μ, A, I) ≡ μg < C(σ, μ, A, I) ∨ δw = ∅ ∨ ‖μs‖ < δw ∨ (w = JUMP ∧ μs[0] ∈/ D(Ib)) ∨ (w = JUMPI ∧ μs[1] 6 = 0 ∧ μs[0] ∈/ D(Ib)) ∨ (w = RETURNDATACOPY ∧ μs[1] + μs[2] > ‖μo‖) ∨ ‖μs‖ − δw + αw > 1024 ∨ (¬Iw ∧ W (w, μ)) ∨ (w = SSTORE ∧ μg 6 Gcallstipend)
where
(150) W (w, μ) ≡ w ∈ {CREATE, CREATE2, SSTORE, SELFDESTRUCT} ∨ LOG0 ≤ w ∧ w ≤ LOG4 ∨ w = CALL ∧ μs[2] 6 = 0
This states that the execution is in an exceptional halt- ing state if there is insufficient gas, if the instruction is invalid (and therefore its δ subscript is undefined), if there are insufficient stack items, if a JUMP/JUMPI destination is invalid, the new stack size would be larger than 1024 or state modification is attempted during a static call. The as- tute reader will realise that this implies that no instruction can, through its execution, cause an exceptional halt. Also, the execution is in an exceptional halting state if the gas left prior to executing an SSTORE instruction is less than or equal to the call stipend Gcallstipend. The last condition was introduced in EIP-1706 by Forshtat and Weiss [2019] (part of EIP-2200 by Tang [2019]).
9.4.3. Jump Destination Validity. We previously used D as the function to determine the set of valid jump desti- nations given the code that is being run. We define this as any position in the code occupied by a JUMPDEST instruction. All such positions must be on valid instruction bound- aries, rather than sitting in the data portion of PUSH operations and must appear within the explicitly defined portion of the code (rather than in the implicitly defined STOP operations that trail it). Formally:
(151) D(c) ≡ DJ(c, 0)
where: (152)
DJ(c, i) ≡
{} if i > ‖c‖ {i} ∪ DJ(c, N (i, c[i])) if c[i] = JUMPDEST DJ(c, N (i, c[i])) otherwise
where N is the next valid instruction position in the code, skipping the data of a PUSH instruction, if any: (153)
N (i, w) ≡
i + w − PUSH1 + 2 if w ∈ [PUSH1, PUSH32] i + 1 otherwise
9.4.4. Normal Halting. The normal halting function H is defined: (154)
H(μ, I) ≡
HRETURN(μ) if w ∈ {RETURN, REVERT} () if w ∈ {STOP, SELFDESTRUCT} ∅ otherwise
The data-returning halt operations, RETURN and REVERT, have a special function HRETURN. Note also the difference between the empty sequence and the empty set as discussed here.
9.5. The Execution Cycle. Stack items are added or removed from the left-most, lower-indexed portion of the series; all other items remain unchanged:
O
(σ, μ, A, I)
(155) ≡ (σ′, μ′, A′, I) (156) ∆ ≡ αw − δw (157) ‖μ′ s‖ ≡ ‖μs‖ + ∆ (158) ∀x ∈ [αw , ‖μ′ s‖) : μ′ s[x] ≡ μs[x − ∆]
The gas is reduced by the instruction’s gas cost and for most instructions, the program counter increments on each cycle, for the three exceptions, we assume a function J, subscripted by one of two instructions, which evaluates to the according value:
(159) μ′ g ≡ μg − C(σ, μ, A, I)
μ′ pc ≡
JJUMP(μ) if w = JUMP JJUMPI(μ) if w = JUMPI N (μpc, w) otherwise
In general, we assume the memory, accrued substate and system state do not change:
(161) μ′ m ≡ μm (162) μ′ i ≡ μi (163) A′^ ≡ A (164) σ′^ ≡ σ
However, instructions do typically alter one or several components of these values. Altered components listed by instruction are noted in Appendix H, alongside values for α and δ and a formal description of the gas requirements.
- Blocktree to Blockchain The canonical blockchain is a path from root to leaf through the entire block tree. In order to have consensus over which path it is, conceptually we identify the path that has had the most computation done upon it, or, the heaviest path. Clearly one factor that helps determine the heaviest path is the block number of the leaf, equivalent to the number of blocks, not counting the unmined genesis block, in the path. The longer the path, the greater the total mining effort that must have been done in order to arrive at the leaf. This is akin to existing schemes, such as that employed in Bitcoin-derived protocols. Since a block header includes the difficulty, the header alone is enough to validate the computation done. Any block contributes toward the total computation or total difficulty of a chain.
Finally, we define Π as the new state given the block re- ward function Ω applied to the final transaction’s resultant state, (σ): (186) Π(σ, B) ≡ Ω(B,(σ)) Thus the complete block-transition mechanism is de- fined, except for PoW, the proof-of-work function.
11.5. Mining Proof-of-Work. The mining proof-of- work (PoW) exists as a cryptographically secure nonce that proves beyond reasonable doubt that a particular amount of computation has been expended in the deter- mination of some token value n. It is utilised to enforce the blockchain security by giving meaning and credence to the notion of difficulty (and, by extension, total dif- ficulty). However, since mining new blocks comes with an attached reward, the proof-of-work not only functions as a method of securing confidence that the blockchain will remain canonical into the future, but also as a wealth distribution mechanism. For both reasons, there are two important goals of the proof-of-work function; firstly, it should be as accessible as possible to as many people as possible. The requirement of, or reward from, specialised and uncommon hardware should be minimised. This makes the distribution model as open as possible, and, ideally, makes the act of mining a simple swap from electricity to Ether at roughly the same rate for anyone around the world. Secondly, it should not be possible to make super-linear profits, and especially not so with a high initial barrier. Such a mechanism allows a well-funded adversary to gain a troublesome amount of the network’s total mining power and as such gives them a super-linear reward (thus skewing distribution in their favour) as well as reducing the network security. One plague of the Bitcoin world is ASICs. These are specialised pieces of compute hardware that exist only to do a single task (Smith [1997]). In Bitcoin’s case the task is the SHA256 hash function (Courtois et al. [2014]). While ASICs exist for a proof-of-work function, both goals are placed in jeopardy. Because of this, a proof-of-work func- tion that is ASIC-resistant (i.e. difficult or economically inefficient to implement in specialised compute hardware) has been identified as the proverbial silver bullet. Two directions exist for ASIC resistance; firstly make it sequential memory-hard, i.e. engineer the function such that the determination of the nonce requires a lot of mem- ory and bandwidth such that the memory cannot be used in parallel to discover multiple nonces simultaneously. The second is to make the type of computation it would need to do general-purpose; the meaning of “specialised hardware” for a general-purpose task set is, naturally, general purpose hardware and as such commodity desktop computers are likely to be pretty close to “specialised hardware” for the task. For Ethereum 1.0 we have chosen the first path. More formally, the proof-of-work function takes the form of PoW: (187) m = Hm ∧ n 6 2
256 Hd
with (m, n) = PoW(Hn, Hn, d)
Where Hn is the new block’s header but without the nonce and mix-hash components; Hn is the nonce of the header; d is a large data set needed to compute the mix- Hash and Hd is the new block’s difficulty value (i.e. the
block difficulty from section 10). PoW is the proof-of-work function which evaluates to an array with the first item being the mixHash and the second item being a pseudo- random number cryptographically dependent on H and d. The underlying algorithm is called Ethash and is described below.
11.5.1. Ethash. Ethash is the PoW algorithm for Ethereum 1.0. It is the latest version of Dagger-Hashimoto, intro- duced by Buterin [2013b] and Dryja [2014], although it can no longer appropriately be called that since many of the original features of both algorithms were drastically changed with R&D from February 2015 until May 4 2015 (Jentzsch [2015]). The general route that the algorithm takes is as follows: There exists a seed which can be computed for each block by scanning through the block headers up until that point. From the seed, one can compute a pseudorandom cache, Jcacheinit bytes in initial size. Light clients store the cache. From the cache, we can generate a dataset, Jdatasetinit bytes in initial size, with the property that each item in the dataset depends on only a small number of items from the cache. Full clients and miners store the dataset. The dataset grows linearly with time. Mining involves grabbing random slices of the dataset and hashing them together. Verification can be done with low memory by using the cache to regenerate the specific pieces of the dataset that you need, so you only need to store the cache. The large dataset is updated once every Jepoch blocks, so the vast majority of a miner’s effort will be reading the dataset, not making changes to it. The mentioned parameters as well as the algorithm is explained in detail in Appendix J.
- Implementing Contracts There are several patterns of contracts engineering that allow particular useful behaviours; two of these that we will briefly discuss are data feeds and random numbers.
12.1. Data Feeds. A data feed contract is one which pro- vides a single service: it gives access to information from the external world within Ethereum. The accuracy and timeliness of this information is not guaranteed and it is the task of a secondary contract author—the contract that utilises the data feed—to determine how much trust can be placed in any single data feed. The general pattern involves a single contract within Ethereum which, when given a message call, replies with some timely information concerning an external phenome- non. An example might be the local temperature of New York City. This would be implemented as a contract that returned that value of some known point in storage. Of course this point in storage must be maintained with the correct such temperature, and thus the second part of the pattern would be for an external server to run an Ethereum node, and immediately on discovery of a new block, creates a new valid transaction, sent to the contract, updating said value in storage. The contract’s code would accept such updates only from the identity contained on said server.
12.2. Random Numbers. Providing random numbers within a deterministic system is, naturally, an impossible task. However, we can approximate with pseudo-random numbers by utilising data which is generally unknowable
at the time of transacting. Such data might include the block’s hash, the block’s timestamp and the block’s benefi- ciary address. In order to make it hard for malicious miners to control those values, one should use the BLOCKHASH operation in order to use hashes of the previous 256 blocks as pseudo-random numbers. For a series of such numbers, a trivial solution would be to add some constant amount and hashing the result.
- Future Directions The state database won’t be forced to maintain all past state trie structures into the future. It should maintain an age for each node and eventually discard nodes that are neither recent enough nor checkpoints. Checkpoints, or a set of nodes in the database that allow a particular block’s state trie to be traversed, could be used to place a maximum limit on the amount of computation needed in order to retrieve any state throughout the blockchain. Blockchain consolidation could be used in order to re- duce the amount of blocks a client would need to download to act as a full, mining, node. A compressed archive of the trie structure at given points in time (perhaps one in every 10,000th block) could be maintained by the peer network, effectively recasting the genesis block. This would reduce the amount to be downloaded to a single archive plus a hard maximum limit of blocks. Finally, blockchain compression could perhaps be con- ducted: nodes in state trie that haven’t sent/received a transaction in some constant amount of blocks could be thrown out, reducing both Ether-leakage and the growth of the state database.
13.1. Scalability. Scalability remains an eternal concern. With a generalised state transition function, it becomes dif- ficult to partition and parallelise transactions to apply the divide-and-conquer strategy. Unaddressed, the dynamic value-range of the system remains essentially fixed and as the average transaction value increases, the less valuable of them become ignored, being economically pointless to in- clude in the main ledger. However, several strategies exist that may potentially be exploited to provide a considerably more scalable protocol. Some form of hierarchical structure, achieved by either consolidating smaller lighter-weight chains into the main block or building the main block through the incremen- tal combination and adhesion (through proof-of-work) of smaller transaction sets may allow parallelisation of trans- action combination and block-building. Parallelism could also come from a prioritised set of parallel blockchains, consolidating each block and with duplicate or invalid transactions thrown out accordingly. Finally, verifiable computation, if made generally avail- able and efficient enough, may provide a route to allow the proof-of-work to be the verification of final state.
- Conclusion
We have introduced, discussed and formally defined the protocol of Ethereum. Through this protocol the reader may implement a node on the Ethereum network and join others in a decentralised secure social operating system. Contracts may be authored in order to algorithmically specify and autonomously enforce rules of interaction.
- Acknowledgements Many thanks to Aeron Buchanan for authoring the Homestead revisions, Christoph Jentzsch for authoring the Ethash algorithm and Yoichi Hirai for doing most of the EIP-150 changes. Important maintenance, useful correc- tions and suggestions were provided by a number of others from the Ethereum DEV organisation and Ethereum com- munity at large including Gustav Simonsson, Pawel Bylica, Jutta Steiner, Nick Savers, Viktor Tr´on, Marko Simovic, Giacomo Tazzari and, of course, Vitalik Buterin.
- Availability The source of this paper is maintained at https: //github.com/ethereum/yellowpaper/. An auto- generated PDF is located at https://ethereum.github. io/yellowpaper/paper.pdf.
References Jacob Aron. BitCoin software finds new life. New Scientist, 213(2847):20, 2012. URL http://www.sciencedirect. com/science/article/pii/S0262407912601055. Adam Back. Hashcash - Amortizable Publicly Auditable Cost-Functions, 2002. URL http://www.hashcash.org/ papers/amortizable.pdf. Tim Beiko, James Hancock, and Thomas Jay Rush. EIP- 4345: Difficulty bomb delay to June 2022, October 2021a. URL https://eips.ethereum.org/EIPS/eip-4345. Tim Beiko et al. Berlin network upgrade specifica- tion, 2021b. URL https://github.com/ethereum/ eth1.0-specs/blob/master/network-upgrades/ mainnet-upgrades/berlin.md. Guido Bertoni, Joan Daemen, Michal Peeters, and Gilles Van Assche. The KECCAK SHA-3 sub- mission, 2011. URL https://keccak.team/files/ Keccak-submission-3.pdf. Roman Boutellier and Mareike Heinzen. Pirates, Pio- neers, Innovators and Imitators. In Growth Through Innovation, pages 85–96. Springer, 2014. URL https: //www.springer.com/gb/book/9783319040158. Vitalik Buterin. Ethereum: A Next-Generation Smart Contract and Decentralized Application Platform, 2013a. URL https://github.com/ethereum/wiki/ wiki/White-Paper. Vitalik Buterin. Dagger: A Memory-Hard to Compute, Memory-Easy to Verify Scrypt Alternative, 2013b. URL http://www.hashcash.org/papers/dagger.html. Vitalik Buterin. EIP-2: Homestead hard-fork changes,
- URL https://eips.ethereum.org/EIPS/eip-2. Vitalik Buterin. EIP-100: Change difficulty adjustment to target mean block time including uncles, April 2016a. URL https://eips.ethereum.org/EIPS/eip-100. Vitalik Buterin. EIP-155: Simple replay attack protec- tion, October 2016b. URL https://eips.ethereum. org/EIPS/eip-155. Vitalik Buterin. EIP-1014: Skinny CREATE2, April 2018. URL https://eips.ethereum.org/EIPS/eip-1014. Vitalik Buterin and Martin Swende. EIP-2929: Gas cost in- creases for state access opcodes, September 2020a. URL https://eips.ethereum.org/EIPS/eip-2929. Vitalik Buterin and Martin Swende. EIP-2930: Optional ac- cess lists, August 2020b. URL https://eips.ethereum. org/EIPS/eip-2930.
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:
(188) T ≡ L ] B
(189) L ≡ {t : t = (t[0], t[1], ...) ∧ ∀n < ‖t‖ : t[n] ∈ T}
(190) B ≡ {b : b = (b[0], b[1], ...) ∧ ∀n < ‖b‖ : 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:
(191) RLP(x) ≡
Rb(x) if x ∈ B 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 2^64 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 2^64 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:
Rb(x) ≡
x if ‖x‖ = 1 ∧ x[0] < 128 (128 + ‖x‖) · x else if ‖x‖ < 56 ( 183 +
∥BE(‖x‖)
∥)^ · BE(‖x‖) · x else if ‖x‖ < 264 ∅ otherwise
BE(x) ≡ (b 0 , b 1 , ...) : b 0 6 = 0 ∧ x =
‖b ∑‖− 1
n=
(193) bn · 256 ‖b‖−^1 −n
(194) (x 1 , ..., xn) · (y 1 , ..., ym) = (x 1 , ..., xn, y 1 , ..., 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 2^64 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 2^64 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:
Rl(x) ≡
(192 + ‖s(x)‖) · s(x) if s(x) 6 = ∅ ∧ ‖s(x)‖ < 56 ( 247 +
BE(‖s(x)‖)
· BE(‖s(x)‖) · s(x) else if s(x) 6 = ∅ ∧ ‖s(x)‖ < 264 ∅ otherwise
s(x) ≡
RLP(x[0]) · RLP(x[1]) · ... if ∀i : RLP(x[i]) 6 = ∅ ∅ 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:
(197) 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):
HP(x, t) : x ∈ Y ≡
(16f (t), 16 x[0] + x[1], 16 x[2] + x[3], ...) if ‖x‖ is even (16(f (t) + 1) + x[0], 16 x[1] + x[2], 16 x[3] + x[4], ...) otherwise
f (t) ≡
2 if t 6 = 0 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.
