Ethereum通用交易账本：设计、挑战与未来

需积分: 5 18 浏览量更新于2024-07-16 收藏 562KB PDF 举报

《以太坊项目黄皮书》是Gavin Wood博士于2019年10月20日发布的，主要探讨了区块链技术与加密安全交易结合后在以太坊项目中的广泛应用。该文档深入研究了一种通用的交易模式，即在去中心化的、单一的计算机资源（称为“交易性单例机器”）上运行，其中每个资源拥有独特的状态和操作代码，并通过消息传递机制相互交互。以太坊（Ethereum）作为一种通用的分布式账本系统，其核心是将区块链技术提升到了一个新的层面。它不仅支持单一的交易处理，而是提供了一系列可扩展的资源，这些资源共享状态并能够通过标准化的消息传递架构进行协调。这种设计使得开发者可以构建各种不同的应用程序和服务，比如智能合约，这些合约有自己的状态和执行逻辑，同时又可以相互调用，形成一个高度灵活且去中心化的计算环境。黄皮书中详细分析了以太坊的设计理念和实施策略。首先，介绍了共识机制在信息传输中的关键作用，比如比特币的共识机制对于确保交易的可靠性和安全性。然后，讨论了以太坊如何通过诸如拜占庭容错（Byzantine Fault Tolerance, BFT）等技术来应对分布式系统中的复杂问题，以及它如何通过分片（Sharding）和状态通道（State Channels）等技术来提高交易吞吐量和降低网络拥堵。此外，黄皮书还探讨了以太坊面临的挑战和未来的发展方向。随着区块链技术的普及和应用需求的增长，以太坊需要不断优化性能，包括但不限于交易速度、能源效率和隐私保护。同时，随着DeFi（去中心化金融）和Web3.0概念的兴起，以太坊如何保持其在生态系统中的领先地位，与竞争者如Solana、Polkadot等区分开来，也成为了关注焦点。《以太坊项目黄皮书》不仅是一份技术文档，也是对区块链技术未来发展路径的一次深度洞察。通过阅读这份黄皮书，读者可以了解到以太坊的设计哲学、实施细节以及可能面临的机遇和挑战，这对于理解区块链技术和其在金融、智能合约和其他领域的潜在影响具有重要意义。

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

more time to develop proof-of-stake and preventing the

network from “freezing” up.

The canonical gas limit

of a block of header

must

fulﬁl the relation:

< P (H)



P (H)

1024



∧(47)

> P (H)

−



P (H)

1024



∧

> 5000

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

ETHEREUM: A SECURE DECENTRALISED GENERALISED TRANSACTION LEDGER BYZANTIUM VERSION 7e819ec - 2019-10-20 8

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 the accrued transac-

tion substate, or accrued substate for short, and represent

it as A, which is a tuple:

(52) A ≡ (A

, A

)

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 accrued 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

, accrued 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 refund counter has to be incremented for the accounts

that were self-destructed throughout its invocation.

(64) A

≡ A

i∈A

self destruct

Then the state is ﬁnalised by determining the amount

to be refunded,

∗

from the remaining gas,

, plus some

allowance from the refund counter, to the sender at the

original rate.

(65) 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

− g

. Therefore,

∗

is the total gas

that remains after the transaction has been executed.

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(66)

∗

[S(T )]

≡ σ

[S(T )]

+ g

∗

(67)

∗

[m]

≡ σ

[m]

+ (T

− g

∗

(68)

m ≡ B

(69)

剩余38页未读，继续阅读

Meta吴彦祖

粉丝: 796
资源: 6

Ethereum通用交易账本：设计、挑战与未来

nodemcu_yellow.zip

ethereumapis：一系列公共以太坊API

ethereum.pdf

ethereum_yellow_paper.pdf

ethereum go web3.pdf

Exploring the Ethereum Blockchain with etherchain.pdf

Ethereum C++ Client..zip

Apress.Beginning.Ethereum.Smart.Contracts.Programming.pdf

Claymore.s.dual.ethereum.v15.0.-.widows.zip

Mastering Ethereum-small.pdf

最新资源