Ethereum White Paper 以太坊白皮書（中英文對照，未完，待續）

A Next-Generation Smart Contract and Decentralized Application Platform

下一代智能合約和去中心化應用平台

Satoshi Nakamotos development of Bitcoin in 2009 has often been hailed as a radical development in money and currency, being the first example of a digital asset which simultaneously has no backing or "intrinsic value" and no centralized issuer or controller. However, another - arguably more important - part of the Bitcoin experiment is the underlying blockchain technology as a tool of distributed consensus, and attention is rapidly starting to shift to this other aspect of Bitcoin. Commonly cited alternative applications of blockchain technology include using on-blockchain digital assets to represent custom currencies and financial instruments ("colored coins"), the ownership of an underlying physical device ("smart property"), non-fungible assets such as domain names ("Namecoin"), as well as more complex applications involving having digital assets being directly controlled by a piece of code implementing arbitrary rules ("smart contracts") or even blockchain-based "decentralized autonomous organizations" (DAOs). What Ethereum intends to provide is a blockchain with a built-in fully fledged Turing-complete programming language that can be used to create "contracts" that can be used to encode arbitrary state transition functions, allowing users to create any of the systems described above, as well as many others that we have not yet imagined, simply by writing up the logic in a few lines of code.

2009年中本聰開發出比特幣，經常被人們譽為貨幣的激進式發展，因為比特幣是第一個同時沒有支持和「內在價值」，也沒有集中發行人或控制者的數字資產。然而，比特幣實驗的另一部分 —— 可以說是更加重要的部分——是作為分散式共識工具的底層區塊鏈技術，關注正在迅速轉移到比特幣的其他方面。通常被引用的區塊鏈技術的替代應用包括：使用區塊鏈數字資產來表示自定義貨幣和金融工具（「彩色硬幣」），基礎物理設備（「智能財產」）的所有權，不可替代資產（如域名幣「Namecoin」）以及更複雜的應用程序，其中涉及通過實施任意規則的一段代碼（「智能合約」）甚至基於區塊鏈的「分散式自治組織」（DAO）直接控制數字資產。以太坊計劃提供的區塊鏈是一種內置的完全成熟的圖靈完備的編程語言，可用於創建編碼任意狀態轉換功能的「合同」，允許用戶創建上述任何系統，還有其他許多我們還沒有想像到的，僅僅通過在幾行代碼中編寫邏輯就可以實現。

Table of Contents 目錄

• Introduction to Bitcoin and Existing Concepts 對比特幣及現有概念的介紹
• History 歷史
• Bitcoin As A State Transition System 作為一種狀態轉換系統的比特幣
• Mining 挖礦
• Merkle Trees 默克爾樹
• Alternative Blockchain Applications 其他的區塊鏈應用
• Scripting 腳本

• Ethereum 以太坊
• Ethereum Accounts 以太坊賬戶
• Messages and Transactions 消息和交易
• Messages 消息
• Ethereum State Transition Function 以太坊狀態轉換功能
• Code Execution 代碼運行
• Blockchain and Mining 區塊鏈和挖礦

• Applications 應用
• Token Systems 代幣系統
• Financial derivatives and Stable-Value Currencies 金融衍生品和價值穩定的貨幣
• Identity and Reputation Systems 身份與聲望系統
• Decentralized File Storage 去中心化文件存儲
• Decentralized Autonomous Organizations 去中心化自治組織
• Further Applications 將來的應用

• Miscellanea And Concerns 雜集及相關
• Modified GHOST Implementation 被修改的GHOST實現
• Fees 費用
• Computation And Turing-Completeness 計算及圖靈完備
• Currency And Issuance 貨幣及發行
• Mining Centralization 挖礦集中
• Scalability 可擴展性

• Conclusion 結論
• Notes and Further Reading 注釋及延伸閱讀
• Notes 注釋
• Further Reading 延伸閱讀

Created by gh-md-toc

gh-md-toc 創建

Introduction to Bitcoin and Existing Concepts

對比特幣及現有概念的介紹

History 歷史

The concept of decentralized digital currency, as well as alternative applications like property registries, has been around for decades. The anonymous e-cash protocols of the 1980s and the 1990s, mostly reliant on a cryptographic primitive known as Chaumian blinding, provided a currency with a high degree of privacy, but the protocols largely failed to gain traction because of their reliance on a centralized intermediary. In 1998, Wei Dais b-money became the first proposal to introduce the idea of creating money through solving computational puzzles as well as decentralized consensus, but the proposal was scant on details as to how decentralized consensus could actually be implemented. In 2005, Hal Finney introduced a concept of "reusable proofs of work", a system which uses ideas from b-money together with Adam Backs computationally difficult Hashcash puzzles to create a concept for a cryptocurrency, but once again fell short of the ideal by relying on trusted computing as a backend. In 2009, a decentralized currency was for the first time implemented in practice by Satoshi Nakamoto, combining established primitives for managing ownership through public key cryptography with a consensus algorithm for keeping track of who owns coins, known as "proof of work".

分散式數字貨幣的概念以及財產登記等替代應用已經存在數十年了。二十世紀八十年代和九十年代的匿名電子現金協議，主要依賴於一種被稱為Chaumian blinding的密碼原語，它提供了一種高度隱私的貨幣，但由於其過於依賴一種集中式中介而未能被廣泛接受。 1998年， Wei Dai 的B-money成為第一個提出通過解決數學難題和分散式共識來創造貨幣的提案，但是該提案沒有提供關於如何實現分散式共識的細節。 2005年，Hal Finney引入了一種「可重複使用的工作量證明」的概念，該系統使用B-money的想法和Adam Back計算困難的哈希現金難題創造了一個加密貨幣概念，但由於需要依賴可信的後端計算而再一次沒有實現。 2009年，中本聰首次實施了分散式貨幣，通過公鑰密碼體制來管理所有權與共識演算法追蹤誰擁有貨幣相結合，這一演算法稱為「工作l量證明」。

The mechanism behind proof of work was a breakthrough in the space because it simultaneously solved two problems. First, it provided a simple and moderately effective consensus algorithm, allowing nodes in the network to collectively agree on a set of canonical updates to the state of the Bitcoin ledger. Second, it provided a mechanism for allowing free entry into the consensus process, solving the political problem of deciding who gets to influence the consensus, while simultaneously preventing sybil attacks. It does this by substituting a formal barrier to participation, such as the requirement to be registered as a unique entity on a particular list, with an economic barrier - the weight of a single node in the consensus voting process is directly proportional to the computing power that the node brings. Since then, an alternative approach has been proposed called proof of stake, calculating the weight of a node as being proportional to its currency holdings and not computational resources; the discussion of the relative merits of the two approaches is beyond the scope of this paper but it should be noted that both approaches can be used to serve as the backbone of a cryptocurrency.

工作量證明背後的機制是這一領域的的突破，因為它同時解決了兩個問題。首先，它提供了一個簡單而適度有效的共識演算法，允許網路中的節點共同商定對比特幣賬本狀態的一組規範更新。其次，它提供了允許自由進入共識流程的機制，解決了由誰來影響共識的政治問題，同時防止sybil攻擊。它通過用經濟壁壘來取代正式的參與壁壘，正式的參與壁壘如要求在特定列表上登記為獨特的實體，而經濟障礙則是 - 共識投票過程中單個節點的權重與該節點帶來的計算能力成正比。此後，有人提出了一種替代方法，稱為股權證明，它計算一個節點的權重的方式是與其貨幣持有量成正比，而不是計算資源;對這兩種方法相對優點的討論超出了本文的範圍，但應該指出，這兩種方法都可以用作加密貨幣的核心支撐。

Bitcoin As A State Transition System

作為狀態轉換系統的比特幣

From a technical standpoint, the ledger of a cryptocurrency such as Bitcoin can be thought of as a state transition system, where there is a "state" consisting of the ownership status of all existing bitcoins and a "state transition function" that takes a state and a transaction and outputs a new state which is the result. In a standard banking system, for example, the state is a balance sheet, a transaction is a request to move $X from A to B, and the state transition function reduces the value in As account by $X and increases the value in Bs account by $X. If As account has less than $X in the first place, the state transition function returns an error. Hence, one can formally define:

從技術的角度來看，像比特幣這樣的加密貨幣賬本可以被認為是一種狀態轉換系統，其中存在一個由所有現有比特幣的所有權狀態組成的「狀態」和一個狀態轉換功能，它輸入一個狀態和一個交易，輸出一個新狀態作為結果。 例如，在標準的銀行系統中，狀態是資產負債表，交易是將$X從A移動到B的請求，狀態轉換功能將A的賬戶中的值減少$X，並增加B帳戶的值$X。 如果A的賬戶首先少於$X，則狀態轉換函數返回一個錯誤。 因此，人們可以正式定義：

APPLY(S,TX) -> S or ERROR

In the banking system defined above:

在銀行系統定義如上（下）

APPLY({ Alice: $50, Bob: $50 },"send $20 from Alice to Bob") = { Alice: $30, Bob: $70 }

But:

但是：

APPLY({ Alice: $50, Bob: $50 },"send $70 from Alice to Bob") = ERROR

The "state" in Bitcoin is the collection of all coins (technically, "unspent transaction outputs" or UTXO) that have been minted and not yet spent, with each UTXO having a denomination and an owner (defined by a 20-byte address which is essentially a cryptographic public key[1]). A transaction contains one or more inputs, with each input containing a reference to an existing UTXO and a cryptographic signature produced by the private key associated with the owners address, and one or more outputs, with each output containing a new UTXO to be added to the state.

比特幣中的「狀態」是已經產生和尚未用完的所有貨幣（技術上說是「未使用的交易輸出」或UTXO）的集合，每個UTXO有一個面額和一個擁有者（由20位元組地址定義） 本質上是一個密碼公鑰（譯者註：實際與密碼公鑰還是有很大差別的，嚴格說，也該是公鑰的兩次hash）[1]）。 交易包含一個或多個輸入，每個輸入包含對現有UTXO的引用和由與所有者地址關聯的私鑰生成的加密簽名，以及一個或多個輸出，每個輸出包含要添加新UTXO到狀態中去。

The state transition function APPLY(S,TX) -> S can be defined roughly as follows:

狀態轉換函數 APPLY(S,TX) -> S 可以粗略的定義如下：

1. For each input in TX: 對每個TX的輸入

• If the referenced UTXO is not in S, return an error.
• 如果引用的UTXO不在S裡面，返回錯誤
• If the provided signature does not match the of the UTXO, return an error.
• 如果提供的簽名不能被UTXO驗證相符，返回錯誤

1. If the sum of the denominations of all input UTXO is less than the sum of the denominations of all output UTXO, return an error. 如果所有輸入的UTXO的面額小於輸出的UTXO的面額，返回錯誤
2. Return S with all input UTXO removed and all output UTXO added. 返回S』，同時移除所有的輸入UTXO，增加輸出的UTXO。

The first half of the first step prevents transaction senders from spending coins that do not exist, the second half of the first step prevents transaction senders from spending other peoples coins, and the second step enforces conservation of value. In order to use this for payment, the protocol is as follows. Suppose Alice wants to send 11.7 BTC to Bob. First, Alice will look for a set of available UTXO that she owns that totals up to at least 11.7 BTC. Realistically, Alice will not be able to get exactly 11.7 BTC; say that the smallest she can get is 6+4+2=12. She then creates a transaction with those three inputs and two outputs. The first output will be 11.7 BTC with Bobs address as its owner, and the second output will be the remaining 0.3 BTC "change", with the owner being Alice herself.

第一步的前半部分阻止交易發送人花費不存在的比特幣，第一步的第二部分阻止交易送人花費其他人的比特幣，同時第二步執行價值守恆。 為了使用這個付款，協議如下。 假設Alice想要將11.7 BTC發送給Bob。 首先，Alice將尋找一套她擁有的可用UTXO，總計至少為11.7 BTC。 實際上，Alice將無法準確獲得11.7 BTC; 就說她能得到的接近的組合是6 + 4 + 2 = 12。 然後，她用這三個輸入和兩個輸出創建一個交易。 第一個輸出11.7 BTC到Bob所有的的地址，第二個輸出將是餘下的0.3 BTC「找零」，其擁有者是Alice本人。

Mining 挖礦

If we had access to a trustworthy centralized service, this system would be trivial to implement; it could simply be coded exactly as described, using a centralized servers hard drive to keep track of the state. However, with Bitcoin we are trying to build a decentralized currency system, so we will need to combine the state transaction system with a consensus system in order to ensure that everyone agrees on the order of transactions. Bitcoins decentralized consensus process requires nodes in the network to continuously attempt to produce packages of transactions called "blocks". The network is intended to produce roughly one block every ten minutes, with each block containing a timestamp, a nonce, a reference to (ie. hash of) the previous block and a list of all of the transactions that have taken place since the previous block. Over time, this creates a persistent, ever-growing, "blockchain" that constantly updates to represent the latest state of the Bitcoin ledger.

如果我們能夠獲得值得信賴的集中式服務，這個系統將很容易實施; 它可以完全按照描述進行編碼，使用中央伺服器的硬碟來跟蹤狀態。 但是，對於比特幣，我們正在試圖建立一個分散式的貨幣體系，所以我們需要將狀態交易體系與共識體系結合起來，以確保每個人都對交易順序達成一致。 比特幣的分散式共識流程要求網路中的節點不斷嘗試生成稱為「塊」的交易包。 網路每10分鐘產生一個塊，每個塊包含一個時間戳，一個隨機數，一個前一個塊的引用（即散列）和一個自上一次塊產生以來發生的所有交易的列表。 隨著時間的推移，這會創建一個持續、不斷增長的「區塊鏈」，它的不斷更新是為了代表最新的比特幣賬本的狀態。

The algorithm for checking if a block is valid, expressed in this paradigm, is as follows:

用來表達這種模式的，檢查一個區塊是否合法的演算法，如下所示：

1. Check if the previous block referenced by the block exists and is valid. 檢查被當期區塊引用的前一個區塊是否存在和合法。
2. Check that the timestamp of the block is greater than that of the previous block[2] and less than 2 hours into the future 檢查當前區塊的時間戳大於前一個區塊，同時小於未來2小時（譯註：應該就是按照當前區塊加入的時間計算是否小於2小時）
3. Check that the proof of work on the block is valid. 檢查當前區塊上的工作量證明是否正確
4. Let S[0] be the state at the end of the previous block. 讓S[0]作為前一個區塊的末尾的狀態。
5. Suppose TX is the blocks transaction list with n transactions. For all i in 0...n-1, set S[i+1] = APPLY(S[i],TX[i]) If any application returns an error, exit and return false. 假設 TX 是區塊中 n 個交易的交易列表，因為所有的 i 都在 0...n-1 中, 讓 S[i+1] = APPLY(S[i],TX[i]) ，如果程序返回錯誤，則退出並返回失敗。
6. Return true, and register S[n] as the state at the end of block. 如果返回正確，納悶註冊 S[n] 作為當前區塊末尾的狀態。

Essentially, each transaction in the block must provide a valid state transition from what was the canonical state before the transaction was executed to some new state. Note that the state is not encoded in the block in any way; it is purely an abstraction to be remembered by the validating node and can only be (securely) computed for any block by starting from the genesis state and sequentially applying every transaction in every block. Additionally, note that the order in which the miner includes transactions into the block matters; if there are two transactions A and B in a block such that B spends a UTXO created by A, then the block will be valid if A comes before B but not otherwise.

本質上，塊中的每個交易必須提供從事務執行前的規範狀態到新狀態的有效狀態轉換。 請注意，狀態不以任何方式編碼在塊中; 狀態僅僅是一個被驗證節點記住的抽象概念，任何區塊的狀態，都可以從創始狀態開始，按次序加入每個塊中的每一筆交易後，被（安全地）計算出來。 此外，請注意礦工處理將交易包含進區塊的順序; 如果塊中有兩個交易A和B，B花費由A創建的UTXO，如果A在B之前，則該塊將是有效的，否則不是。

The one validity condition present in the above list that is not found in other systems is the requirement for "proof of work". The precise condition is that the double-SHA256 hash of every block, treated as a 256-bit number, must be less than a dynamically adjusted target, which as of the time of this writing is approximately 2187. The purpose of this is to make block creation computationally "hard", thereby preventing sybil attackers from remaking the entire blockchain in their favor. Because SHA256 is designed to be a completely unpredictable pseudorandom function, the only way to create a valid block is simply trial and error, repeatedly incrementing the nonce and seeing if the new hash matches.

在上述列表中出現的，在其他系統沒有發現的有效性條件，是對「工作證明」的要求。 確切的條件是，每個區塊的雙-SHA256散列值（被視為256位數）必須小於一個動態調整的目標，截至本文寫作時約為2^187。這樣做的目的是為了讓創建區塊變得「困難」，從而防止sybil攻擊者為了私利而重建整個區塊鏈。 因為SHA256被設計為一個完全不可預知的偽隨機函數，所以創建一個有效區塊的唯一方法是簡單的反覆嘗試，不斷增加隨機數的值並查看新的哈希值是否匹配。

At the current target of ~2187, the network must make an average of ~269 tries before a valid block is found; in general, the target is recalibrated by the network every 2016 blocks so that on average a new block is produced by some node in the network every ten minutes. In order to compensate miners for this computational work, the miner of every block is entitled to include a transaction giving themselves 12.5 BTC out of nowhere. Additionally, if any transaction has a higher total denomination in its inputs than in its outputs, the difference also goes to the miner as a "transaction fee". Incidentally, this is also the only mechanism by which BTC are issued; the genesis state contained no coins at all.

如果當前的目標值是在2^187之下，網路發現有效塊之前必須平均進行2^69次嘗試; 一般而言，網路每產生2016個區塊後會重新校準目標值，以保證平均每10分鐘由網路中的某個節點產生一個新區塊。 為了補償礦工們的計算工作，每個發現區塊的礦工有權包含一筆給自己12.5比特幣（不要問哪裡來的）的交易進區塊（譯註：這就是所謂的每個區塊裡面的第一個交易，coinbase交易，最開始獎勵是25個比特幣，每4年減半，以太坊白皮書推出時已經第一次減半）。 此外，如果任何交易在其輸入總額高於其輸出，則差額也作為「交易費」交給礦工。 順便說一句，這也是BTC發行的唯一機制; 創始狀態根本沒有比特幣。

In order to better understand the purpose of mining, let us examine what happens in the event of a malicious attacker. Since Bitcoins underlying cryptography is known to be secure, the attacker will target the one part of the Bitcoin system that is not protected by cryptography directly: the order of transactions. The attackers strategy is simple:

為了更好地理解挖礦的的目的，讓我們來看看在發生惡意攻擊時會發生什麼。 由於比特幣的基礎密碼學是安全的，因此攻擊者將瞄準比特幣系統中不受密碼學直接保護的部分：交易順序。 攻擊者的策略很簡單：

1. Send 100 BTC to a merchant in exchange for some product (preferably a rapid-delivery digital good) 發送比特幣給一個商戶，交互一些產品（更青睞快速發貨的數字產品）
2. Wait for the delivery of the product 等待商品發貨
3. Produce another transaction sending the same 100 BTC to himself 創建另一個交易，將剛才的100比特幣發送給自己
4. Try to convince the network that his transaction to himself was the one that came first. 試圖讓網路相信，那筆發送給自己的交易是第一個交易。

Once step (1) has taken place, after a few minutes some miner will include the transaction in a block, say block number 270000. After about one hour, five more blocks will have been added to the chain after that block, with each of those blocks indirectly pointing to the transaction and thus "confirming" it. At this point, the merchant will accept the payment as finalized and deliver the product; since we are assuming this is a digital good, delivery is instant. Now, the attacker creates another transaction sending the 100 BTC to himself. If the attacker simply releases it into the wild, the transaction will not be processed; miners will attempt to run APPLY(S,TX) and notice that TXconsumes a UTXO which is no longer in the state. So instead, the attacker creates a "fork" of the blockchain, starting by mining another version of block 270000 pointing to the same block 269999 as a parent but with the new transaction in place of the old one. Because the block data is different, this requires redoing the proof of work. Furthermore, the attackers new version of block 270000 has a different hash, so the original blocks 270001 to 270005 do not "point" to it; thus, the original chain and the attackers new chain are completely separate. The rule is that in a fork the longest blockchain is taken to be the truth, and so legitimate miners will work on the 270005 chain while the attacker alone is working on the 270000 chain. In order for the attacker to make his blockchain the longest, he would need to have more computational power than the rest of the network combined in order to catch up (hence, "51% attack").

一旦步驟（1）發生，幾分鐘後某些礦工將把交易包括在一個區塊中，例如區塊編號270000。大約一個小時後，在該區塊之後將再添加五個區塊，每個區塊都間接地指向那筆交易並如此進行「確認」。此時，商家將接受付款並最終交付產品;因為我們假設這是一個數字商品，交貨是即時的。現在，攻擊者創建了另一個發送100比特幣的交易。如果攻擊者只是簡單地將交易釋放到外面，這個交易將不會被處理;礦工將嘗試運行APPLY（S，TX），並注意到TX會消耗一個不在狀態的UTXO。因此，攻擊者創建區塊鏈的「分支」，首先挖掘另一個版本的區塊270000，指向與父區塊相同的區塊269999，但其中新的交易取代舊的交易。由於區塊數據不同，這需要重做工作證明。此外，攻擊者的新版區塊270000具有不同的散列，因此原始塊270001至270005不會「指向」它;因此，原始鏈和攻擊者的新鏈完全分開。規則是，在一個分支中，最長的區塊鏈被認為是事實，所以合法的礦工將在270005鏈上工作，而攻擊者只能在270000鏈上工作。攻擊者為了使自己的區塊鏈最長，他需要比網路其餘部分具有更多的計算能力才能趕上（因此，也叫「51％攻擊」）。

Merkle Trees 默克爾樹

Left: it suffices to present only a small number of nodes in a Merkle tree to give a proof of the validity of a branch.

左邊：在默克爾樹中，僅用少量節點就足以證明一個分支的有效性

Right: any attempt to change any part of the Merkle tree will eventually lead to an inconsistency somewhere up the chain.

右邊：任何試圖對默克爾樹任何部分的改變，都將導致鏈上某處的不一致。

An important scalability feature of Bitcoin is that the block is stored in a multi-level data structure. The "hash" of a block is actually only the hash of the block header, a roughly 200-byte piece of data that contains the timestamp, nonce, previous block hash and the root hash of a data structure called the Merkle tree storing all transactions in the block. A Merkle tree is a type of binary tree, composed of a set of nodes with a large number of leaf nodes at the bottom of the tree containing the underlying data, a set of intermediate nodes where each node is the hash of its two children, and finally a single root node, also formed from the hash of its two children, representing the "top" of the tree. The purpose of the Merkle tree is to allow the data in a block to be delivered piecemeal: a node can download only the header of a block from one source, the small part of the tree relevant to them from another source, and still be assured that all of the data is correct. The reason why this works is that hashes propagate upward: if a malicious user attempts to swap in a fake transaction into the bottom of a Merkle tree, this change will cause a change in the node above, and then a change in the node above that, finally changing the root of the tree and therefore the hash of the block, causing the protocol to register it as a completely different block (almost certainly with an invalid proof of work).

比特幣的一個重要的可擴展性特徵是，區塊存儲在多層級數據結構中。區塊的「散列」實際上只是塊頭的散列，一個大致200位元組的數據塊，包含時間戳，隨機數，先前區塊散列和稱為Merkle樹的數據結構的根散列，這個Merkle樹中存儲了所有交易。 Merkle樹是一種二叉樹，由一組節點組成，其中包含底層數據的樹的底部有大量的葉節點，一組中間節點，其中每個節點是其兩個子節點的散列，最後是一個單一的根節點，也是由它的兩個子節點的散列形成的，代表樹的「頂部」。 Merkle樹的目的是允許塊中的數據零散傳遞：一個節點可以只從一個源下載塊的頭部，從另一個源下載與此相關的樹的小部分，並且依然可以確信所有數據都是正確的。之所以這樣做，是因為哈希會向上傳播：如果惡意用戶試圖將虛假交易替換到Merkle樹的底部，則此更改將導致其上的節點發生更改，然後改變的是這個節點上面的節點，最後改變樹的根，因此改變區塊的散列值，導致協議將它標示為完全不同的塊（幾乎肯定帶有無效的工作量證明）。

The Merkle tree protocol is arguably essential to long-term sustainability. A "full node" in the Bitcoin network, one that stores and processes the entirety of every block, takes up about 15 GB of disk space in the Bitcoin network as of April 2014, and is growing by over a gigabyte per month. Currently, this is viable for some desktop computers and not phones, and later on in the future only businesses and hobbyists will be able to participate. A protocol known as "simplified payment verification" (SPV) allows for another class of nodes to exist, called "light nodes", which download the block headers, verify the proof of work on the block headers, and then download only the "branches" associated with transactions that are relevant to them. This allows light nodes to determine with a strong guarantee of security what the status of any Bitcoin transaction, and their current balance, is while downloading only a very small portion of the entire blockchain.

Merkle樹協議，對於長期可持續性來說可能是必不可少的。 比特幣網路中的一個「完整節點」，一個用於存儲和處理所有區塊整體的網路，截至2014年4月，佔用大約15 GB的磁碟空間，並且每月增長超過千兆位元組。 目前，這對於一些台式計算機是可行的，但是手機不行，並且以後只有企業和愛好者才能參與。 被稱為「簡化支付驗證」（SPV）的協議允許存在另一類節點，稱為「輕節點」，其下載區塊頭部，驗證區塊頭部的工作量證明，然後僅下載與他們的交易相關聯的「分支」。 這使得輕型節點只需下載整個區塊鏈很小的部分，就可以安全的確定任一比特幣交易狀態和他們的賬戶餘額安全。

Alternative Blockchain Applications 其他區塊鏈應用

The idea of taking the underlying blockchain idea and applying it to other concepts also has a long history. In 2005, Nick Szabo came out with the concept of "secure property titles with owner authority", a document describing how "new advances in replicated database technology" will allow for a blockchain-based system for storing a registry of who owns what land, creating an elaborate framework including concepts such as homesteading, adverse possession and Georgian land tax. However, there was unfortunately no effective replicated database system available at the time, and so the protocol was never implemented in practice. After 2009, however, once Bitcoins decentralized consensus was developed a number of alternative applications rapidly began to emerge.

將底層區塊鏈想法應用於其他領域的想法早就出現了。 2005年，Nick Szabo提出了「標示所有權的安全產權」概念，一個文件描述了「複製資料庫技術的新進展」將會如何允許基於區塊鏈的系統，用來存儲誰擁有哪塊土地的註冊， 並創建一個精心設計的框架，包括諸如家園式，逆權管理和喬治亞地稅等概念。 但是，不幸的是，當時沒有有效的複製資料庫系統，因此該協議在實踐中從未得到實施。 然而，2009年之後，當比特幣的分散式共識被開發出來後，很多其他的應用迅速湧現。

• Namecoin - created in 2010, Namecoin is best described as a decentralized name registration database. In decentralized protocols like Tor, Bitcoin and BitMessage, there needs to be some way of identifying accounts so that other people can interact with them, but in all existing solutions the only kind of identifier available is a pseudorandom hash like 1LW79wp5ZBqaHW1jL5TCiBCrhQYtHagUWy. Ideally, one would like to be able to have an account with a name like "george". However, the problem is that if one person can create an account named "george" then someone else can use the same process to register "george" for themselves as well and impersonate them. The only solution is a first-to-file paradigm, where the first registerer succeeds and the second fails - a problem perfectly suited for the Bitcoin consensus protocol. Namecoin is the oldest, and most successful, implementation of a name registration system using such an idea.
• Namecoin - 2010年創建，Namecoin最好描述為分散式名稱註冊資料庫。 在像Tor，Bitcoin和BitMessage這樣的分散式協議中，需要有一些識別帳戶的方法，以便其他人可以與它們交互，但是在所有現有的解決方案中，唯一可用的標識符是偽隨機哈希，如1LW79wp5ZBqaHW1jL5TCiBCrhQYtHagUWy。 理想情況下，人們希望能夠擁有像「喬治」這樣的名字。 但問題是，如果一個人可以創建一個名為「喬治」的賬戶，那麼其他人可以使用相同的過程為自己註冊「喬治」，並假冒它們。 唯一的解決方案是採用first-to-file模式，第一個註冊成功，第二個失敗 - 這是一個完全適合比特幣共識協議的問題。 使用這種想法實現名稱註冊系統，Namecoin是最早、也是最成功的一個。
• Colored coins - the purpose of colored coins is to serve as a protocol to allow people to create their own digital currencies - or, in the important trivial case of a currency with one unit, digital tokens, on the Bitcoin blockchain. In the colored coins protocol, one "issues" a new currency by publicly assigning a color to a specific Bitcoin UTXO, and the protocol recursively defines the color of other UTXO to be the same as the color of the inputs that the transaction creating them spent (some special rules apply in the case of mixed-color inputs). This allows users to maintain wallets containing only UTXO of a specific color and send them around much like regular bitcoins, backtracking through the blockchain to determine the color of any UTXO that they receive.
• 彩色幣（Colored coins） - Colored coins的目的是作為一種協議，允許人們在比特幣區塊鏈上創建自己的數字貨幣 - 或者，一個重要瑣碎情況下的貨幣單位，數字代幣等。 在彩色幣協議中，通過公開地為特定的比特幣UTXO分配一種顏色來「發布」新幣種，並且該協議遞歸地將其他UTXO的顏色定義為，與創建該交易花費的輸入（UTXO）的顏色相同 （一些特殊的規則適用於混合顏色輸入的情況）。 這允許用戶維護僅包含特定顏色的UTXO的錢包，並像常規比特幣一樣使用它們，通過區塊鏈回溯可以確定它們接收的任何UTXO的顏色。
• Metacoins - the idea behind a metacoin is to have a protocol that lives on top of Bitcoin, using Bitcoin transactions to store metacoin transactions but having a different state transition function, APPLY. Because the metacoin protocol cannot prevent invalid metacoin transactions from appearing in the Bitcoin blockchain, a rule is added that if APPLY(S,TX)returns an error, the protocol defaults to APPLY(S,TX) = S. This provides an easy mechanism for creating an arbitrary cryptocurrency protocol, potentially with advanced features that cannot be implemented inside of Bitcoin itself, but with a very low development cost since the complexities of mining and networking are already handled by the Bitcoin protocol. Metacoins have been used to implement some classes of financial contracts, name registration and decentralized exchange.
• 元幣（Metacoins） - metacoin背後的想法是擁有一個生活在比特幣之上的協議，使用比特幣交易來存儲metacoin交易，但具有不同的狀態轉換函數 APPLY。 由於元幣協議不能防止無效的元幣交易出現在比特幣區塊鏈中，所以添加一條規則，即如果APPLY（S，TX）返回錯誤，則協議默認為APPLY（S，TX）= S。 由於挖礦和網路的複雜性已經由比特幣協議處理，所以創建任意加密貨幣協議的機制非常簡單，可能無法在比特幣內部實現高級功能，但其開發成本非常低。 Metacoins已被用於實施一些類別的金融合同，名稱註冊和分散式交換。

Thus, in general, there are two approaches toward building a consensus protocol: building an independent network, and building a protocol on top of Bitcoin. The former approach, while reasonably successful in the case of applications like Namecoin, is difficult to implement; each individual implementation needs to bootstrap an independent blockchain, as well as building and testing all of the necessary state transition and networking code. Additionally, we predict that the set of applications for decentralized consensus technology will follow a power law distribution where the vast majority of applications would be too small to warrant their own blockchain, and we note that there exist large classes of decentralized applications, particularly decentralized autonomous organizations, that need to interact with each other.

因此，總的來說，有兩種方法可以建立一個共識協議：建立一個獨立的網路，或者在比特幣之上構建一個協議。 前一種方法雖然在像Namecoin這樣的應用程序中相當成功，但很難實現，因為每個單獨的應用都需要創建一個獨立的區塊鏈，以及構建和測試所有必要的狀態轉換和網路代碼。 此外，我們預測分散式共識技術的應用程序集將遵循冪律分布，絕大多數應用太小而不能保證自己區塊鏈的安全，並且我們注意到存在大量的分散式應用程序，特別是分散式自治組織，需要相互交流。

The Bitcoin-based approach, on the other hand, has the flaw that it does not inherit the simplified payment verification features of Bitcoin. SPV works for Bitcoin because it can use blockchain depth as a proxy for validity; at some point, once the ancestors of a transaction go far enough back, it is safe to say that they were legitimately part of the state. Blockchain-based meta-protocols, on the other hand, cannot force the blockchain not to include transactions that are not valid within the context of their own protocols. Hence, a fully secure SPV meta-protocol implementation would need to backward scan all the way to the beginning of the Bitcoin blockchain to determine whether or not certain transactions are valid. Currently, all "light" implementations of Bitcoin-based meta-protocols rely on a trusted server to provide the data, arguably a highly suboptimal result especially when one of the primary purposes of a cryptocurrency is to eliminate the need for trust.

另一方面，基於比特幣的方法存在缺陷，因為它繼承不了比特幣的簡化支付驗證（SPV）功能。 SPV適用於比特幣，因為它可以使用區塊鏈深度作為有效性的代理; 在某種程度上，一旦交易的祖先足夠回歸，可以肯定地說它們是狀態的合法組成部分。 另一方面，基於區塊鏈的元協議，不能強制比特幣區塊鏈不要包含元協議環境中無效的交易。 因此，完全安全的SPV元協議實現需要一直向後掃描到比特幣區塊鏈的開頭，以確定某些交易是否有效。 目前，基於比特幣的元協議的所有「輕量級」實現依賴於可信伺服器來提供數據，可以說這是一個非常不妙的結果，尤其是因為加密貨幣的主要目的之一，就是要消除對信任的需求。

Scripting 腳本

Even without any extensions, the Bitcoin protocol actually does facilitate a weak version of a concept of "smart contracts". UTXO in Bitcoin can be owned not just by a public key, but also by a more complicated script expressed in a simple stack-based programming language. In this paradigm, a transaction spending that UTXO must provide data that satisfies the script. Indeed, even the basic public key ownership mechanism is implemented via a script: the script takes an elliptic curve signature as input, verifies it against the transaction and the address that owns the UTXO, and returns 1 if the verification is successful and 0 otherwise. Other, more complicated, scripts exist for various additional use cases. For example, one can construct a script that requires signatures from two out of a given three private keys to validate ("multisig"), a setup useful for corporate accounts, secure savings accounts and some merchant escrow situations. Scripts can also be used to pay bounties for solutions to computational problems, and one can even construct a script that says something like "this Bitcoin UTXO is yours if you can provide an SPV proof that you sent a Dogecoin transaction of this denomination to me", essentially allowing decentralized cross-cryptocurrency exchange.

即使沒有任何擴展，比特幣協議實際上也實現了「智能合約」概念的弱化版本。比特幣中的UTXO不僅可以被公鑰擁有，還可以被更複雜的腳本來擁有，這一腳本以簡單的基於堆棧的編程語言來表達。在這個模式中，花費UTXO的交易必須提供滿足腳本的數據。事實上，即使是基本的公鑰所有權機制也是通過腳本實現的：腳本以橢圓曲線簽名為輸入，根據交易和擁有UTXO的地址驗證它，如果驗證成功則返回1，否則返回0。其他更複雜的腳本存在於各種其他用例中。例如，可以構建一個腳本，該腳本需要來自給定三個私鑰中的兩個的簽名才能驗證（多重簽名「multisig」），這一設置對於公司帳戶，安全儲蓄帳戶和一些商業託管情況很有用。腳本也可以用來支付解決計算問題的獎勵，甚至你可以構建這樣的腳本：「如果您可以提供SPV證據證明您已向此發送此幣值的狗幣（Dogecoin），則此比特幣UTXO即屬於您」 ，本質上，比特幣系統允許分散式的跨加密貨幣間的兌換。

However, the scripting language as implemented in Bitcoin has several important limitations:

然而，比特幣實現的腳本語言存在幾處重要的限制：

• Lack of Turing-completeness - that is to say, while there is a large subset of computation that the Bitcoin scripting language supports, it does not nearly support everything. The main category that is missing is loops. This is done to avoid infinite loops during transaction verification; theoretically it is a surmountable obstacle for script programmers, since any loop can be simulated by simply repeating the underlying code many times with an if statement, but it does lead to scripts that are very space-inefficient. For example, implementing an alternative elliptic curve signature algorithm would likely require 256 repeated multiplication rounds all individually included in the code.
• 缺乏圖靈完備性 - 也就是說，儘管比特幣腳本語言支持大量計算，但它並不是支持所有計算。 缺少的主要類別是循環（loops）。 這樣做是為了避免交易驗證期間的無限循環; 從理論上說，這是一個腳本程序員可以克服的障礙，因為任何循環都可以簡單地用 if 語句多次重複底層代碼來模擬，但它確實會導致腳本在空間利用上的低效。 例如，實施替代橢圓曲線簽名演算法可能需要256次重複的乘法循環，每一次循環都需單獨包含在代碼中。
• Value-blindness - there is no way for a UTXO script to provide fine-grained control over the amount that can be withdrawn. For example, one powerful use case of an oracle contract would be a hedging contract, where A and B put in $1000 worth of BTC and after 30 days the script sends $1000 worth of BTC to A and the rest to B. This would require an oracle to determine the value of 1 BTC in USD, but even then it is a massive improvement in terms of trust and infrastructure requirement over the fully centralized solutions that are available now. However, because UTXO are all-or-nothing, the only way to achieve this is through the very inefficient hack of having many UTXO of varying denominations (eg. one UTXO of 2k for every k up to 30) and having O pick which UTXO to send to A and which to B.
• 價值盲 - UTXO腳本無法對可撤銷的金額進行精細化控制。 例如，預言合同的一個強大的用例就是套期保值合同，A和B投入1000美元的BTC，30天後腳本向A發送價值1000美元的BTC，其餘的則發給B。 這就需要預言確定1 BTC價值多少美元，但即使如此，它對信任和基礎設施要求方面的重大改進已經超過了現在可用的完全集中式解決方案。 然而，由於UTXO全是或全無，實現這一目標的唯一方法，是通過非常低效地分解許多不同面額的UTXO（例如，一個每達到30 的2k的UTXO），並選擇哪個UTXO 發送給A和哪個給B。
• Lack of state - UTXO can either be spent or unspent; there is no opportunity for multi-stage contracts or scripts which keep any other internal state beyond that. This makes it hard to make multi-stage options contracts, decentralized exchange offers or two-stage cryptographic commitment protocols (necessary for secure computational bounties). It also means that UTXO can only be used to build simple, one-off contracts and not more complex "stateful" contracts such as decentralized organizations, and makes meta-protocols difficult to implement. Binary state combined with value-blindness also mean that another important application, withdrawal limits, is impossible.
• 缺乏狀態 - UTXO只有用完和沒有用兩種狀態; 多階段合同或腳本沒有機會保持任何其他內部狀態。 這使得很難制定多階段期權合約，分散式交易提議或兩階段密碼承諾協議（安全計算獎勵所必需的）。 這也意味著UTXO只能用於構建簡單的一次性合同，而不能構建像分散式組織那樣更複雜的「有狀態」合同，並且使元協議難以實施。 二元狀態與價值盲相結合還意味著另一個重要的應用——取款限制——不可能實現。
• Blockchain-blindness - UTXO are blind to blockchain data such as the nonce, the timestamp and previous block hash. This severely limits applications in gambling, and several other categories, by depriving the scripting language of a potentially valuable source of randomness.
• 區塊鏈盲 - UTXO對區塊鏈數據（例如隨機數，時間戳和前一個區塊哈希）視而不見。 這剝奪了腳本語言來源於隨機性的潛在價值，嚴重限制了賭博和其他幾個類別的應用。

Thus, we see three approaches to building advanced applications on top of cryptocurrency: building a new blockchain, using scripting on top of Bitcoin, and building a meta-protocol on top of Bitcoin. Building a new blockchain allows for unlimited freedom in building a feature set, but at the cost of development time, bootstrapping effort and security. Using scripting is easy to implement and standardize, but is very limited in its capabilities, and meta-protocols, while easy, suffer from faults in scalability. With Ethereum, we intend to build an alternative framework that provides even larger gains in ease of development as well as even stronger light client properties, while at the same time allowing applications to share an economic environment and blockchain security.

綜上，我們了解到在加密貨幣之上構建高級應用程序的三種方法：構建新的區塊鏈，在比特幣之上使用腳本，在比特幣之上構建元協議。 構建新的區塊鏈，可以在構建功能集時實現無限制的自由，但成本是開發時間，培育努力和安全保障。 使用腳本很容易實現和標準化，但其功能非常有限，而元協議雖然很容易，但在可伸縮性方面遇到問題。 通過以太坊，我們打算構建一個替代框架，在易於開發的同時提供更大的收益，以及更強大的輕客戶端屬性，同時允許應用程序共享經濟環境和區塊鏈安全。

Ethereum 以太坊

The intent of Ethereum is to create an alternative protocol for building decentralized applications, providing a different set of tradeoffs that we believe will be very useful for a large class of decentralized applications, with particular emphasis on situations where rapid development time, security for small and rarely used applications, and the ability of different applications to very efficiently interact, are important. Ethereum does this by building what is essentially the ultimate abstract foundational layer: a blockchain with a built-in Turing-complete programming language, allowing anyone to write smart contracts and decentralized applications where they can create their own arbitrary rules for ownership, transaction formats and state transition functions. A bare-bones version of Namecoin can be written in two lines of code, and other protocols like currencies and reputation systems can be built in under twenty. Smart contracts, cryptographic "boxes" that contain value and only unlock it if certain conditions are met, can also be built on top of the platform, with vastly more power than that offered by Bitcoin scripting because of the added powers of Turing-completeness, value-awareness, blockchain-awareness and state.

以太坊的目的是為構建分散式應用程序創建一個替代協議，提供一套不同的折衷方案，我們認為這對於大量分散式應用程序非常有用，特彆強調快速開發時間，小型很少使用的應用程序，以及不同應用程序的高效互動能力都很重要。以太坊通過構建本質上最終的抽象基礎層來實現這一點：一種內置圖靈完整編程語言的區塊鏈，允許任何人編寫智能合約和分散式應用程序，在這些應用程序中他們可以為所有權，交易格式和狀態轉換函數制定自己的規則。 Namecoin的一個簡單版本可以用兩行代碼編寫，其他協議，如貨幣和信譽系統可以在20行以內建立。因為擁有比比特幣腳本所提供的功能強大得多的圖靈完備性，價值知曉，區塊鏈知曉和狀態，所以智能合約，包含價值並且只有在滿足特定條件時才解鎖的密碼「箱子」，都可以建立在平台之上。

Ethereum Accounts 以太坊賬戶

In Ethereum, the state is made up of objects called "accounts", with each account having a 20-byte address and state transitions being direct transfers of value and information between accounts. An Ethereum account contains four fields:

在以太坊中，狀態由稱為「帳戶」的對象組成，每個帳戶都有一個20位元組的地址，狀態轉換是賬戶之間的價值和信息的直接轉移。 以太坊賬戶包含四個欄位：

• The nonce, a counter used to make sure each transaction can only be processed once 隨機數，用於確定每筆交易只能被處理一次的計算器
• The accounts current ether balance 賬戶當前的以太幣餘額
• The accounts contract code, if present 賬戶的合約代碼，如果有的話
• The accounts storage (empty by default) 賬戶的存儲（默認為空）

"Ether" is the main internal crypto-fuel of Ethereum, and is used to pay transaction fees. In general, there are two types of accounts: externally owned accounts, controlled by private keys, and contract accounts, controlled by their contract code. An externally owned account has no code, and one can send messages from an externally owned account by creating and signing a transaction; in a contract account, every time the contract account receives a message its code activates, allowing it to read and write to internal storage and send other messages or create contracts in turn.

「以太」是以太坊的主要內部加密燃料，用於支付交易費用。 一般來說，有兩種類型的賬戶：外部所有的賬戶，由私鑰控制；合同賬戶由合同代碼控制。 外部所有的賬戶沒有代碼，人們從外部所有賬戶發送消息，以創建和簽署交易; 在合同賬戶中，合約賬戶每次收到消息後，代碼激活，將允許對內部存儲進行讀寫和發送其他消息或者依次創建合約。

Note that "contracts" in Ethereum should not be seen as something that should be "fulfilled" or "complied with"; rather, they are more like "autonomous agents" that live inside of the Ethereum execution environment, always executing a specific piece of code when "poked" by a message or transaction, and having direct control over their own ether balance and their own key/value store to keep track of persistent variables.

請注意，以太坊中的「合約」不應被視為應該被「履行」或「遵守」的事物; 相反，他們更像是居住在以太坊執行環境中的「自主代理人」，當被消息或交易「捅一下」時，總是執行特定的代碼段，並直接控制自己的以太餘額和自己的密鑰/ 值存儲，保持對持久變數的跟蹤。

Messages and Transactions 消息與交易

The term "transaction" is used in Ethereum to refer to the signed data package that stores a message to be sent from an externally owned account. Transactions contain:

「交易」術語在以太坊中是指被外部所有賬戶發送的存有消息的經過簽署的數據包。交易包含：

• The recipient of the message 消息接受人
• A signature identifying the sender 能證明發送者身份的簽名
• The amount of ether to transfer from the sender to the recipient 一定數量的從發送者轉移至接受者的以太幣
• An optional data field 一個可選的數據欄位
• A STARTGAS value, representing the maximum number of computational steps the transaction execution is allowed to take STARTGAS值，代表交易被執行時可以運行的最大計算步驟數
• A GASPRICE value, representing the fee the sender pays per computational step GASPRICE值，代表發送者為每個計算步驟支付的費用。

The first three are standard fields expected in any cryptocurrency. The data field has no function by default, but the virtual machine has an opcode using which a contract can access the data; as an example use case, if a contract is functioning as an on-blockchain domain registration service, then it may wish to interpret the data being passed to it as containing two "fields", the first field being a domain to register and the second field being the IP address to register it to. The contract would read these values from the message data and appropriately place them in storage.

前三個是任何加密貨幣中預期的標準欄位。 數據欄位默認沒有功能，但虛擬機具有合同可以訪問數據的操作碼; 作為示例用例，如果合同作為區塊鏈上的域名註冊服務運行，那麼它可能希望將傳遞給它的數據解釋為包含兩個「欄位」，第一個欄位是要註冊的域名，第二個欄位是域名的IP地址。 合同將從消息數據中讀取這些值並將其妥善放置在存儲中。

The STARTGAS and GASPRICE fields are crucial for Ethereums anti-denial of service model. In order to prevent accidental or hostile infinite loops or other computational wastage in code, each transaction is required to set a limit to how many computational steps of code execution it can use. The fundamental unit of computation is "gas"; usually, a computational step costs 1 gas, but some operations cost higher amounts of gas because they are more computationally expensive, or increase the amount of data that must be stored as part of the state. There is also a fee of 5 gas for every byte in the transaction data. The intent of the fee system is to require an attacker to pay proportionately for every resource that they consume, including computation, bandwidth and storage; hence, any transaction that leads to the network consuming a greater amount of any of these resources must have a gas fee roughly proportional to the increment.

對於以太坊的反拒絕服務模式，STARTGAS和GASPRICE欄位至關重要。 為了防止代碼中的意外或惡意的無限循環，或其他計算浪費，每個事務都需要設置它可以使用多少的代碼執行步驟數。 計算的基本單位是「gas」。 通常，一個計算步驟花費1個gas，但是一些操作耗費更高的gas，因為它們在計算上更昂貴，或者增加了作為狀態的一部分的必須存儲的數據量。 交易數據中的每個位元組也要收費5個gas。 收費系統的目的是要求攻擊者按比例支付他們消費的每一種資源，包括計算量，帶寬和存儲量; 因此，任何導致網路消耗更多資源的交易必須具有與增量大致成比例的gas。

Messages 消息

Contracts have the ability to send "messages" to other contracts. Messages are virtual objects that are never serialized and exist only in the Ethereum execution environment. A message contains:

合約具有向其他合約發送「消息」的能力。消息是從沒有被序列化的，只存在於以太坊執行環境的虛擬對象。消息包含：

• The sender of the message (implicit) 消息發送者（固有的）
• The recipient of the message 消息接受者
• The amount of ether to transfer alongside the message 與消息一起被轉移的以太幣的數量
• An optional data field 可選的數據欄位
• A STARTGAS value STARTGAS值

Essentially, a message is like a transaction, except it is produced by a contract and not an external actor. A message is produced when a contract currently executing code executes the CALLopcode, which produces and executes a message. Like a transaction, a message leads to the recipient account running its code. Thus, contracts can have relationships with other contracts in exactly the same way that external actors can.

從本質上講，消息就像一個交易，除了它是由合同產生的而不是由外部參與者產生的之外。 當一個正在運行代碼的協議執行CALLopcode時，將會產生和執行一條消息。 就像一個交易，一條消息導致接收人賬戶運行其代碼。 因此，合約可以擁有與其他合約的關係，這與外部參與者之間的方式完全相同。

Note that the gas allowance assigned by a transaction or contract applies to the total gas consumed by that transaction and all sub-executions. For example, if an external actor A sends a transaction to B with 1000 gas, and B consumes 600 gas before sending a message to C, and the internal execution of C consumes 300 gas before returning, then B can spend another 100 gas before running out of gas.

請注意，交易或合同分配的gas限額適用於該交易和所有子執行消耗的總gas。 例如，如果外部參與者A向B發送帶有1000個gas的事交易，B在向C發送消息之前消耗了600個gas，並且C的內部執行在返回之前消耗300個gas，則B在用光gas之前，只可以花費另外100個gas。

Ethereum State Transition Function 以太坊狀態轉換函數

The Ethereum state transition function, APPLY(S,TX) -> S can be defined as follows:

以太坊狀態轉換函數 APPLY(S,TX) -> S 定義如下：

1. Check if the transaction is well-formed (ie. has the right number of values), the signature is valid, and the nonce matches the nonce in the senders account. If not, return an error. 檢查交易是否被構建完好（例如，有正確的值），簽名是否正確，隨機數是否與發送者賬戶的隨機數匹配。如果不是，返回錯誤。
2. Calculate the transaction fee as STARTGAS * GASPRICE, and determine the sending address from the signature. Subtract the fee from the senders account balance and increment the senders nonce. If there is not enough balance to spend, return an error. 通過 STARTGAS * GASPRICE計算出交易費用，確定發生地址來自於簽名，從發送者賬戶減去費用，同時增加發送者的隨機數。如果沒有足夠的餘額，返回錯誤。
3. Initialize GAS = STARTGAS, and take off a certain quantity of gas per byte to pay for the bytes in the transaction. 初始化 GAS = STARTGAS，在交易中支付確定每位元組數量的gas。
4. Transfer the transaction value from the senders account to the receiving account. If the receiving account does not yet exist, create it. If the receiving account is a contract, run the contracts code either to completion or until the execution runs out of gas. 從發送者賬戶轉移交易數額至接受者的賬戶。如果接受者的賬戶不存在，創建一個。如果接受者賬戶是一個合約，運行合約代碼要麼完成，要麼用光了所有的gas。
5. If the value transfer failed because the sender did not have enough money, or the code execution ran out of gas, revert all state changes except the payment of the fees, and add the fees to the miners account. 如果是因為發送者沒有足夠的錢而導致轉移失敗，或者是代碼運行用光了gas，除了支付的費用外，恢復所有狀態的更改，並將費用支付給礦工的賬戶。
6. Otherwise, refund the fees for all remaining gas to the sender, and send the fees paid for gas consumed to the miner. 相反的情況，將剩餘的費用找零給發送者，支付消耗的費用給礦工。

For example, suppose that the contracts code is:

例如，假定合約代碼如下：

if !self.storage[calldataload(0)]: self.storage[calldataload(0)] = calldataload(32)

Note that in reality the contract code is written in the low-level EVM code; this example is written in Serpent, one of our high-level languages, for clarity, and can be compiled down to EVM code. Suppose that the contracts storage starts off empty, and a transaction is sent with 10 ether value, 2000 gas, 0.001 ether gasprice, and 64 bytes of data, with bytes 0-31 representing the number 2and bytes 32-63 representing the string CHARLIE. The process for the state transition function in this case is as follows:

請注意，實際上，合約代碼是用低級EVM代碼編寫的; 為了清晰起見，本示例使用Serpent（我們的高級語言之一）編寫，並且可以編譯為EVM代碼。 假設，合約的存儲從空開始，交易是發送：10個以太幣，2000gas，0.001 gasprice 和 64位元組，其中位元組0-31代表數字2，位元組32-63代表字元串CHARLIE。 在這種情況下狀態轉換函數進行如下處理：

1. Check that the transaction is valid and well formed. 檢查交易是否有效並組織完好
2. Check that the transaction sender has at least 2000 * 0.001 = 2 ether. If it is, then subtract 2 ether from the senders account. 檢查交易發送者至少擁有2000 * 0.001 = 2 個以太幣，並從其賬戶上扣減2個以太幣
3. Initialize gas = 2000; assuming the transaction is 170 bytes long and the byte-fee is 5, subtract 850 so that there is 1150 gas left. 初始化 gas = 2000，假定交易是170位元組，每位元組5gas，減去850gas，剩下 1150 gas
4. Subtract 10 more ether from the senders account, and add it to the contracts account. 從發送者賬戶減去10個以太幣，將其增加到合約賬戶
5. Run the code. In this case, this is simple: it checks if the contracts storage at index 2 is used, notices that it is not, and so it sets the storage at index 2 to the value CHARLIE. Suppose this takes 187 gas, so the remaining amount of gas is 1150 - 187 = 963 運行代碼。在這個案例中，非常簡單：檢查合約賬戶的存儲索引 2 是否被使用，提示沒有，則將存儲索引2的數據設置為 CHARLIE 。假設這花費了187gas，餘下的就是 1150 - 187 = 963 gas
6. Add 963 * 0.0001 = 0.963 ether back to the senders account, and return the resulting state. 返還 963 * 0.0001 = 0.963 以太幣到發送者賬戶，同時返回結果狀態。

If there was no contract at the receiving end of the transaction, then the total transaction fee would simply be equal to the provided GASPRICE multiplied by the length of the transaction in bytes, and the data sent alongside the transaction would be irrelevant.

如果在交易接收端沒有合約，那麼總的交易費用將等於所提供的GASPRICE乘以交易的長度（以位元組為單位），與交易一起發送的數據無關。

Note that messages work equivalently to transactions in terms of reverts: if a message execution runs out of gas, then that messages execution, and all other executions triggered by that execution, revert, but parent executions do not need to revert. This means that it is "safe" for a contract to call another contract, as if A calls B with G gas then As execution is guaranteed to lose at most G gas. Finally, note that there is an opcode, CREATE, that creates a contract; its execution mechanics are generally similar to CALL, with the exception that the output of the execution determines the code of a newly created contract.

請注意，消息在回滾方面與交易相同：如果消息執行耗盡gas，那麼該消息的執行以及該執行觸發的所有其他執行都會回滾，但父執行不需要回滾。 這意味著合約調用另一份合約是「安全的」，就好像A用G gas調用B，那麼可以確保A的執行最多會損失G gas。 最後，請注意，有一個操作碼CREATE，它創建合約; 其執行機制通常與CALL類似，例外是執行的輸出決定了新創建的合約代碼。

Code Execution 代碼執行

The code in Ethereum contracts is written in a low-level, stack-based bytecode language, referred to as "Ethereum virtual machine code" or "EVM code". The code consists of a series of bytes, where each byte represents an operation. In general, code execution is an infinite loop that consists of repeatedly carrying out the operation at the current program counter (which begins at zero) and then incrementing the program counter by one, until the end of the code is reached or an error or STOP or RETURN instruction is detected. The operations have access to three types of space in which to store data:

以太坊合約中的代碼採用低級，基於堆棧的位元組碼語言編寫，被稱為「以太坊虛擬機代碼」或「EVM代碼」。 該代碼由一系列位元組組成，其中每個位元組表示一個操作。 一般來說，代碼執行是一個無限循環，它包括在當前程序計數器（從零開始）重複執行操作，然後將程序計數器遞增1，直到代碼結束或錯誤或STOP 或RETURN指令被檢測到。 這些操作可以訪問三種類型的數據存儲空間：

• The stack, a last-in-first-out container to which values can be pushed and popped 堆棧，數據壓入彈出的後進先出的容器
• Memory, an infinitely expandable byte array 內存，一個無限擴展的位元組數組
• The contracts long-term storage, a key/value store. Unlike stack and memory, which reset after computation ends, storage persists for the long term. 合約的長期存儲，一個鍵/值存儲，與堆棧和內存會在計算結束後重置不同，這一存儲將會長期保持，

The code can also access the value, sender and data of the incoming message, as well as block header data, and the code can also return a byte array of data as an output.

代碼還可以訪問傳入消息的值，發送者和數據以及塊頭數據，代碼也可以返回一個位元組數組作為輸出。

The formal execution model of EVM code is surprisingly simple. While the Ethereum virtual machine is running, its full computational state can be defined by the tuple (block_state, transaction, message, code, memory, stack, pc, gas), where block_state is the global state containing all accounts and includes balances and storage. At the start of every round of execution, the current instruction is found by taking the pcth byte of code (or 0 if pc >= len(code)), and each instruction has its own definition in terms of how it affects the tuple. For example, ADD pops two items off the stack and pushes their sum, reduces gas by 1 and increments pc by 1, and SSTORE pops the top two items off the stack and inserts the second item into the contracts storage at the index specified by the first item. Although there are many ways to optimize Ethereum virtual machine execution via just-in-time compilation, a basic implementation of Ethereum can be done in a few hundred lines of code.

EVM代碼的正式執行模型非常簡單。 當以太坊虛擬機正在運行時，它的完整計算狀態可以由元組（block_state，transaction，message，code，memory，stack，pc，gas）定義，其中block_state是包含所有帳戶的全局狀態，並包含餘額和存儲。 在每一輪執行開始時，當前指令可以通過獲取代碼的pc th（譯者註：類似4th，5th 等）位元組來找到（如果pc> = len（code），則為0），並且每條指令都有其自己的定義，以表明它如何影響元組。 例如，ADD從堆疊中彈出兩個物品並推送其總和，將gas減少1，並將pc遞增1，SSTORE將頂部兩項品從堆棧中彈出，並將第二項插入到合約存儲器中作為索引的第一項。 雖然有很多方法可以通過即時編譯來優化以太坊虛擬機的執行，但以太坊的基本實現可以通過幾百行代碼完成。

Blockchain and Mining 區塊鏈和挖礦

The Ethereum blockchain is in many ways similar to the Bitcoin blockchain, although it does have some differences. The main difference between Ethereum and Bitcoin with regard to the blockchain architecture is that, unlike Bitcoin, Ethereum blocks contain a copy of both the transaction list and the most recent state. Aside from that, two other values, the block number and the difficulty, are also stored in the block. The basic block validation algorithm in Ethereum is as follows:

以太坊區塊鏈在很多方面與比特幣區塊鏈相似，但它確實有一些區別。 以太坊和比特幣在區塊鏈架構方面的主要區別在於，與比特幣不同，以太坊區塊包含交易列表和最新狀態的副本。 除此之外，區塊塊中還存儲了其他兩個值，區塊號和難度。 以太坊中的基礎的區塊驗證演算法如下：

1. Check if the previous block referenced exists and is valid. 檢查被引用的前一區塊是否存在並有效
2. Check that the timestamp of the block is greater than that of the referenced previous block and less than 15 minutes into the future 檢查時間戳是否大於被引用的前一區塊並且小於未來15分鐘
3. Check that the block number, difficulty, transaction root, uncle root and gas limit (various low-level Ethereum-specific concepts) are valid. 檢查區塊號，難度，交易根，叔根和gas限制（各種各樣底層的以太坊特有概念）是否有效。
4. Check that the proof of work on the block is valid. 檢查當前區塊的工作量證明是否有效。
5. Let S[0] be the state at the end of the previous block. 讓 S[0] 作為前一區塊末尾的狀態
6. Let TX be the blocks transaction list, with n transactions. For all i in 0...n-1, set S[i+1] = APPLY(S[i],TX[i]). If any applications returns an error, or if the total gas consumed in the block up until this point exceeds the GASLIMIT, return an error. 讓 TX 作為區塊的交易列表，包含了 n 個交易。為所有在 0...n-1的 i 進行操作, 讓 S[i+1] = APPLY(S[i],TX[i])。如果任何應用返回錯誤，或者 gas 消耗超過了 GASLINIT 的限制，返回錯誤。
7. Let S_FINAL be S[n], but adding the block reward paid to the miner. 讓S_FINAL 成為 S[n]，但要增加支付給礦工的區塊獎勵。
8. Check if the Merkle tree root of the state S_FINAL is equal to the final state root provided in the block header. If it is, the block is valid; otherwise, it is not valid. 檢查 S_FINAL 中默克爾樹根是否等於區塊頭部的最終狀態根。如果相等則區塊是有效的，否則區塊無效。

The approach may seem highly inefficient at first glance, because it needs to store the entire state with each block, but in reality efficiency should be comparable to that of Bitcoin. The reason is that the state is stored in the tree structure, and after every block only a small part of the tree needs to be changed. Thus, in general, between two adjacent blocks the vast majority of the tree should be the same, and therefore the data can be stored once and referenced twice using pointers (ie. hashes of subtrees). A special kind of tree known as a "Patricia tree" is used to accomplish this, including a modification to the Merkle tree concept that allows for nodes to be inserted and deleted, and not just changed, efficiently. Additionally, because all of the state information is part of the last block, there is no need to store the entire blockchain history - a strategy which, if it could be applied to Bitcoin, can be calculated to provide 5-20x savings in space.

這種方法乍一看似乎效率很低，因為它需要在每個塊中存儲整個狀態，但實際上效率應該與比特幣相當。 原因是狀態存儲在樹狀結構中，並且在每個塊之後只需要改變樹的一小部分。 因此，通常在兩個相鄰塊之間，絕大多數樹應該是相同的，因此數據可以被存儲一次並且使用指針（即子樹的散列）被引用兩次。 一種稱為「Patricia樹」的特殊樹被用來實現這一點，包括對Merkle樹概念的修改，允許節點被插入和刪除，而不僅僅是改變，非常高效。 此外，由於所有狀態信息都是最後一個區塊的一部分，因此不需要存儲整個區塊鏈歷史記錄 - 這一策略如果應用於比特幣，可以節省出節省5-20倍的空間。

A commonly asked question is "where" contract code is executed, in terms of physical hardware. This has a simple answer: the process of executing contract code is part of the definition of the state transition function, which is part of the block validation algorithm, so if a transaction is added into block B the code execution spawned by that transaction will be executed by all nodes, now and in the future, that download and validate block B.

對於物理硬體來說，一個常見問題是「在哪裡」執行合約代碼。一個簡單的答案：執行合同代碼的過程是狀態轉換函數的定義的一部分，函數是區塊驗證演算法的一部分，所以如果將一個交易添加到區塊B中，則該交易導致的代碼執行將是：所有節點，現在和將來，都會下載和驗證區塊B。

Applications 應用

In general, there are three types of applications on top of Ethereum. The first category is financial applications, providing users with more powerful ways of managing and entering into contracts using their money. This includes sub-currencies, financial derivatives, hedging contracts, savings wallets, wills, and ultimately even some classes of full-scale employment contracts. The second category is semi-financial applications, where money is involved but there is also a heavy non-monetary side to what is being done; a perfect example is self-enforcing bounties for solutions to computational problems. Finally, there are applications such as online voting and decentralized governance that are not financial at all.

總的來說，在以太坊之上有三種類型的應用程序。 第一類是金融應用程序，它為用戶提供更強大的管理方式，讓用戶使用它們的資金簽訂合同。 這包括子貨幣，金融衍生品，套期保值合約，儲蓄錢包，遺囑以及最終甚至是一些類別的全面僱傭合同。 第二類是半金融應用，涉及金錢，但也有非常重要的非貨幣方面的工作。一個完美的例子就是為計算問題的解決自我實施獎勵。 最後，還有諸如在線投票和分散式治理等應用程序，這些應用程序一點兒也沒有財務屬性。

Token Systems 代幣系統

On-blockchain token systems have many applications ranging from sub-currencies representing assets such as USD or gold to company stocks, individual tokens representing smart property, secure unforgeable coupons, and even token systems with no ties to conventional value at all, used as point systems for incentivization. Token systems are surprisingly easy to implement in Ethereum. The key point to understand is that all a currency, or token system, fundamentally is a database with one operation: subtract X units from A and give X units to B, with the proviso that (1) A had at least X units before the transaction and (2) the transaction is approved by A. All that it takes to implement a token system is to implement this logic into a contract.

區塊鏈上的代幣系統有許多應用，從代表資產（如美元或黃金）的子貨幣到公司股票，還有代表智能財產的單個代幣，安全不可偽造的優惠券，甚至還有與常規價值完全不相干的代幣，它被用做點激勵系統。 代幣系統在以太坊中實現起來非常簡單。 要理解的關鍵點是，所有貨幣或代幣系統基本上都是一個資料庫，只有一個操作：從A中減去X個單位並將X個單位給予B，但條件是（1）在交易前，A至少有X個單位和（2）交易由A批准。實現代幣系統所需的一切就是將該邏輯在合約中實施。

The basic code for implementing a token system in Serpent looks as follows:

用Serpent編寫的實現代幣系統的基本代碼如下：

def send(to, value): if self.storage[msg.sender] >= value: self.storage[msg.sender] = self.storage[msg.sender] - value self.storage[to] = self.storage[to] + value

This is essentially a literal implementation of the "banking system" state transition function described further above in this document. A few extra lines of code need to be added to provide for the initial step of distributing the currency units in the first place and a few other edge cases, and ideally a function would be added to let other contracts query for the balance of an address. But thats all there is to it. Theoretically, Ethereum-based token systems acting as sub-currencies can potentially include another important feature that on-chain Bitcoin-based meta-currencies lack: the ability to pay transaction fees directly in that currency. The way this would be implemented is that the contract would maintain an ether balance with which it would refund ether used to pay fees to the sender, and it would refill this balance by collecting the internal currency units that it takes in fees and reselling them in a constant running auction. Users would thus need to "activate" their accounts with ether, but once the ether is there it would be reusable because the contract would refund it each time.

這實質上是對上文中進一步描述的「銀行系統」狀態轉換函數的字面實現。需要添加一些額外的代碼行，以便首先提供分配貨幣單位的第一步以及其他一些邊緣情況；理想情況下，會添加一個函數以便讓其他合同來查詢地址的餘額。但，這就是它的全部。從理論上講，以太坊為基礎的代幣系統充當次級貨幣可能會包含，鏈式的以基於比特幣元幣所缺乏的，另一個重要特徵：能夠直接以該貨幣支付交易費用。這樣做的方式是，合同將維護一個以太幣賬戶，這樣就可以用給發送人的以太幣退款來支付交易費用，合約將通過收集被作為交易費的內部貨幣單位，並在一個不斷運行的拍賣中再次賣掉，以實現為該賬戶注資。用戶因此需要使用以太幣來「激活」他們的賬戶，但是一旦以太會在那裡就可以重用，因為合約每次都會退還。

Financial derivatives and Stable-Value Currencies

金融衍生品和價值穩定的貨幣

Financial derivatives are the most common application of a "smart contract", and one of the simplest to implement in code. The main challenge in implementing financial contracts is that the majority of them require reference to an external price ticker; for example, a very desirable application is a smart contract that hedges against the volatility of ether (or another cryptocurrency) with respect to the US dollar, but doing this requires the contract to know what the value of ETH/USD is. The simplest way to do this is through a "data feed" contract maintained by a specific party (eg. NASDAQ) designed so that that party has the ability to update the contract as needed, and providing an interface that allows other contracts to send a message to that contract and get back a response that provides the price.

金融衍生工具是「智能合約」中最常見的應用，也是最簡單的代碼實現之一。 實施金融合同的主要挑戰是，其中大部分要求參考外部價格報價器; 例如，一個非常理想的應用程序是一種智能合約，可以抵禦以太幣（或另一種加密貨幣）相對於美元的波動性，但這樣做需要合約知道ETH / USD的價值。 最簡單的方法是通過由特定方（例如納斯達克）維護的「數據反饋」合同，以便該方有權根據需要更新合同，並提供一個介面，以允許其他合同向那個合同發送消息並取回提供價格的響應。

Given that critical ingredient, the hedging contract would look as follows:

給定關鍵元素，對沖合約看起來如下：

1. Wait for party A to input 1000 ether. 等待 A 方 輸入1000 以太幣
2. Wait for party B to input 1000 ether. 等待 B 方輸入1000以太幣
3. Record the USD value of 1000 ether, calculated by querying the data feed contract, in storage, say this is $x. 記錄1000 以太幣價值多少美元，這通過詢問數據反饋合約後計算獲得，保存，假如是 $x。
4. After 30 days, allow A or B to "reactivate" the contract in order to send $x worth of ether (calculated by querying the data feed contract again to get the new price) to A and the rest to B. 30天後，允許A或者B再次激活合約，發送價值$x 的以太幣給A，具體的以太幣的數值當然也是在詢問數據反饋合約後計算獲得，餘下的以太幣發送給B。

Such a contract would have significant potential in crypto-commerce. One of the main problems cited about cryptocurrency is the fact that its volatile; although many users and merchants may want the security and convenience of dealing with cryptographic assets, they may not wish to face that prospect of losing 23% of the value of their funds in a single day. Up until now, the most commonly proposed solution has been issuer-backed assets; the idea is that an issuer creates a sub-currency in which they have the right to issue and revoke units, and provide one unit of the currency to anyone who provides them (offline) with one unit of a specified underlying asset (eg. gold, USD). The issuer then promises to provide one unit of the underlying asset to anyone who sends back one unit of the crypto-asset. This mechanism allows any non-cryptographic asset to be "uplifted" into a cryptographic asset, provided that the issuer can be trusted.

這樣的合同在密碼商務中將具有巨大的潛力。 引用加密貨幣的主要問題之一是不穩定; 儘管許多用戶和商家可能希望使用加密資產的安全性和便利性，但他們可能不希望一天內損失其資金價值23％的前景。 到目前為止，最常見的解決方案是發行人背書資產; 這個想法是，發行人創建了一個子貨幣，他們有權發行和撤回貨幣單位，並將任何一個單位的貨幣提供給那些給他們（離線）提供一個單位特定基礎資產（例如，黃金 ， 美元）的人。 然後，發行人承諾向發回一個單位加密資產的任何人返還一個基礎資產單位。 該機制允許任何非密碼資產被「提升」為密碼資產，前提是發行人可以被信任。

In practice, however, issuers are not always trustworthy, and in some cases the banking infrastructure is too weak, or too hostile, for such services to exist. Financial derivatives provide an alternative. Here, instead of a single issuer providing the funds to back up an asset, a decentralized market of speculators, betting that the price of a cryptographic reference asset (eg. ETH) will go up, plays that role. Unlike issuers, speculators have no option to default on their side of the bargain because the hedging contract holds their funds in escrow. Note that this approach is not fully decentralized, because a trusted source is still needed to provide the price ticker, although arguably even still this is a massive improvement in terms of reducing infrastructure requirements (unlike being an issuer, issuing a price feed requires no licenses and can likely be categorized as free speech) and reducing the potential for fraud.

然而，在實踐中，發行人並不總是值得信賴的，而且在某些情況下，銀行業基礎設施太脆弱，或者銀行不夠誠信，所以這樣的服務不能存在。金融衍生產品提供了另一種選擇。在這裡，不是單一發行人提供資金來支撐一種資產，而是一個分散式的投機者市場，他們認為加密資產（例如ETH）的價格會上漲，而扮演了投機者這個角色。 與發行人不同，投機者沒有討價還價的餘地，因為對沖合約持有他們的資金託管。 請注意，這種方法並不是完全分散式的，因為仍然需要一個可信賴的來源來提供報價，儘管可以說即使如此，這也仍然是一個在降低基礎設施要求（與發行商不同，發布價格反饋不需要許可證，並可能被歸類為言論自由）和減少欺詐的可能性方面的巨大進步。

Identity and Reputation Systems 身份和信譽系統

The earliest alternative cryptocurrency of all, Namecoin, attempted to use a Bitcoin-like blockchain to provide a name registration system, where users can register their names in a public database alongside other data. The major cited use case is for a DNS system, mapping domain names like "bitcoin.org" (or, in Namecoins case, "bitcoin.bit") to an IP address. Other use cases include email authentication and potentially more advanced reputation systems. Here is the basic contract to provide a Namecoin-like name registration system on Ethereum:

最早的替代加密貨幣，Namecoin試圖使用類似比特幣的區塊鏈來提供名稱註冊系統，用戶可以在公共資料庫中將他們的名稱與其他數據一起註冊。 主要引用的用例是DNS系統，將域名（比如「bitcoin.org」）（或者在Namecoin的例子中是「bitcoin.bit」）映射到IP地址。 其他用例包括電子郵件認證和潛在的更高級的信譽系統。 以下是在以太坊提供類似Namecoin的名稱註冊系統的基本合約：

def register(name, value): if !self.storage[name]: self.storage[name] = value

The contract is very simple; all it is is a database inside the Ethereum network that can be added to, but not modified or removed from. Anyone can register a name with some value, and that registration then sticks forever. A more sophisticated name registration contract will also have a "function clause" allowing other contracts to query it, as well as a mechanism for the "owner" (ie. the first registerer) of a name to change the data or transfer ownership. One can even add reputation and web-of-trust functionality on top.

合約非常簡單; 所有這一切都是以太坊網路內的一個資料庫，可以添加到但不能修改或刪除。 任何人都可以註冊一個具有一定價值的名稱，然後該註冊將永久保存。 一個更複雜的名稱註冊合同也會有一個「函數條款」，允許其他合同進行查詢，以及一個為「所有者」而設的機制（即，第一註冊者），所有者可以更改數據或轉讓所有權。 人們甚至可以在上面添加信譽和網路信任功能。

Decentralized File Storage 分散式文件存儲

Over the past few years, there have emerged a number of popular online file storage startups, the most prominent being Dropbox, seeking to allow users to upload a backup of their hard drive and have the service store the backup and allow the user to access it in exchange for a monthly fee. However, at this point the file storage market is at times relatively inefficient; a cursory look at various existing solutions shows that, particularly at the "uncanny valley" 20-200 GB level at which neither free quotas nor enterprise-level discounts kick in, monthly prices for mainstream file storage costs are such that you are paying for more than the cost of the entire hard drive in a single month. Ethereum contracts can allow for the development of a decentralized file storage ecosystem, where individual users can earn small quantities of money by renting out their own hard drives and unused space can be used to further drive down the costs of file storage.

在過去幾年中，已經出現了一些流行的在線文件存儲初創公司，其中最著名的是Dropbox，它試圖允許用戶上傳他們硬碟的備份，提供保存備份和用戶訪問這些數據服務，他們為此收取月費。 但是，目前文件存儲市場有時相對低效， 粗略看一下現有的各種解決方案，特別是在20-200 GB的「恐怖谷」水平上，既沒有免費額度也沒有企業級的折扣，你支付的主流文件存儲成本的每月價格，要高於單月整個硬碟的成本。 以太坊合同可以允許開發分散式文件存儲生態系統，個人用戶可以通過出租自己的硬碟來賺取少量的資金，未使用的空間可以用來進一步降低文件存儲成本。

The key underpinning piece of such a device would be what we have termed the "decentralized Dropbox contract". This contract works as follows. First, one splits the desired data up into blocks, encrypting each block for privacy, and builds a Merkle tree out of it. One then makes a contract with the rule that, every N blocks, the contract would pick a random index in the Merkle tree (using the previous block hash, accessible from contract code, as a source of randomness), and give X ether to the first entity to supply a transaction with a simplified payment verification-like proof of ownership of the block at that particular index in the tree. When a user wants to re-download their file, they can use a micropayment channel protocol (eg. pay 1 szabo per 32 kilobytes) to recover the file; the most fee-efficient approach is for the payer not to publish the transaction until the end, instead replacing the transaction with a slightly more lucrative one with the same nonce after every 32 kilobytes.

這種裝置的關鍵部件我們稱之為「分散式Dropbox合同」。該合同的如此工作。首先，將所需數據分成塊，對每個塊進行隱私加密，然後構建默克爾樹。然後用以下規則形成合約：每N個塊，合約將在Merkle樹中選擇一個隨機索引（可從合同代碼訪問，使用之前的區塊散列作為隨機源），並將 X 以太幣賦予第一個實體，為該交易提供一個簡化的支付驗證（SPV） - 就像在樹中特定索引處的塊的所有權證明。當用戶想要重新下載他們的文件時，他們可以使用微支付通道協議（例如，支付每32千位元組1個szabo）來恢復文件;最節省費用的方法是付款人不到最後不要發布交易，而是，在每32千位元組之後，用一個更划算的帶有同樣隨機數的交易取代原來的那個。

An important feature of the protocol is that, although it may seem like one is trusting many random nodes not to decide to forget the file, one can reduce that risk down to near-zero by splitting the file into many pieces via secret sharing, and watching the contracts to see each piece is still in some nodes possession. If a contract is still paying out money, that provides a cryptographic proof that someone out there is still storing the file.

該協議的一個重要特點是，雖然看起來像一個人相信許多不會丟失文件的隨機節點，但可以通過秘密共享將文件分割成許多塊，從而將風險降低到接近於零，並通過監看合約來了解每個碎片仍然在某個節點中。 如果合約仍在支付金錢，那麼它提供了一個某人仍在存儲該文件的密碼學證據。

Decentralized Autonomous Organizations 分散式自治組織

The general concept of a "decentralized autonomous organization" is that of a virtual entity that has a certain set of members or shareholders which, perhaps with a 67% majority, have the right to spend the entitys funds and modify its code. The members would collectively decide on how the organization should allocate its funds. Methods for allocating a DAOs funds could range from bounties, salaries to even more exotic mechanisms such as an internal currency to reward work. This essentially replicates the legal trappings of a traditional company or nonprofit but using only cryptographic blockchain technology for enforcement. So far much of the talk around DAOs has been around the "capitalist" model of a "decentralized autonomous corporation" (DAC) with dividend-receiving shareholders and tradable shares; an alternative, perhaps described as a "decentralized autonomous community", would have all members have an equal share in the decision making and require 67% of existing members to agree to add or remove a member. The requirement that one person can only have one membership would then need to be enforced collectively by the group.

「分散式自治組織」的一般概念是擁有一定數量的成員或股東的虛擬實體，這些成員或股東可能擁有67％的多數股東權利，有權花費實體的資金和修改代碼。成員將共同決定組織如何分配資金。分配DAO資金的方法可以，從賞金，工資，到更多如用內部貨幣以獎勵工作這樣的外來機制。這基本上複製了傳統公司或非營利組織的法律外觀，但僅使用加密區塊鏈技術來執行。到目前為止，關於DAO的大部分討論都圍繞著「分散式自治公司」（DAC）的「資本主義」模式，其中包含接受分紅的股東和可交易股票;另一種可能被稱為「分散式自治社區」的替代方案，所有成員在決策中擁有平等的份額，增加或開除一名成員，需要得到67％現有成員的同意。一個人只能擁有一個會員資格的要求，將需要該團體共同強制執行。

A general outline for how to code a DAO is as follows. The simplest design is simply a piece of self-modifying code that changes if two thirds of members agree on a change. Although code is theoretically immutable, one can easily get around this and have de-facto mutability by having chunks of the code in separate contracts, and having the address of which contracts to call stored in the modifiable storage. In a simple implementation of such a DAO contract, there would be three transaction types, distinguished by the data provided in the transaction:

如何編寫DAO的一般概要如下。 最簡單的設計只是一個自我修改的代碼，如果三分之二的成員同意修改就會發生變化。 儘管代碼在理論上是不可變的，但人們可以很容易地解決這個問題，通過在單獨的合同中包含大部分代碼，並調用那些合同的地址存儲在可修改的存儲中，從而具有事實上的可變性。 在這種DAO合同的簡單實現中，有三種交易類型，通過交易中提供的數據進行區分：

• [0,i,K,V] to register a proposal with index i to change the address at storage index K to value V 註冊一個提議，用索引 i 來修改存儲索引 K 到 V 的地址
• [0,i] to register a vote in favor of proposal i 註冊一個贊成建議 i 的投票
• [2,i] to finalize proposal i if enough votes have been made 如果足夠的投票已經做出，敲定建議 i 。

The contract would then have clauses for each of these. It would maintain a record of all open storage changes, along with a list of who voted for them. It would also have a list of all members. When any storage change gets to two thirds of members voting for it, a finalizing transaction could execute the change. A more sophisticated skeleton would also have built-in voting ability for features like sending a transaction, adding members and removing members, and may even provide for Liquid Democracy-style vote delegation (ie. anyone can assign someone to vote for them, and assignment is transitive so if A assigns B and B assigns C then C determines As vote). This design would allow the DAO to grow organically as a decentralized community, allowing people to eventually delegate the task of filtering out who is a member to specialists, although unlike in the "current system" specialists can easily pop in and out of existence over time as individual community members change their alignments.

合同的每一項都有條款。它將保存所有開放存儲更改的記錄以及誰投票給他們的清單。它也會有一個所有成員的名單。當任何存儲變更得到三分之二的成員投票支持時，敲定的交易來執行變更。一個更複雜的框架可能也會具有內置投票功能，例如發送交易，增加成員和刪除成員等功能，甚至可以提供流動民主風格的投票授權（即任何人都可以指定某人投票給他們，因此如果A指定B投票，B指定C，則C決定A的投票）。這種設計可以使DAO作為一個分散式的社區有機地發展起來，允許人們最終將挑選合適人選的任務委派給專家，但與「現有系統」不同，隨著時間的推移，當個別社區成員改變他們的陣營時，專家很容易的加入或退出。

An alternative model is for a decentralized corporation, where any account can have zero or more shares, and two thirds of the shares are required to make a decision. A complete skeleton would involve asset management functionality, the ability to make an offer to buy or sell shares, and the ability to accept offers (preferably with an order-matching mechanism inside the contract). Delegation would also exist Liquid Democracy-style, generalizing the concept of a "board of directors".

Further Applications

1. Savings wallets. Suppose that Alice wants to keep her funds safe, but is worried that she will lose or someone will hack her private key. She puts ether into a contract with Bob, a bank, as follows:

• Alice alone can withdraw a maximum of 1% of the funds per day.
• Bob alone can withdraw a maximum of 1% of the funds per day, but Alice has the ability to make a transaction with her key shutting off this ability.
• Alice and Bob together can withdraw anything.

Normally, 1% per day is enough for Alice, and if Alice wants to withdraw more she can contact Bob for help. If Alices key gets hacked, she runs to Bob to move the funds to a new contract. If she loses her key, Bob will get the funds out eventually. If Bob turns out to be malicious, then she can turn off his ability to withdraw.

2. Crop insurance. One can easily make a financial derivatives contract but using a data feed of the weather instead of any price index. If a farmer in Iowa purchases a derivative that pays out inversely based on the precipitation in Iowa, then if there is a drought, the farmer will automatically receive money and if there is enough rain the farmer will be happy because their crops would do well. This can be expanded to natural disaster insurance generally.

3. A decentralized data feed. For financial contracts for difference, it may actually be possible to decentralize the data feed via a protocol called "SchellingCoin". SchellingCoin basically works as follows: N parties all put into the system the value of a given datum (eg. the ETH/USD price), the values are sorted, and everyone between the 25th and 75th percentile gets one token as a reward. Everyone has the incentive to provide the answer that everyone else will provide, and the only value that a large number of players can realistically agree on is the obvious default: the truth. This creates a decentralized protocol that can theoretically provide any number of values, including the ETH/USD price, the temperature in Berlin or even the result of a particular hard computation.

4. Smart multisignature escrow. Bitcoin allows multisignature transaction contracts where, for example, three out of a given five keys can spend the funds. Ethereum allows for more granularity; for example, four out of five can spend everything, three out of five can spend up to 10% per day, and two out of five can spend up to 0.5% per day. Additionally, Ethereum multisig is asynchronous - two parties can register their signatures on the blockchain at different times and the last signature will automatically send the transaction.

5. Cloud computing. The EVM technology can also be used to create a verifiable computing environment, allowing users to ask others to carry out computations and then optionally ask for proofs that computations at certain randomly selected checkpoints were done correctly. This allows for the creation of a cloud computing market where any user can participate with their desktop, laptop or specialized server, and spot-checking together with security deposits can be used to ensure that the system is trustworthy (ie. nodes cannot profitably cheat). Although such a system may not be suitable for all tasks; tasks that require a high level of inter-process communication, for example, cannot easily be done on a large cloud of nodes. Other tasks, however, are much easier to parallelize; projects like SETI@home, folding@home and genetic algorithms can easily be implemented on top of such a platform.

6. Peer-to-peer gambling. Any number of peer-to-peer gambling protocols, such as Frank Stajano and Richard Claytons Cyberdice, can be implemented on the Ethereum blockchain. The simplest gambling protocol is actually simply a contract for difference on the next block hash, and more advanced protocols can be built up from there, creating gambling services with near-zero fees that have no ability to cheat.

7. Prediction markets. Provided an oracle or SchellingCoin, prediction markets are also easy to implement, and prediction markets together with SchellingCoin may prove to be the first mainstream application of futarchy as a governance protocol for decentralized organizations.

8. On-chain decentralized marketplaces, using the identity and reputation system as a base.

Miscellanea And Concerns

Modified GHOST Implementation

The "Greedy Heaviest Observed Subtree" (GHOST) protocol is an innovation first introduced by Yonatan Sompolinsky and Aviv Zohar in December 2013. The motivation behind GHOST is that blockchains with fast confirmation times currently suffer from reduced security due to a high stale rate - because blocks take a certain time to propagate through the network, if miner A mines a block and then miner B happens to mine another block before miner As block propagates to B, miner Bs block will end up wasted and will not contribute to network security. Furthermore, there is a centralization issue: if miner A is a mining pool with 30% hashpower and B has 10% hashpower, A will have a risk of producing a stale block 70% of the time (since the other 30% of the time A produced the last block and so will get mining data immediately) whereas B will have a risk of producing a stale block 90% of the time. Thus, if the block interval is short enough for the stale rate to be high, A will be substantially more efficient simply by virtue of its size. With these two effects combined, blockchains which produce blocks quickly are very likely to lead to one mining pool having a large enough percentage of the network hashpower to have de facto control over the mining process.

As described by Sompolinsky and Zohar, GHOST solves the first issue of network security loss by including stale blocks in the calculation of which chain is the "longest"; that is to say, not just the parent and further ancestors of a block, but also the stale descendants of the blocks ancestor (in Ethereum jargon, "uncles") are added to the calculation of which block has the largest total proof of work backing it. To solve the second issue of centralization bias, we go beyond the protocol described by Sompolinsky and Zohar, and also provide block rewards to stales: a stale block receives 87.5% of its base reward, and the nephew that includes the stale block receives the remaining 12.5%. Transaction fees, however, are not awarded to uncles.

Ethereum implements a simplified version of GHOST which only goes down seven levels. Specifically, it is defined as follows:

• A block must specify a parent, and it must specify 0 or more uncles
• An uncle included in block B must have the following properties:
• It must be a direct child of the kth generation ancestor of B, where 2 <= k <= 7.
• It cannot be an ancestor of B
• An uncle must be a valid block header, but does not need to be a previously verified or even valid block
• An uncle must be different from all uncles included in previous blocks and all other uncles included in the same block (non-double-inclusion)

• For every uncle U in block B, the miner of B gets an additional 3.125% added to its coinbase reward and the miner of U gets 93.75% of a standard coinbase reward.

This limited version of GHOST, with uncles includable only up to 7 generations, was used for two reasons. First, unlimited GHOST would include too many complications into the calculation of which uncles for a given block are valid. Second, unlimited GHOST with compensation as used in Ethereum removes the incentive for a miner to mine on the main chain and not the chain of a public attacker.

Fees

Because every transaction published into the blockchain imposes on the network the cost of needing to download and verify it, there is a need for some regulatory mechanism, typically involving transaction fees, to prevent abuse. The default approach, used in Bitcoin, is to have purely voluntary fees, relying on miners to act as the gatekeepers and set dynamic minimums. This approach has been received very favorably in the Bitcoin community particularly because it is "market-based", allowing supply and demand between miners and transaction senders determine the price. The problem with this line of reasoning is, however, that transaction processing is not a market; although it is intuitively attractive to construe transaction processing as a service that the miner is offering to the sender, in reality every transaction that a miner includes will need to be processed by every node in the network, so the vast majority of the cost of transaction processing is borne by third parties and not the miner that is making the decision of whether or not to include it. Hence, tragedy-of-the-commons problems are very likely to occur.

However, as it turns out this flaw in the market-based mechanism, when given a particular inaccurate simplifying assumption, magically cancels itself out. The argument is as follows. Suppose that:

1. A transaction leads to k operations, offering the reward kR to any miner that includes it where R is set by the sender and k and R are (roughly) visible to the miner beforehand.
2. An operation has a processing cost of C to any node (ie. all nodes have equal efficiency)
3. There are N mining nodes, each with exactly equal processing power (ie. 1/N of total)
4. No non-mining full nodes exist.

A miner would be willing to process a transaction if the expected reward is greater than the cost. Thus, the expected reward is kR/N since the miner has a 1/N chance of processing the next block, and the processing cost for the miner is simply kC. Hence, miners will include transactions where kR/N > kC, or R > NC. Note that R is the per-operation fee provided by the sender, and is thus a lower bound on the benefit that the sender derives from the transaction, and NC is the cost to the entire network together of processing an operation. Hence, miners have the incentive to include only those transactions for which the total utilitarian benefit exceeds the cost.

However, there are several important deviations from those assumptions in reality:

1. The miner does pay a higher cost to process the transaction than the other verifying nodes, since the extra verification time delays block propagation and thus increases the chance the block will become a stale.
2. There do exist nonmining full nodes.
3. The mining power distribution may end up radically inegalitarian in practice.
4. Speculators, political enemies and crazies whose utility function includes causing harm to the network do exist, and they can cleverly set up contracts where their cost is much lower than the cost paid by other verifying nodes.

(1) provides a tendency for the miner to include fewer transactions, and (2) increases NC; hence, these two effects at least partially cancel each other out.How? (3) and (4) are the major issue; to solve them we simply institute a floating cap: no block can have more operations than BLK_LIMIT_FACTOR times the long-term exponential moving average. Specifically:

blk.oplimit = floor((blk.parent.oplimit * (EMAFACTOR - 1) + floor(parent.opcount * BLK_LIMIT_FACTOR)) / EMA_FACTOR)

BLK_LIMIT_FACTOR and EMA_FACTOR are constants that will be set to 65536 and 1.5 for the time being, but will likely be changed after further analysis.

There is another factor disincentivizing large block sizes in Bitcoin: blocks that are large will take longer to propagate, and thus have a higher probability of becoming stales. In Ethereum, highly gas-consuming blocks can also take longer to propagate both because they are physically larger and because they take longer to process the transaction state transitions to validate. This delay disincentive is a significant consideration in Bitcoin, but less so in Ethereum because of the GHOST protocol; hence, relying on regulated block limits provides a more stable baseline.

Computation And Turing-Completeness

An important note is that the Ethereum virtual machine is Turing-complete; this means that EVM code can encode any computation that can be conceivably carried out, including infinite loops. EVM code allows looping in two ways. First, there is a JUMP instruction that allows the program to jump back to a previous spot in the code, and a JUMPI instruction to do conditional jumping, allowing for statements like while x < 27: x = x * 2. Second, contracts can call other contracts, potentially allowing for looping through recursion. This naturally leads to a problem: can malicious users essentially shut miners and full nodes down by forcing them to enter into an infinite loop? The issue arises because of a problem in computer science known as the halting problem: there is no way to tell, in the general case, whether or not a given program will ever halt.

As described in the state transition section, our solution works by requiring a transaction to set a maximum number of computational steps that it is allowed to take, and if execution takes longer computation is reverted but fees are still paid. Messages work in the same way. To show the motivation behind our solution, consider the following examples:

• An attacker creates a contract which runs an infinite loop, and then sends a transaction activating that loop to the miner. The miner will process the transaction, running the infinite loop, and wait for it to run out of gas. Even though the execution runs out of gas and stops halfway through, the transaction is still valid and the miner still claims the fee from the attacker for each computational step.
• An attacker creates a very long infinite loop with the intent of forcing the miner to keep computing for such a long time that by the time computation finishes a few more blocks will have come out and it will not be possible for the miner to include the transaction to claim the fee. However, the attacker will be required to submit a value for STARTGAS limiting the number of computational steps that execution can take, so the miner will know ahead of time that the computation will take an excessively large number of steps.
• An attacker sees a contract with code of some form like send(A,contract.storage[A]); contract.storage[A] = 0, and sends a transaction with just enough gas to run the first step but not the second (ie. making a withdrawal but not letting the balance go down). The contract author does not need to worry about protecting against such attacks, because if execution stops halfway through the changes get reverted.
• A financial contract works by taking the median of nine proprietary data feeds in order to minimize risk. An attacker takes over one of the data feeds, which is designed to be modifiable via the variable-address-call mechanism described in the section on DAOs, and converts it to run an infinite loop, thereby attempting to force any attempts to claim funds from the financial contract to run out of gas. However, the financial contract can set a gas limit on the message to prevent this problem.

The alternative to Turing-completeness is Turing-incompleteness, where JUMP and JUMPI do not exist and only one copy of each contract is allowed to exist in the call stack at any given time. With this system, the fee system described and the uncertainties around the effectiveness of our solution might not be necessary, as the cost of executing a contract would be bounded above by its size. Additionally, Turing-incompleteness is not even that big a limitation; out of all the contract examples we have conceived internally, so far only one required a loop, and even that loop could be removed by making 26 repetitions of a one-line piece of code. Given the serious implications of Turing-completeness, and the limited benefit, why not simply have a Turing-incomplete language? In reality, however, Turing-incompleteness is far from a neat solution to the problem. To see why, consider the following contracts:

C0: call(C1); call(C1);C1: call(C2); call(C2);C2: call(C3); call(C3);...C49: call(C50); call(C50);C50: (run one step of a program and record the change in storage)

Now, send a transaction to A. Thus, in 51 transactions, we have a contract that takes up 250computational steps. Miners could try to detect such logic bombs ahead of time by maintaining a value alongside each contract specifying the maximum number of computational steps that it can take, and calculating this for contracts calling other contracts recursively, but that would require miners to forbid contracts that create other contracts (since the creation and execution of all 26 contracts above could easily be rolled into a single contract). Another problematic point is that the address field of a message is a variable, so in general it may not even be possible to tell which other contracts a given contract will call ahead of time. Hence, all in all, we have a surprising conclusion: Turing-completeness is surprisingly easy to manage, and the lack of Turing-completeness is equally surprisingly difficult to manage unless the exact same controls are in place - but in that case why not just let the protocol be Turing-complete?

Currency And Issuance

The Ethereum network includes its own built-in currency, ether, which serves the dual purpose of providing a primary liquidity layer to allow for efficient exchange between various types of digital assets and, more importantly, of providing a mechanism for paying transaction fees. For convenience and to avoid future argument (see the current mBTC/uBTC/satoshi debate in Bitcoin), the denominations will be pre-labelled:

• 1: wei
• 1012: szabo
• 1015: finney
• 1018: ether

This should be taken as an expanded version of the concept of "dollars" and "cents" or "BTC" and "satoshi". In the near future, we expect "ether" to be used for ordinary transactions, "finney" for microtransactions and "szabo" and "wei" for technical discussions around fees and protocol implementation; the remaining denominations may become useful later and should not be included in clients at this point.

The issuance model will be as follows:

• Ether will be released in a currency sale at the price of 1000-2000 ether per BTC, a mechanism intended to fund the Ethereum organization and pay for development that has been used with success by other platforms such as Mastercoin and NXT. Earlier buyers will benefit from larger discounts. The BTC received from the sale will be used entirely to pay salaries and bounties to developers and invested into various for-profit and non-profit projects in the Ethereum and cryptocurrency ecosystem.
• 0.099x the total amount sold (60102216 ETH) will be allocated to the organization to compensate early contributors and pay ETH-denominated expenses before the genesis block.
• 0.099x the total amount sold will be maintained as a long-term reserve.
• 0.26x the total amount sold will be allocated to miners per year forever after that point.

GroupAt launchAfter 1 yearAfter 5 yearsCurrency units1.198X1.458X2.498XPurchasers83.5%68.6%40.0%Reserve spent pre-sale8.26%6.79%3.96%Reserve used post-sale8.26%6.79%3.96%Miners0%17.8%52.0%

Long-Term Supply Growth Rate (percent)

Despite the linear currency issuance, just like with Bitcoin over time the supply growth rate nevertheless tends to zero

The two main choices in the above model are (1) the existence and size of an endowment pool, and (2) the existence of a permanently growing linear supply, as opposed to a capped supply as in Bitcoin. The justification of the endowment pool is as follows. If the endowment pool did not exist, and the linear issuance reduced to 0.217x to provide the same inflation rate, then the total quantity of ether would be 16.5% less and so each unit would be 19.8% more valuable. Hence, in the equilibrium 19.8% more ether would be purchased in the sale, so each unit would once again be exactly as valuable as before. The organization would also then have 1.198x as much BTC, which can be considered to be split into two slices: the original BTC, and the additional 0.198x. Hence, this situation is exactly equivalent to the endowment, but with one important difference: the organization holds purely BTC, and so is not incentivized to support the value of the ether unit.

The permanent linear supply growth model reduces the risk of what some see as excessive wealth concentration in Bitcoin, and gives individuals living in present and future eras a fair chance to acquire currency units, while at the same time retaining a strong incentive to obtain and hold ether because the "supply growth rate" as a percentage still tends to zero over time. We also theorize that because coins are always lost over time due to carelessness, death, etc, and coin loss can be modeled as a percentage of the total supply per year, that the total currency supply in circulation will in fact eventually stabilize at a value equal to the annual issuance divided by the loss rate (eg. at a loss rate of 1%, once the supply reaches 26X then 0.26X will be mined and 0.26X lost every year, creating an equilibrium).

Note that in the future, it is likely that Ethereum will switch to a proof-of-stake model for security, reducing the issuance requirement to somewhere between zero and 0.05X per year. In the event that the Ethereum organization loses funding or for any other reason disappears, we leave open a "social contract": anyone has the right to create a future candidate version of Ethereum, with the only condition being that the quantity of ether must be at most equal to 60102216 * (1.198 + 0.26 * n) where n is the number of years after the genesis block. Creators are free to crowd-sell or otherwise assign some or all of the difference between the PoS-driven supply expansion and the maximum allowable supply expansion to pay for development. Candidate upgrades that do not comply with the social contract may justifiably be forked into compliant versions.

Mining Centralization

The Bitcoin mining algorithm works by having miners compute SHA256 on slightly modified versions of the block header millions of times over and over again, until eventually one node comes up with a version whose hash is less than the target (currently around 2192). However, this mining algorithm is vulnerable to two forms of centralization. First, the mining ecosystem has come to be dominated by ASICs (application-specific integrated circuits), computer chips designed for, and therefore thousands of times more efficient at, the specific task of Bitcoin mining. This means that Bitcoin mining is no longer a highly decentralized and egalitarian pursuit, requiring millions of dollars of capital to effectively participate in. Second, most Bitcoin miners do not actually perform block validation locally; instead, they rely on a centralized mining pool to provide the block headers. This problem is arguably worse: as of the time of this writing, the top three mining pools indirectly control roughly 50% of processing power in the Bitcoin network, although this is mitigated by the fact that miners can switch to other mining pools if a pool or coalition attempts a 51% attack.

The current intent at Ethereum is to use a mining algorithm where miners are required to fetch random data from the state, compute some randomly selected transactions from the last N blocks in the blockchain, and return the hash of the result. This has two important benefits. First, Ethereum contracts can include any kind of computation, so an Ethereum ASIC would essentially be an ASIC for general computation - ie. a better CPU. Second, mining requires access to the entire blockchain, forcing miners to store the entire blockchain and at least be capable of verifying every transaction. This removes the need for centralized mining pools; although mining pools can still serve the legitimate role of evening out the randomness of reward distribution, this function can be served equally well by peer-to-peer pools with no central control.

This model is untested, and there may be difficulties along the way in avoiding certain clever optimizations when using contract execution as a mining algorithm. However, one notably interesting feature of this algorithm is that it allows anyone to "poison the well", by introducing a large number of contracts into the blockchain specifically designed to stymie certain ASICs. The economic incentives exist for ASIC manufacturers to use such a trick to attack each other. Thus, the solution that we are developing is ultimately an adaptive economic human solution rather than purely a technical one.

Scalability

One common concern about Ethereum is the issue of scalability. Like Bitcoin, Ethereum suffers from the flaw that every transaction needs to be processed by every node in the network. With Bitcoin, the size of the current blockchain rests at about 15 GB, growing by about 1 MB per hour. If the Bitcoin network were to process Visas 2000 transactions per second, it would grow by 1 MB per three seconds (1 GB per hour, 8 TB per year). Ethereum is likely to suffer a similar growth pattern, worsened by the fact that there will be many applications on top of the Ethereum blockchain instead of just a currency as is the case with Bitcoin, but ameliorated by the fact that Ethereum full nodes need to store just the state instead of the entire blockchain history.

The problem with such a large blockchain size is centralization risk. If the blockchain size increases to, say, 100 TB, then the likely scenario would be that only a very small number of large businesses would run full nodes, with all regular users using light SPV nodes. In such a situation, there arises the potential concern that the full nodes could band together and all agree to cheat in some profitable fashion (eg. change the block reward, give themselves BTC). Light nodes would have no way of detecting this immediately. Of course, at least one honest full node would likely exist, and after a few hours information about the fraud would trickle out through channels like Reddit, but at that point it would be too late: it would be up to the ordinary users to organize an effort to blacklist the given blocks, a massive and likely infeasible coordination problem on a similar scale as that of pulling off a successful 51% attack. In the case of Bitcoin, this is currently a problem, but there exists a blockchain modification suggested by Peter Todd which will alleviate this issue.

In the near term, Ethereum will use two additional strategies to cope with this problem. First, because of the blockchain-based mining algorithms, at least every miner will be forced to be a full node, creating a lower bound on the number of full nodes. Second and more importantly, however, we will include an intermediate state tree root in the blockchain after processing each transaction. Even if block validation is centralized, as long as one honest verifying node exists, the centralization problem can be circumvented via a verification protocol. If a miner publishes an invalid block, that block must either be badly formatted, or the state S[n] is incorrect. Since S[0] is known to be correct, there must be some first state S[i] that is incorrect where S[i-1] is correct. The verifying node would provide the index i, along with a "proof of invalidity" consisting of the subset of Patricia tree nodes needing to process APPLY(S[i-1],TX[i]) -> S[i]. Nodes would be able to use those nodes to run that part of the computation, and see that the S[i] generated does not match the S[i] provided.

Another, more sophisticated, attack would involve the malicious miners publishing incomplete blocks, so the full information does not even exist to determine whether or not blocks are valid. The solution to this is a challenge-response protocol: verification nodes issue "challenges" in the form of target transaction indices, and upon receiving a node a light node treats the block as untrusted until another node, whether the miner or another verifier, provides a subset of Patricia nodes as a proof of validity.

Conclusion

The Ethereum protocol was originally conceived as an upgraded version of a cryptocurrency, providing advanced features such as on-blockchain escrow, withdrawal limits, financial contracts, gambling markets and the like via a highly generalized programming language. The Ethereum protocol would not "support" any of the applications directly, but the existence of a Turing-complete programming language means that arbitrary contracts can theoretically be created for any transaction type or application. What is more interesting about Ethereum, however, is that the Ethereum protocol moves far beyond just currency. Protocols around decentralized file storage, decentralized computation and decentralized prediction markets, among dozens of other such concepts, have the potential to substantially increase the efficiency of the computational industry, and provide a massive boost to other peer-to-peer protocols by adding for the first time an economic layer. Finally, there is also a substantial array of applications that have nothing to do with money at all.

The concept of an arbitrary state transition function as implemented by the Ethereum protocol provides for a platform with unique potential; rather than being a closed-ended, single-purpose protocol intended for a specific array of applications in data storage, gambling or finance, Ethereum is open-ended by design, and we believe that it is extremely well-suited to serving as a foundational layer for a very large number of both financial and non-financial protocols in the years to come.

Notes and Further Reading

Notes

1. A sophisticated reader may notice that in fact a Bitcoin address is the hash of the elliptic curve public key, and not the public key itself. However, it is in fact perfectly legitimate cryptographic terminology to refer to the pubkey hash as a public key itself. This is because Bitcoins cryptography can be considered to be a custom digital signature algorithm, where the public key consists of the hash of the ECC pubkey, the signature consists of the ECC pubkey concatenated with the ECC signature, and the verification algorithm involves checking the ECC pubkey in the signature against the ECC pubkey hash provided as a public key and then verifying the ECC signature against the ECC pubkey.
2. Technically, the median of the 11 previous blocks.
3. Internally, 2 and "CHARLIE" are both numbers, with the latter being in big-endian base 256 representation. Numbers can be at least 0 and at most 2256-1.

Further Reading

1. Intrinsic value: http://bitcoinmagazine.com/8640/an-exploration-of-intrinsic-value-what-it-is-why-bitcoin-doesnt-have-it-and-why-bitcoin-does-have-it/
2. Smart property: https://en.bitcoin.it/wiki/Smart_Property
3. Smart contracts: https://en.bitcoin.it/wiki/Contracts
4. B-money: http://www.weidai.com/bmoney.txt
5. Reusable proofs of work: http://www.finney.org/~hal/rpow/
6. Secure property titles with owner authority: http://szabo.best.vwh.net/securetitle.html
7. Bitcoin whitepaper: http://bitcoin.org/bitcoin.pdf
8. Namecoin: https://namecoin.org/
9. Zookos triangle: http://en.wikipedia.org/wiki/Zookos_triangle
10. Colored coins whitepaper: https://docs.google.com/a/buterin.com/document/d/1AnkP_cVZTCMLIzw4DvsW6M8Q2JC0lIzrTLuoWu2z1BE/edit
11. Mastercoin whitepaper: https://github.com/mastercoin-MSC/spec
12. Decentralized autonomous corporations, Bitcoin Magazine: http://bitcoinmagazine.com/7050/bootstrapping-a-decentralized-autonomous-corporation-part-i/
13. Simplified payment verification: https://en.bitcoin.it/wiki/Scalability#Simplifiedpaymentverification
14. Merkle trees: http://en.wikipedia.org/wiki/Merkle_tree
15. Patricia trees: http://en.wikipedia.org/wiki/Patricia_tree
16. GHOST: https://eprint.iacr.org/2013/881.pdf
17. StorJ and Autonomous Agents, Jeff Garzik: http://garzikrants.blogspot.ca/2013/01/storj-and-bitcoin-autonomous-agents.html
18. Mike Hearn on Smart Property at Turing Festival: http://www.youtube.com/watch?v=Pu4PAMFPo5Y
19. Ethereum RLP: https://github.com/ethereum/wiki/wiki/%5BEnglish%5D-RLP
20. Ethereum Merkle Patricia trees: https://github.com/ethereum/wiki/wiki/%5BEnglish%5D-Patricia-Tree
21. Peter Todd on Merkle sum trees: http://sourceforge.net/p/bitcoin/mailman/message/31709140/

推薦閱讀：