以太坊黄皮书英文版资源-CSDN文库

需积分: 10 165 浏览量 2018-03-15 10:13:53 上传评论收藏 584KB PDF 举报

资源推荐

资源详情

资源评论

ETHEREUM: A SECURE DECENTRALISED GENERALISED TRANSACTION LEDGER

BYZANTIUM VERSION 7aa0e4c - 2018-03-12

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 BYZANTIUM VERSION 7aa0e4c - 2018-03-12 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 ﬁnal state. It is this ﬁnal 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 then 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 BYZANTIUM VERSION 7aa0e4c - 2018-03-12 3

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

ticular height. 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 the winning

entry to the SHA-3 contest by Bertoni et al. [2017], rather

than later releases), is denoted

KEC

(and generally referred

to as plain Keccak). Also

KEC512

is referring 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 positive integers 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 positive 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 maintains a

mapping of bytearrays to bytearrays; we name this under-

lying database the state database. This has a number of

beneﬁts; ﬁrstly the root node of this structure is crypto-

graphically 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

contained in the state database under their corre-

sponding hashes for later retrieval. This hash is

ETHEREUM: A SECURE DECENTRALISED GENERALISED TRANSACTION LEDGER BYZANTIUM VERSION 7aa0e4c - 2018-03-12 4

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

of a given transaction T can be represented with S(T ).

(15)

(T ) ≡

(

, T

) if T

= ∅

, T

) otherwise

Here, we assume all components are interpreted by the

RLP as integer values, with the exception of the arbitrary

length byte arrays T

and T

(16) T

∈ N

256

∧ T

∈ N

256

∧ T

∈ N

256

∧

∈ N

256

∧ T

∈ N

∧ T

∈ N

256

∧

∈ N

256

∧ T

∈ B ∧ T

∈ B

where

(17) N

= {P : P ∈ N ∧ P < 2

}

The address hash

is slightly diﬀerent: 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

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 oﬀer bounties to

humans for being sent transactions to initiate their execution.

ETHEREUM: A SECURE DECENTRALISED GENERALISED TRANSACTION LEDGER BYZANTIUM VERSION 7aa0e4c - 2018-03-12 5

the RLP empty byte sequence and thus the member of

(18) T

∈

(

if T

6= ∅

otherwise

4.3.

The Block.

The block in Ethereum is the collec-

tion of relevant pieces of information (known as the block

header),

, together with information corresponding to

the comprised transactions,

, and a set of other block

headers

that are known to have a parent equal to the

present block’s parent’s parent (such blocks are known as

ommers

). The block header contains several pieces of

information:

parentHash:

The Keccak 256-bit hash of the parent

block’s header, in its entirety; formally H

ommersHash:

The Keccak 256-bit hash of the om-

mers list portion of this block; formally H

beneﬁciary:

The 160-bit address to which all fees

collected from the successful mining of this block

be transferred; formally H

stateRoot:

The Keccak 256-bit hash of the root

node of the state trie, after all transactions are

executed and ﬁnalisations applied; formally H

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 H

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 H

logsBloom:

The Bloom ﬁlter 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

diﬃculty:

A scalar value corresponding to the dif-

ﬁculty level of this block. This can be calculated

from the previous block’s diﬃculty level and the

timestamp; formally H

number:

A scalar value equal to the number of an-

cestor blocks. The genesis block has a number of

zero; formally H

gasLimit:

A scalar value equal to the current limit

of gas expenditure per block; formally H

gasUsed:

A scalar value equal to the total gas used

in transactions in this block; formally H

timestamp:

A scalar value equal to the reasonable

output of Unix’s time() at this block’s inception;

formally H

extraData:

An arbitrary byte array containing data

relevant to this block. This must be 32 bytes or

fewer; formally H

mixHash:

A 256-bit hash which, combined with the

nonce, proves that a suﬃcient amount of compu-

tation has been carried out on this block; formally

nonce:

A 64-bit value which, combined with the mix-

hash, proves that a suﬃcient amount of computa-

tion has been carried out on this block; formally

The other two components in the block are simply a list

of ommer block headers (of the same format as above),

and a series of the transactions,

. Formally, we can

refer to a block B:

(19) B ≡ (B

, B

)

4.3.1. Transaction Receipt. In order to encode information

about a transaction concerning which it may be useful

to form a zero-knowledge proof, or index and search, we

encode a receipt of each transaction containing certain

information from concerning its execution. Each receipt,

denoted

[

] for the

th transaction, is placed in an index-

keyed trie and the root recorded in the header as H

The transaction receipt,

, is a tuple of four items com-

prising the cumulative gas used in the block containing the

transaction receipt as of immediately after the transaction

has happened,

, the set of logs created through execu-

tion of the transaction,

and the Bloom ﬁlter composed

from information in those logs,

and the status code of

the transaction, R

(20) R ≡ (R

, R

)

The function

trivially prepares a transaction receipt

for being transformed into an RLP-serialised byte array:

(21) L

(R) ≡ (0 ∈ B

256

, R

)

where 0

∈ B

256

replaces the pre-transaction state root that

existed in previous versions of the protocol.

We assert that the status code R

is an integer.

(22) R

∈ N

We assert

, the cumulative gas used is a positive

integer and that the logs Bloom,

, is a hash of size 2048

bits (256 bytes):

(23) R

∈ N ∧ R

∈ B

256

The sequence

is a series of log entries, (

, O

, ...

A log entry,

, is a tuple of the logger’s address,

, a

series of 32-byte log topics,

and some number of bytes

of data, O

(24) O ≡ (O

, (O

, O

, ...), O

)

(25) O

∈ B

∧ ∀

t∈O

: t ∈ B

∧ O

∈ B

We deﬁne the Bloom ﬁlter function,

, to reduce a log

entry into a single 256-byte hash:

(26) M(O) ≡

t∈{O

}∪O



3:2048

(t)



where

3:2048

is a specialised Bloom ﬁlter that sets

three bits out of 2048, given an arbitrary byte sequence.

It does this through taking the low-order 11 bits of each of

the ﬁrst three pairs of bytes in a Keccak-256 hash of the

ommer is a gender-neutral term to mean “sibling of parent”; see

https://nonbinary.miraheze.org/wiki/Gender_neutral_language#Aunt.

2FUncle

11 bits = 2

2048

, and the low-order 11 bits is the modulo 2048 of the operand, which is in this case is “each of the ﬁrst three pairs of

bytes in a Keccak-256 hash of the byte sequence.”

剩余37页未读，继续阅读

评论收藏

内容反馈

miao129

粉丝: 0
资源: 1

以太坊黄皮书英文版

以太坊黄皮书原版

以太坊黄皮书中文版

以太坊技术黄皮书

以太坊黄皮书相关

以太坊黄皮书

以太坊黄皮书英文

以太坊黄皮书（中文）

以太坊：黄皮书1

以太坊黄皮书【英文版】1

以太坊-以太坊黄皮书.pdf

ethereumj:以太坊黄皮书的Java实现

ethereumj:已弃用！ 以太坊黄皮书的Java实现。 对于JSON-RPC和其他客户端功能，请查看以太坊和谐

初链黄皮书

最新版以太坊源码

深入浅出以太坊

初链TrueChain黄皮书.pdf

白皮书.rar

Nebulas星云指数黄皮书1

Ethereum.NET:C#以太坊客户端

YellowPaper1.02 Hash-Chinese

Ethereum Project Yellow Paper.pdf

AppCoins-white-paper:AppCoins是Aptoide App Store支持的，用于App Economy的基于区块链的协议，也是第一个为2亿用户提供服务的ICO

lovelace-library:Lovelace图书馆网站的任务是为新兴的Cardano生态系统提供精选的资源目录。 随着时间的流逝，网站将不可避免地发生变化，并随着

Ethereum内部结构剖析（工作原理）

ETH多链密钥碰撞工具V2.01

私钥狩猎私钥碰撞工具v1.07

最新资源

ethereumj:已弃用！以太坊黄皮书的Java实现。对于JSON-RPC和其他客户端功能，请查看以太坊和谐

lovelace-library:Lovelace图书馆网站的任务是为新兴的Cardano生态系统提供精选的资源目录。随着时间的流逝，网站将不可避免地发生变化，并随着