以太坊黄皮书：通用去中心化交易账本设计详解

需积分: 10 115 浏览量更新于2024-07-19 收藏 584KB PDF 举报

以太坊黄皮书英文版，由以太坊创始人Dr. Gavin Wood编撰，是深入理解以太坊协议及其原理的核心资料。这份文档详细阐述了区块链技术与加密交易相结合的理念，尤其以比特币的成功案例为佐证，展示了分布式、去中心化网络的实用价值。在这一框架下，每个项目被视为运行在单一的、共享状态的交易机器（transactional singleton machine）上，如比特币代表的应用。以太坊在此基础上进行了扩展，它设计了一个通用的平台，支持多个独立的、拥有自己状态和操作代码的“智能合约”（smart contracts）。这些智能合约通过消息传递机制相互交互，形成了一个高度灵活且可扩展的系统。这使得开发者能够构建各种复杂的应用和服务，如去中心化金融（DeFi）、非同质化代币（NFT）和去中心化应用（DApps）。黄皮书首先介绍了背景，指出随着互联网的普及，信息传输的成本大幅降低，而比特币等创新项目凭借共识机制的力量，展示了分布式账本技术的巨大潜力。以太坊的目标是提供一个通用的交易和计算平台，它不仅实现了基础的去中心化交易，还允许用户创建、执行和维护自我管理的代码，从而实现更加多样化的应用场景。然而，文档也探讨了实施过程中可能遇到的挑战，包括但不限于性能瓶颈、安全风险、监管合规问题以及如何处理不断增加的用户需求。以太坊团队致力于不断改进，例如通过分片技术（Sharding）来提高交易吞吐量，同时确保系统的稳定性和安全性。未来，黄皮书预见了以太坊可能面临的障碍和未来的演变方向，比如能源效率、隐私保护、跨链互操作性等问题。阅读这份黄皮书对于了解以太坊的底层技术、设计理念以及它在区块链领域的重要地位至关重要，无论是对开发者、投资者还是技术爱好者，都是深入研究以太坊生态不可或缺的参考资料。

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

is the timestamp (in Unix’s time()) of block

and

must fulﬁl the relation:

(48) H

> P (H)

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 diﬃculty level and thus

additional computation required, lengthening the likely

next period. Conversely, if the period is too large, the

diﬃculty, and expected time to the next block, is reduced.

The nonce, H

, must satisfy the relations:

(49) n 6

256

∧ m = H

with (n, m) = PoW(H

, H

, d).

Where

is the new block’s header

, but without the

nonce and mix-hash components,

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

), the expected time to ﬁnd

a solution is proportional to the diﬃculty, H

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 diﬃcult and,

over time, requires approximately the total compute power

of the trustworthy portion of the mining peers.

Thus we are able to deﬁne the block header validity

function V (H):

V (H) ≡ n 6

256

∧ m = H

∧(50)

= D(H) ∧

≤ H

∧

< P (H)



P (H)

1024



∧

> P (H)

−



P (H)

1024



∧

> 5000 ∧

> P (H)

∧

= P (H)

+ 1 ∧

k ≤ 32

where (n, m) = PoW(H

, H

, d)

Noting additionally that

extraData

must be at most

32 bytes.

5. 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 speciﬁed 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 speciﬁc 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

speciﬁed 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 beneﬁciary 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

oﬀer. Since there will be a (weighted) distribution of min-

imum acceptable gas prices, transactors will necessarily

have a trade-oﬀ to make between lowering the gas price

and maximising the chance that their transaction will be

mined in a timely manner.

6. Transaction Execution

The execution of a transaction is the most complex part

of the Ethereum protocol: it deﬁnes the state transition

function Υ. It is assumed that any transactions executed

ﬁrst 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 gas limit is no smaller than the intrinsic gas,

, used by the transaction; and

(5)

the sender account balance contains at least the

cost, v

, required in up-front payment.

Formally, we consider the function Υ, with

being a

transaction and σ the state:

(51) σ

= Υ(σ, T )

Thus

is the post-transactional state. We also deﬁne

to evaluate to the amount of gas used in the execution

of a transaction, Υ

to evaluate to the transaction’s accrued

log items and Υ

to evaluate to the status code resulting

from the transaction. These will be formally deﬁned later.

6.1.

Substate.

Throughout transaction execution, we ac-

crue certain information that is acted upon immediately

following the transaction. We call this transaction substate,

and represent it as A, which is a tuple:

(52) A ≡ (A

, A

)

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

The tuple contents include

, the self-destruct set: a

set of accounts that will be discarded following the trans-

action’s completion.

is the log series: this is a series of

archived and indexable ‘checkpoints’ in VM code execu-

tion that allow for contract-calls to be easily tracked by

onlookers external to the Ethereum world (such as decen-

tralised application front-ends).

is the set of touched

accounts, of which the empty ones are deleted at the end

of a transaction. Finally there 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

oﬀset the total execution costs.

We deﬁne the empty substate

to have no self-

destructs, no logs, no touched accounts and a zero refund

balance:

(53) A

≡ (∅, (), ∅, 0)

6.2.

Execution.

We deﬁne intrinsic gas

, the amount of

gas this transaction requires to be paid prior to execution,

as follows:

≡

i∈T

(

txdatazero

if i = 0

txdatanonzero

otherwise

(54)

(

txcreate

if T

= ∅

0 otherwise

(55)

+ G

transaction

(56)

where

, T

means the series of bytes of the trans-

action’s associated data and initialisation EVM-code, de-

pending on whether the transaction is for contract-creation

or message-call.

txcreate

is added if the transaction is

contract-creating, but not if a result of EVM-code.

fully deﬁned in Appendix G.

The up-front cost v

is calculated as:

(57) v

≡ T

+ T

The validity is determined as:

(58) S(T ) 6= ∅ ∧

σ[S(T )] 6= ∅ ∧

= σ[S(T )]

∧

6 T

∧

6 σ[S(T )]

∧

6 B

− `(B

)

Note the ﬁnal condition; the sum of the transaction’s

gas limit,

, and the gas utilised in this block prior, given

(

)

, must be no greater than the block’s

gasLimit

The execution of a valid transaction begins with an

irrevocable change made to the state: the nonce of the

account of the sender,

(

), is incremented by one and the

balance is reduced by part of the up-front cost,

. The

gas available for the proceeding computation,

, is deﬁned

− g

. The computation, whether contract creation

or a message call, results in an eventual state (which may

legally be equivalent to the current state), the change to

which is deterministic and never invalid: there can be no

invalid transactions from this point.

We deﬁne the checkpoint state σ

≡ σ except:(59)

[S(T )]

≡ σ[S(T )]

− T

(60)

[S(T )]

≡ σ[S(T )]

+ 1(61)

Evaluating

from

depends on the transaction

type; either contract creation or message call; we deﬁne

the tuple of post-execution provisional state

, remaining

gas g

, substate A and status code z:

(62)

(σ

, g

, A, z) ≡











(σ

, S(T ), T

, g,

, T

, 0, >) if T

= ∅

(σ

, S(T ), T

, T

g, T

, T

, 0, >) otherwise

where

is the amount of gas remaining after deducting

the basic amount required to pay for the existence of the

transaction:

(63) g ≡ T

− g

and

is the original transactor, which can diﬀer 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.

Note we use Θ

and Λ

to denote the fact that only the

ﬁrst four components of the functions’ values are taken;

the ﬁnal represents the message-call’s output value (a byte

array) and is unused in the context of transaction evalua-

tion.

After the message call or contract creation is processed,

the state is ﬁnalised by determining the amount to be re-

funded,

∗

from the remaining gas,

, plus some allowance

from the refund counter, to the sender at the original rate.

(64) g

∗

≡ g

+ min



− g

, A



The total refundable amount is the legitimately remain-

ing gas

, added to

, with the latter component being

capped up to a maximum of half (rounded down) of the

total amount used T

− g

The Ether for the gas is given to the miner, whose

address is speciﬁed as the beneﬁciary of the present block

. So we deﬁne the pre-ﬁnal state

∗

in terms of the

provisional state σ

∗

≡ σ

except(65)

∗

[S(T )]

≡ σ

[S(T )]

+ g

∗

(66)

∗

[m]

≡ σ

[m]

+ (T

− g

∗

(67)

m ≡ B

(68)

The ﬁnal state,

, is reached after deleting all accounts

that either appear in the self-destruct list or are touched

and empty:

≡ σ

∗

except(69)

∀i ∈ A

: σ

[i] = ∅(70)

∀i ∈ A

: σ

[i] = ∅ if DEAD(σ

∗

, i)(71)

And ﬁnally, we specify Υ

, the total gas used in this

transaction, Υ

, the logs created by this transaction and

, the status code of this transaction:

(σ, T ) ≡ T

− g

(72)

(σ, T ) ≡ A

(73)

(σ, T ) ≡ z(74)

These are used to help deﬁne the transaction receipt

and are also used later for state and nonce validation.

剩余37页未读，继续阅读

miao129

粉丝: 0
资源: 1

以太坊黄皮书：通用去中心化交易账本设计详解

以太坊黄皮书原版

以太坊黄皮书英文

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

以太坊黄皮书

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

以太坊黄皮书相关

以太坊黄皮书（中文）

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

以太坊黄皮书：通用去中心化交易账本与设计详解

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

最新资源

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