以太坊：黄皮书1资源-CSDN文库

需积分: 0 17 浏览量 2022-08-03 15:44:28 上传评论收藏 561KB PDF 举报

身份认证购VIP最低享 7 折!

领优惠券(最高得80元）

资源详情

资源评论

资源推荐

ETHEREUM: A SECURE DECENTRALISED GENERALISED TRANSACTION LEDGER

PETERSBURG VERSION 3e2c089 – 2020-09-05

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.

1. 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 diﬃculty, 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 diﬃcult to ﬁnd, 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 diﬃcult 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 conﬁdence in the possible outcomes

and how those outcomes might come about.

1.2.

Previous Work.

Buterin [2013a] ﬁrst 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 eﬀectively

unlimited inter-transaction storage capability remains un-

changed.

Dwork and Naor [1992] provided the ﬁrst 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 ﬁrst 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 ﬁle trading in check, providing

“consumers” with the ability to make micro-payments to

“suppliers” for their services. The security model aﬀorded

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 ﬁrst

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,

ETHEREUM: A SECURE DECENTRALISED GENERALISED TRANSACTION LEDGER 2

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,

ﬁrst 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 simpliﬁed 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, eﬀectively creating

a new ﬁnancial clearing system. It has demonstrated that

high eﬃciency 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

signiﬁcant force in human cooperation. Though no speciﬁc

system was proposed to implement such a system, it was

proposed that the future of law would be heavily aﬀected

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 Appendix

2. 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 )

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-

tiﬁer for the ﬁnal state (though do not store the ﬁnal 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 eﬀort (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:

t+1

≡ Π(σ

, B)(2)

B ≡ (..., (T

, T

, ...), ...)(3)

Π(σ, B) ≡ Ω(B, Υ(Υ(σ, T

), T

)...)(4)

Where Ω is the block-ﬁnalisation state transition func-

tion (a function that rewards a nominated party);

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 deﬁned

as being 10

Wei. There exist other subdenominations of

Ether:

Multiplier Name

Wei

Szabo

Finney

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 diﬀerent or incompatible

transactions. This is to be avoided at all costs as the un-

certainty that would ensue would likely kill all conﬁdence

in the entire system.

The scheme we use in order to generate consensus is a

simpliﬁed version of the GHOST protocol introduced by

Sompolinsky and Zohar [2013]. This process is described

in detail in section 10.

ETHEREUM: A SECURE DECENTRALISED GENERALISED TRANSACTION LEDGER 3

Sometimes, a path follows a new protocol from a par-

ticular height (block number). This document describes

one version of the protocol. In order to follow back the

history of a path, one must reference multiple versions of

this document.

3. Conventions

We use a number of typographical conventions for the

formal notation, some of which are quite particular to the

present work:

The two sets of highly structured, ‘top-level’, state val-

ues, are denoted with bold lowercase Greek letters. They

fall into those of world-state, which are denoted

(or a

variant thereupon) and those of machine-state, µ.

Functions operating on highly structured values are

denoted with an upper-case Greek letter, e.g. Υ, the

Ethereum state transition function.

For most functions, an uppercase letter is used, e.g.

the general cost function. These may be subscripted to

denote specialised variants, e.g.

SSTORE

, the cost func-

tion for the

SSTORE

operation. For specialised and possibly

externally deﬁned functions, we may format as typewriter

text, e.g. the Keccak-256 hash function (as per version

3 of the winning entry to the SHA-3 contest by Bertoni

et al. [2011], rather than the ﬁnal SHA-3 speciﬁcation), is

denoted

KEC

(and generally referred to as plain Keccak).

Also, KEC512 refers to the Keccak-512 hash function.

Tuples are typically denoted with an upper-case letter,

e.g.

, is used to denote an Ethereum transaction. This

symbol may, if accordingly deﬁned, be subscripted to refer

to an individual component, e.g.

, denotes the nonce

of said transaction. The form of the subscript is used to

denote its type; e.g. uppercase subscripts refer to tuples

with subscriptable components.

Scalars and ﬁxed-size byte sequences (or, synonymously,

arrays) are denoted with a normal lower-case letter, e.g.

is used in the document to denote a transaction nonce.

Those with a particularly special meaning may be Greek,

e.g.

, the number of items required on the stack for a

given operation.

Arbitrary-length sequences are typically denoted as a

bold lower-case letter, e.g.

is used to denote the byte

sequence given as the output data of a message call. For

particularly important values, a bold uppercase letter may

be used.

Throughout, we assume scalars are non-negative inte-

gers and thus belong to the set

. The set of all byte

sequences is

, formally deﬁned in Appendix B. If such

a set of sequences is restricted to those of a particular

length, it is denoted with a subscript, thus the set of all

byte sequences of length 32 is named

and the set of

all non-negative integers smaller than 2

256

is named

256

This is formally deﬁned in section 4.3.

Square brackets are used to index into and reference

individual components or subsequences of sequences, e.g.

[0] denotes the ﬁrst item on the machine’s stack. For

subsequences, ellipses are used to specify the intended

range, to include elements at both limits, e.g.

31]

denotes the ﬁrst 32 items of the machine’s memory.

In the case of the global state

, which is a sequence of

accounts, themselves tuples, the square brackets are used

to reference an individual account.

When considering variants of existing values, we follow

the rule that within a given scope for deﬁnition, if we

assume that the unmodiﬁed ‘input’ value be denoted by

the placeholder



then the modiﬁed and utilisable value is

denoted as



, and intermediate values would be



∗



∗∗

&c. On very particular occasions, in order to maximise

readability and only if unambiguous in meaning, we may

use alpha-numeric subscripts to denote intermediate values,

especially those of particular note.

When considering the use of existing functions, given a

function

, the function

∗

denotes a similar, element-wise

version of the function mapping instead between sequences.

It is formally deﬁned in section 4.3.

We deﬁne a number of useful functions throughout. One

of the more common is

, which evaluates to the last item

in the given sequence:

(5) `(x) ≡ x[kxk − 1]

4. Blocks, State and Transactions

Having introduced the basic concepts behind Ethereum,

we will discuss the meaning of a transaction, a block and

the state in more detail.

4.1.

World State.

The world state (state), is a map-

ping between addresses (160-bit identiﬁers) and account

states (a data structure serialised as RLP, see Appendix

B). Though not stored on the blockchain, it is assumed

that the implementation will maintain this mapping in

a modiﬁed Merkle Patricia tree (trie, see Appendix D).

The trie requires a simple database backend that main-

tains a mapping of byte arrays to byte arrays; we name

this underlying database the state database. This has a

number of beneﬁts; ﬁrstly the root node of this structure

is cryptographically dependent on all internal data and

as such its hash can be used as a secure identity for the

entire system state. Secondly, being an immutable data

structure, it allows any previous state (whose root hash

is known) to be recalled by simply altering the root hash

accordingly. Since we store all such root hashes in the

blockchain, we are able to trivially revert to old states.

The account state,

[

], comprises the following four

ﬁelds:

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

in state

, this would be for-

mally denoted σ[a]

balance:

A scalar value equal to the number of Wei

owned by this address. Formally denoted σ[a]

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]

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 ﬁelds, cannot be changed

after construction. All such code fragments are

ETHEREUM: A SECURE DECENTRALISED GENERALISED TRANSACTION LEDGER 4

contained in the state database under their corre-

sponding hashes for later retrieval. This hash is

formally denoted

[

]

, and thus the code may be

denoted as b, given that KEC(b) = σ[a]

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 deﬁne a convenient equivalence:

(6) TRIE



∗

(σ[a]

)



≡ σ[a]

The collapse function for the set of key/value pairs in

the trie,

∗

, is deﬁned as the element-wise transformation

of the base function L

, given as:

(7) L



(k, v)



≡



KEC(k), RLP(v)



where:

(8) k ∈ B

∧ v ∈ N

It shall be understood that

[

]

is not a ‘physical’

member of the account and does not contribute to its later

serialisation.

If the

codeHash

ﬁeld is the Keccak-256 hash of the

empty string, i.e.

[

]

KEC



()



, then the node represents

a simple account, sometimes referred to as a “non-contract”

account.

Thus we may deﬁne a world-state collapse function

(9) L

(σ) ≡ {p(a) : σ[a] 6= ∅}

where

(10) p(a) ≡



KEC(a), RLP



(σ[a]

, σ[a]

)



This function,

, is used alongside the trie function

to provide a short identity (hash) of the world state. We

assume:

(11) ∀a : σ[a] = ∅ ∨ (a ∈ B

∧ v(σ[a]))

where v is the account validity function:

(12) v(x) ≡ x

∈ N

256

∧x

∈ N

256

∧x

∈ B

∧x

∈ B

An account is empty when it has no code, zero nonce

and zero balance:

(13)

EMPTY(σ, a) ≡ σ[a]

= KEC



()



∧σ[a]

= 0∧σ[a]

= 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:

(14) DEAD(σ, a) ≡ σ[a] = ∅ ∨ EMPTY(σ, a)

4.2.

The Transaction.

A transaction (formally,

) is a

single cryptographically-signed instruction constructed by

an actor externally to the scope of Ethereum. While it is

assumed that the ultimate external actor will be human in

nature, software tools will be used in its construction and

dissemination

. There are two types 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’). Both types specify a

number of common ﬁelds:

nonce:

A scalar value equal to the number of trans-

actions sent by the sender; formally T

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 T

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 T

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

; formally

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 T

v, r, s:

Values corresponding to the signature of the

transaction and used to determine the sender of

the transaction; formally

and

. This is

expanded in Appendix F.

Additionally, a contract creation transaction contains:

init:

An unlimited size byte array specifying the

EVM-code for the account initialisation procedure,

formally T

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

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 T

Appendix F speciﬁes the function,

, 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 ﬁelds) as the datum

to sign. For the present we simply assert that the sender