精通以太坊

==== Dapp
https://dapp.tools/dapp/

==== Seth
https://dapp.tools/seth/

==== Hevm
https://dapp.tools/hevm/

==== SputnikVM

SputnikVM是一個獨立的可插拔的用於不同的基於以太坊的區塊鏈的虛擬機。它是用Rust編寫的，可以用作二進制，貨物箱，共享庫，或者通過FFI，Protobuf和JSON接口集成。它有一個單獨的用於測試目的的二進制sputnikvm-dev，它模擬大部分JSON RPC API和區塊挖掘。

Github link; https://github.com/etcdevteam/sputnikvm

== Libraries

=== web3.js

web3.js是以太坊兼容的JS API，用於通過以太坊基金會開發的JSON RPC與客戶進行通信。

Github link; https://github.com/ethereum/web3.js

+npm+ package repository link; https://www.npmjs.com/package/web3

Documentation link for web3.js API 0.2x.x; https://github.com/ethereum/wiki/wiki/JavaScript-API

Documentation link for web3.js API 1.0.0-beta.xx; https://web3js.readthedocs.io/en/1.0/web3.html

=== web3.py

web3.py 是一個用於與以太坊區塊鏈進行交互的Python庫。它現在也在以太坊基金會的GitHub中。

Github link; https://github.com/ethereum/web3.py

PyPi link; https://pypi.python.org/pypi/web3/4.0.0b9

Documentation link; https://web3py.readthedocs.io/

=== EthereumJS

以太坊的庫和實用程式集合。

Github link; https://github.com/ethereumjs

Website link; https://ethereumjs.github.io/

=== web3j

web3j 是Java和Android庫，用於與Ethereum客戶端集成並使用智能合約。

Github link; https://github.com/web3j/web3j

Website link; https://web3j.io

Documentation link; https://docs.web3j.io

=== Etherjar


Etherjar 是與Ethereum集成並與智能合約一起工作的另一個Java庫。它專為基於Java 8+的伺服器端項目而設計，提供RPC的低層和高層封裝，以太坊資料結構和智能合約訪問。

Github link; https://github.com/infinitape/etherjar

=== Nethereum

Nethereum 是以太坊的.Net集成庫。

Github link; https://github.com/Nethereum/Nethereum

Website link; http://nethereum.com/

Documentation link; https://nethereum.readthedocs.io/en/latest/

=== ethers.js

ethers.js 庫是一個緊湊，完整，功能齊全，經過廣泛測試的以太坊庫，完全根據MIT許可證獲得，並且已收到來自以太坊基金會的DevEx資助以擴展和維護。

GitHub link: https://github.com/ethers-io/ethers.js

Documentation: https://docs.ethers.io


=== Emerald Platform

Emerald Platform提供了庫和UI組件，可以在以太坊上構建Dapps。Emerald JS和Emerald JS UI提供了一組模塊和React組件來構建Javascript應用程式和網站，Emerald SVG Icons是一組區塊鏈相關的圖示。除了Javascript庫之外，它還有Rust庫來操作私鑰和交易簽名。所有Emerald庫和組件都使用 Apache 2許可。

Github link; https://github.com/etcdevteam/emerald-platform

Documentation link; https://docs.etcdevteam.com
[[Tokens_chapter]]
== Tokens

[[Tokens_definition]]
=== 什麼是Token?

單詞_Token_來源於古英語“tacen”，意思是符號或符號。常用來表示私人發行的類似硬幣的物品，價值不大，例如交通Token，洗衣Token，遊樂場Token。

如今，基於區塊鏈的Token將這個詞重新定義為基於區塊鏈的抽象概念，可以被擁有，並代表資產，貨幣或訪問權。

“Token”一詞與微不足道的價值之間的聯繫與物理Token的使用限制有很大關係。通常僅限於特定的企業，組織或地點，物理Token不易交換，不能用於多個功能。通過區塊鏈標記，這些限制被刪除。這些Token中的許多Token在全球範圍內有多種用途，可以在全球流動市場中相互交易或與其他貨幣交易。隨著這些限制的消失，“微不足道的價值”的期望也成為過去。

在本節中，我們將看到Token的各種用法以及它們的創建方式。我們還討論Token的屬性，如可互換性和內在性等。最後，我們通過基於構建自己的Token的實驗來檢驗它們的標準和技術。

[[Tokens_use]]
=== 如何使用Token？

Token最明顯的用途是作為數字私人貨幣。但是，這只是一個可能的用途。Token可以被編程為提供許多不同的功能，通常是重疊的。例如，Token可以同時傳達投票權，訪問權和資源所有權。貨幣只是第一個“應用程式”。

貨幣:: Token可以作為一種貨幣形式，其價值通過私人交易來確定。例如，ether或bitcoin。

資源:: Token可以表示在共享經濟或資源共享環境中獲得或生成的資源。例如，表示可通過網路共享的資源的儲存或CPU的Token。

資產:: Token可以代表內在或外在，有形或無形資產的所有權。例如，黃金，房地產，汽車，石油，能源等

訪問:: Token可以代表訪問權限，可以訪問數字或實體資產，例如論壇，專屬網站，酒店房間，租車。

權益:: Token可以代表數字組織（例如DAO）或法律虛擬主體（例如公司）中的股東權益

投票:: Token可以代表數字或法律系統中的投票權。

收藏品:: Token可以代表數字（例如CryptoPunks）或物理收藏品（例如繪畫）

身份:: Token可以代表數字（例如頭像）或合法身份（例如國家ID）。

證明:: Token可以代表某些機構或去中心化的信用系統（例如婚姻記錄，出生證明，大學學位）的認證或事實證明。

實際用途:: Token可用於訪問或支付服務。

通常，單個Token包含其中幾個功能。有時它們之間很難辨別，因為物理等價物一直是密不可分的。例如，在物理世界中，駕駛執照（認證）也是身份證件（身份證明），兩者不能分開。在數字領域，以前的混合功能可以獨立分離和開發（例如匿名認證）。

[[Tokens_fungibility]]
=== Tokens和可互換性

來自Wikipedia:

 在經濟學中，可互換性是一種商品或商品的財產，其獨立單位本質上是可以互換的。

當我們可以將Token的任何單個單元替換為另一個Token而其價值或功能沒有任何差異時，Token是可替代的。例如，ether是一種可替代的Token，因為任何ether的單位具有相同的值並且與任何其他單位的ether一起使用。

嚴格地說，如果可以跟蹤Token的歷史出處，那麼它就不是完全可替代的。追蹤出處的能力可能導致黑名單和白名單，從而降低或消除互通性。我們將在<<privacy>>中進一步研究。

不可互換的Token是代表獨特的有形或無形商品的Token，因此不可互換。例如，表示_特定的_ Van Gogh繪畫所有權的Token不等同於代表畢加索的另一個Token。同樣，表示特定數字收藏的Token，如特定的CryptoKitty（請參閱<<cryptoKitties>>）與任何其他CryptoKitty都不可互換。每個不可互換的Token與唯一識別碼相關聯，例如序列號。

本節後面我們將看到可替換和不可替換Token的例子。

[[counterparty_risk]]
=== 交易對手風險

交易對手風險是交易中的其他方不能履行其義務的風險。由於在交易中增加了兩個以上的交易方，某些類型的交易會產生額外的交易對手風險。例如，如果你持有貴金屬存款證明並將其出售給某人，則該交易中至少有三方：賣方，買方和貴金屬的保管人。有人持有有形資產，必要時他們成為一方併為涉及該資產的任何交易添加交易對手風險。當資產通過交換所有權資訊而間接交易時，資產託管人有額外的交易對手風險。他們有資產嗎？他們是否會根據Token的轉讓（例如證書，契約，所有權或數字Token）識別（或允許）所有權的轉移？在數字Token的世界中，瞭解誰持有由Token表示的資產以及適用於該基礎資產的規則很重要。

[[Tokens_intrinsicality]]
=== Tokens和內在性

單詞 "intrinsic" 源於拉丁詞 "intra", 表示"來自內部".

一些Token代表對區塊鏈來說是 _內在的_ 的數字項目。這些數字資產受共識規則的約束，就像Token本身一樣。這具有重要的意義：代表固有資產的Token不會帶來額外的交易對手風險。如果你持有1 ether的密鑰，就沒有其他方為你持有那個以太。區塊鏈共識規則的應用，使得你對私鑰的所有權（控制權）等同於資產的所有權，無需任何中介。

相反，許多Token用於表示 _外在的_ _extrinsic_事物，如房地產，公司投票股票，商標，金條。這些項目的所有權不屬於區塊鏈，屬於法律，習慣和政策，與管理Token的共識規則分開。換句話說，Token發行人和所有者可能仍然依賴現實世界的非智能合約。因此，這些外部資產會帶來額外的交易對手風險，因為它們由託管人持有，記錄在外部註冊管理機構中，或由區塊鏈環境以外的法律和政策控制。

基於區塊鏈的Token最重要的後果之一是能夠將外部資產轉換為內部資產，從而消除交易對手風險。一個很好的例子就是從一家公司的股權（外部）轉向一個 _去中心化的自治組織_ 或類似的（內部）組織的股權或投票權。

[[using_Tokens]]
=== 使用Tokens：效用或權益

今天以太坊的幾乎所有項目都以某種形式發佈。但是，所有這些項目真的需要一個Token嗎？使用Token有什麼缺點，或者我們會看到口號“將所有東西Token化”的口號是否成熟？

首先，讓我們首先澄清Token在新項目中的作用。大多數項目都以兩種方式之一使用Token：要麼是“實用Token”，要麼是“權益Token”。很多時候，這兩個角色是混合在一起的，難以區分。

實用Token是那些需要使用Token來支付服務，應用程式或資源的Token。實用Token的例子包括代表資源的Token，如共享儲存，訪問社交媒體網路等服務，或將ether作為以太坊平臺的gas。相比之下，權益Token是代表創業公司股票的Token。

股權Token可以像享有利潤和分紅的無投票權股份一樣有限，或者向去中心化自治組織的有投票權的股票一樣廣泛，其中平臺是通過Token持有者的多數投票管理的。

[[its_not_duck]]
==== 它不是一隻鴨子

僅僅因為Token用於為初創公司籌款，並不意味著它必須用作服務的支付，反之亦然。然而，許多初創公司面臨著一個難題：Token是一種很好的籌款機制，但向大眾提供證券（股權）是大多數司法管轄區的受監管活動。通過將股權Token偽裝成實用Token，許多創業公司希望能夠繞過這些監管限制，並從公開募股籌集資金，同時將其作為預售的實用Token。這些稀薄的股權產品是否能夠擺脫監管機構仍有待觀察。

正如俗語所說：“如果它像鴨子一樣走路，像鴨子一樣嘎嘎叫 - 它就是一隻鴨子。” 監管機構不會因這些語義扭曲而分心，恰恰相反，他們更有可能將這種法律詭辯看作是企圖欺騙公眾。

[[who_needs_utility_Tokens]]
==== 實用Token：誰需要它們？

真正的問題是實用Token為初創公司帶來了重大風險和被採用障礙。也許在遙遠的將來，“將所有事物Token化”成為現實。但是，目前，獲得，理解和使用Token的人數是已經很小的密碼貨幣市場的一個子集。

對於創業公司而言，每項創新都代表著風險和市場過濾。創新走的是人跡罕至的路，遠離傳統的道路。它已經是一個孤獨的散步。如果一家創業公司試圖在一個新的技術領域進行創新，比如P2P網路上的儲存共享，那麼這是一條足夠孤單的道路。為該創新添加實用Token並要求用戶採用Token以使用該服務會增加風險並增加被採用的障礙。它走出了已然孤獨的P2P儲存創新之路，進入荒野。

將每項創新視為過濾器。它限制了可以成為這種創新的早期採用者的市場子集。添加第二個過濾器化合物，會進一步限制可找到的市場。你要求你的早期採用者採用的不僅僅是兩種全新的技術：你構建的新穎應用程式/平臺/服務以及Token經濟。

對於初創公司而言，每項創新都會帶來風險，從而增加創業失敗的可能性。如果你已經採取冒險的創業想法並添加實用Token，則也同時增加了所有底層平臺（以太坊），更廣泛的經濟（交易所，流動性），監管環境（股票/商品監管機構）和技術（智能合約，Token標準）的風險。這對創業公司來說是一個很大的風險。

“Tokenize all the things”的倡導者可能會通過採用Token來反對上述說法，他們也繼承了整個Token經濟的市場熱情，早期採用者，技術，創新和流動性。這也是事實。問題是收益和熱情是否超過風險和不確定性。

儘管如此，一些最具創新性的商業理念確實發生在加密領域。如果監管機構不能快速通過法律並支持新的商業模式，人才和企業家將尋求在更加加密友好的其他司法轄區開展業務。這實際上正在發生。

最後，在本章開始時，介紹Token時，我們將Token的口語意義解釋為“微不足道的價值”。大多數Token的價值微不足道的根本原因是因為它們只能用在非常狹窄的環境中：一家巴士公司，一家洗衣店，一家商場，一家酒店，一家公司商店。流動性有限，適用性有限，轉換成本高，一路降低Token的價值，直到它只有“Token”那麼小的價值。因此，當你將實用Token添加到你的平臺上，但該Token只能在你自己的一個平臺上使用且市場很小時，則會重新創建使物理Token毫無價值的條件。如果為了使用你的平臺，用戶必須將某些東西轉換為你的實用Token，使用它，然後將其餘部分再轉換回更普遍有用的東西，你實際是創建了公司憑證。數字Token的轉換成本比沒有市場的物理Token低了幾個數量級，但轉換成本並不是零。在整個行業中工作的實用Token將非常有趣並且可能非常有價值。但是，如果你將創業公司設定為必須引導整個行業標準才能成功，那麼你可能已經失敗了。

在像以太坊這樣的通用平臺上部署服務的好處之一就是能夠連接智能合約，增加流動性和Token效用的潛力。

為了正確的理由做出這個決定。採用Token是因為你的應用程式_不使用Token無法工作_ （例如以太坊）。採用它是因為Token解決了基本的市場障礙或訪問問題。不要因為這是你可以快速籌集資金的唯一方式而引入實用Token，你需要假裝它不是公開發行的證券。

[[Token_std]]
=== Token 標準

區塊鏈標記在以太坊之前就已存在。在某些方面，第一塊區塊鏈貨幣比特幣本身就是一種Token。在Ethereum之前，還在比特幣和其他密碼貨幣上開發了許多Token平臺。然而，在以太坊上引入第一個Token標準導致Token爆炸。

Vitalik Buterin建議將Token作為通用可編程區塊鏈（如以太坊）最明顯和最有用的應用之一。事實上，在以太坊的第一年，經常看到Vitalik和其他人穿著印有Ethereum標誌的T恤和背面的智能合約樣本。這件T恤有幾種變化，但最常見的是一種Token的實現。

[[ERC20_std]]
==== ERC20 Token 標準

第一個標準由Fabian Vogelsteller於2015年11月引入，作為以太坊徵求意見（ERC）。它被自動分配了GitHub發行號碼20，從而獲得了名字“ERC20 Token”。絕大多數Token目前都基於ERC20。ERC20徵求意見最終成為以太坊改進建議EIP20，但大多仍以原名ERC20提及。你可以在這裡閱讀標準：

https://github.com/ethereum/EIPs/blob/master/EIPS/eip-20.md

ERC20是_可替換Token_的標準，意味著ERC20標記的不同單元是可互換的，沒有唯一屬性。

ERC20標準為實現Token的合同定義了一個通用接口，這樣任何兼容的Token都可以以相同的方式訪問和使用。該接口包含許多必須存在於標準的每個實現中的函數，以及可能由開發人員添加的一些可選函數和屬性。

[[ERC20_reqd_func]]
===== ERC20 必須的函數和事件

totalSupply:: 返回當前存在的Token的總單位。ERC20Token可以有固定或可變的供應量。

balanceOf:: 給定一個地址，返回該地址的Token餘額。

transfer:: 給定一個地址和數量，將該數量的Tokens從執行該方法的地址的餘額轉移到該地址。

transferFrom:: 給定發送者，接收人和數量，將Token從一個帳戶轉移到另一個帳戶。與+approve+結合使用。

approve:: 在給定接收者地址和數量的情況下，授權該地址從發佈批准的帳戶執行多次轉帳，直到到達指定的數量。

allowance:: 給定一個所有者地址和一個消費者地址，返回該消費者被批准從所有者的取款的剩餘金額。

Transfer event:: 成功轉移時觸發的事件（調用+transfer+或+transferFrom+）（即使對於零值轉移）。

Approval event:: 成功調用+approve+時記錄的事件。

[[ERC20_optional_func]]
===== ERC20 可選函數

name:: 返回Token的可讀名稱（例如“US Dollars”）。

symbol:: 返回Token的人類可讀符號（例如“USD”）。

decimals:: 返回用於分割Token數量的小數位數。例如，如果小數為2，則將Token數除以100以獲取其用戶表示。

[[ERC20_interface]]
===== 在Solidity中定義的ERC20接口

以下是在Solidity中ERC20接口規範的樣子：

[[ERC20_interface_example]]

[[ERC20_data_struct]]
===== ERC20 資料結構

如果你檢查任何ERC20實現，它將包含兩個資料結構，一個用於追蹤餘額，另一個用於追蹤配額（allowances）。在Solidity中，它們使用_data mapping_實現。

第一個data mapping按擁有者實現了Token餘額的內部表。這允許Token合約跟蹤誰擁有Token。每次轉帳都是從一個餘額中扣除的，並且是對另一個餘額的增加。

[[balance_mapping]]
.Balances: a mapping from address (owner) to amount (balance)

第二個資料結構是配額的data mapping。正如我們將在<<transfer_workflows>>中看到的那樣，使用ERC20Token，Token的所有者可以將權限委託給花錢者，允許他們從所有者的餘額中花費特定金額（配額）。ERC20合同通過二維映射追蹤配額，主關鍵字是Token所有者的地址，映射到一個花費者地址和配額金額：

[[allowance_mapping]]
.Allowances: a mapping from address (owner) to address (spender) to amount (allowance)

[[transfer_workflows]]
===== ERC20工作流程：“transfer”和“approve & transferFrom”

ERC20Token標準具有兩種傳輸功能。你可能想知道為什麼？

ERC20允許兩種不同的工作流程。第一個是使用+transfer+函數的單次交易，簡單的工作流程。這個工作流程是錢包用來將Token發送給其他錢包的工作流程。絕大多數Token交易都發生在+transfer+工作流程中。

執行轉讓合同非常簡單。如果愛麗絲希望向鮑勃發送10個Token，她的錢包會向Token合約的地址發送一個交易，並用Bob的地址和“10”作為參數調用+transfer+函數。Token合約調整Alice的餘額（-10）和Bob的餘額（+10）併發出+Transfer+事件。

第二個工作流程是使用+approve+和+transferFrom+的雙交易工作流程。該工作流程允許Token所有者將其控制權委託給另一個地址。它通常用於委託控制權給合約來分配Token，但它也可以被交易所使用。例如，如果一家公司為ICO出售Token，他們可以+approve+一個crowdsale合同地址來分發一定數量的Token。然後crowdsale合同可以用+transferFrom+轉移給Token的每個買家。

((("Initial Coin Offerings (ICOs)","tokens and"))) 然後，眾包合約可以+從代幣合約所有者的餘額轉移到每個代幣買家，如圖所示 <<approve_transferFrom_workflow>>.
例如，如果一家公司為 ICO 出售代幣，他們可以+批准+一個眾包合約 (crowdsale contract) 地址來分發一定數量的代幣。


[NOTE]
====
((("Initial Coin Offerings (ICOs)","defined")))_Initial Coin Offering_（ICO）是一種眾籌機制，公司和組織通過銷售代幣來籌集資金。該術語源自首次公開發行（IPO），即上市公司向證券交易所的投資者出售股票之過程。與高度監管的IPO市場不同，ICO是開放的、全球化並且混亂的。 本書中 ICO 的例子和解釋並不是在為類籌款作背書。


====


[[approve_transferFrom_workflow]]
.The two-step approve & transferFrom workflow of ERC20 Tokens
image::images/approve_transferFrom_workflow.png["The two-step approve &amp; transferFrom workflow of ERC20 Tokens"]

對於 +approve & transferFrom+ 工作流程，需要兩個交易。假設Alice希望允許AliceICO合同將所有AliceCoin Token的50％賣給像Bob和Charlie這樣的買方。首先，Alice發佈AliceCoin ERC20合同，將所有AliceCoin發放到她自己的地址。然後，Alice發佈可以以ether出售Token的AliceICO合同。接下來，Alice啟動+approve & transferFrom+工作流程。她向AliceCoin發送一個交易，調用+approve+，參數是AliceICO的地址和+totalSupply+的50％。這將觸發+Approval+事件。現在，AliceICO合同可以出售AliceCoin了。

當AliceICO從Bob那收到ether，它需要發送一些AliceCoin給Bob作為回報。在AliceICO合約內是AliceCoin和ether之間的匯率。Alice在創建AliceICO時設置的匯率決定了Bob將根據他發送給AliceICO的ether數量能得到多少Token。當AliceICO調用AliceCoin +transferFrom+函數時，它將Alice的地址設置為發送者，將Bob的地址設置為接收者，並使用匯率來確定將在“value”欄位中將多少AliceCoin Token傳送給Bob。AliceCoin合同將餘額從Alice的地址轉移到Bob的地址並觸發 +Transfer+ 事件。只要不超過Alice設定的審批限制，AliceICO合同可以調用 +transferFrom+ 無限次數。AliceICO合同可以通過調用+allowance+函數來跟蹤它能賣出多少AliceCoinToken。


[[ERC20_implementation]]
===== ERC20 實現

雖然可以在約三十行Solidity程式碼中實現兼容ERC20的Token，但大多數實現都更加複雜，以解決潛在的安全漏洞。在EIP20標準中提到了兩種實現：

Consensys EIP20:: 簡單易讀的ERC20兼容Token的實現。

你可以在此處閱讀Consensys實現的Solidity程式碼：
https://github.com/ConsenSys/Tokens/blob/master/contracts/eip20/EIP20.sol

OpenZeppelin StandardToken:: 此實現與ERC20兼容，並具有額外的安全防範措施。它構成了OpenZeppelin庫的基礎，實現了更復雜的與ERC20兼容的Token，包括籌款上限，拍賣，歸屬時間表和其他功能。

你可以在這裡看到OpenZeppelin StandardToken的Solidity程式碼：
https://github.com/OpenZeppelin/zeppelin-solidity/blob/master/contracts/Token/ERC20/StandardToken.sol

[[METoken_example]]
==== 發佈我們自己的ERC20Token

讓我們創建併發布我們自己的Token。在這個例子中，我們將使用+truffle+ 框架（參見<<truffle>>）。該範例假設你已經安裝了+truffle+，進行了配置，並熟悉其基本操作。

我們將稱之為“Mastering Ethereum Token”，標誌為“MET”。

你可以在本書的GitHub倉庫中找到這個例子：
https://github.com/ethereumbook/ethereumbook/blob/develop/code/truffle/METoken

首先，讓我們創建並初始化一個Truffle項目目錄，就像我們在<<truffle_project_directory>>中所做的那樣。運行這四個命令並接受任何問題的預設答案：

[[initialize_truffle]]

你現在應該具有以下目錄結構：

[[truffle_directory]]

編輯+truffle.js+或+truffle-config.js+配置檔案以設置+Truffle+環境，或複製我們使用的環境：

https://github.com/ethereumbook/ethereumbook/blob/develop/code/truffle/METoken/truffle-config.js

如果使用範例+truffle-config.js+，請記住在包含你的測試私鑰的+METoken+檔案夾中創建檔案+.env+，以便在公共以太網測試網路（如ganache或Kovan）上進行測試和部署。你可以從MetaMask中匯出你的測試網路私鑰。

之後你的目錄看起來像：

[[truffle_directory]]

[WARNING]
====
只能使用不用於在以太坊主網路上持有資金的測試密鑰或測試助記符。切勿使用持有真正金錢的鑰匙進行測試。
====

對於我們的範例，我們將匯入OpenZeppelin StandardContract，它實現了一些重要的安全檢查並且易於擴展。讓我們匯入該庫：

[[install_openZeppelin]]

+ zeppelin-solidity +包將在+ node_modules +目錄下添加約250個檔案。OpenZeppelin庫包含的不僅僅是ERC20Token，但我們只使用它的一小部分。

接下來，讓我們編寫我們的Token合約。創建一個新檔案+METoken.sol+並從GitHub複製範例程式碼：

https://github.com/ethereumbook/ethereumbook/blob/develop/code/truffle/METoken/contracts/METoken.sol

我們的合同非常簡單，因為它繼承了OpenZeppelin StandardToken庫的所有功能：

[[solidity_Token_example]]
.METoken.sol : A Solidity contract implementing an ERC20 Token
[source,solidity,linenums]

在這裡，我們定義可選變數+name+，+symbol+和+decimals+。我們還定義了一個+_initial_supply+變數，設置為2,100萬個Token，以及兩個小數細分（總共21億）。在契約的初始化（構造函數）函數中，我們將+totalSupply+設置為等於+_initial_supply+，並將所有+_initial_supply+分配給創建 +METoken+ 契約的帳戶餘額（+msg.sender+）。

我們現在使用+truffle+編譯+METoken+程式碼：

[[truffle_compile]]

如你所見，+truffle+包含了OpenZeppelin庫的必要依賴關係，並編譯了這些契約。

我們建立一個migration腳本，部署 +METoken+合約。在+METoken/migrations+檔案夾中創建一個新檔案+2_deploy_contracts.js+。從Github儲存庫中的範例複製內容：

https://github.com/ethereumbook/ethereumbook/blob/develop/code/truffle/METoken/migrations/2_deploy_contracts.js

以下是它包含的內容：

[[METoken_migration]]
.2_deploy_contracts: Migration to deploy METoken
[source,javascript,linenums]

在我們部署其中一個以太坊測試網路之前，讓我們開始一個本地區塊鏈來測試一切。正如我們在<<using_ganache>>中所做的那樣，從 +ganache-cli+ 的命令行或從圖形用戶界面啟動 +ganache+ 區塊鏈。

一旦 +ganache+ 啟動，我們就可以部署我們的METoken合約，看看是否一切都按預期工作：

[[deploy_METoken]]

在+ganache+控制台上，我們應該看到我們的部署創建了4個新的交易：

[[ganache_METoken]]
.METoken deployment on Ganache
image::images/ganache_meToken.png["METoken deployment on Ganache"]

[[truffle_console]]
==== 使用Truffle控制台與METoken交互

我們可以使用+Truffle控制台+與我們的+ganache+區塊鏈合同進行互動。這是一個交互式的JavaScript環境，可以訪問Truffle環境，並通過Web3訪問區塊鏈。在這種情況下，我們將+Truffle控制台+連接到+ganache+區塊鏈：

[[interactive_truffle]]

 +truffle(ganache)>+ 提示符表明我們已連接到 +ganache+區塊鏈並準備輸入我們的命令。+Truffle控制台+支持所有的Truffle命令，所以我們可以從控制台+compile+和+migrate+。我們已經運行過這些命令，所以讓我們直接看看合同本身。METoken合約作為Truffle環境內的JavaScript物件存在。在提示符下鍵入+METoken+，它將轉儲整個合約定義：

[[get_METoken_definition]]

+METoken+物件還公開幾個屬性，例如合同的地址（由+migrate+命令部署）：

[[METoken_address]]

如果我們想要與已部署的合同進行交互，我們必須以JavaScript“promise”的形式使用異步調用。我們使用+deployment+函數來獲取合約實例，然後調用+totalSupply+函數：

[[METoken_async_call]]

接下來，讓我們使用由+ganache+創建的帳戶來檢查我們的METoken餘額並將一些METoken發送到另一個地址。首先，讓我們獲取帳戶地址：

[[get_account_addresses]]

+accounts+ 列表現在包含由+ganache+創建的所有帳戶，而+account[0]+是部署了該METoken合約的帳戶。它應該有METoken的餘額，因為我們的METoken構造函數將全部Token提供給了創建它的地址。讓我們檢查：

[[check_balance]]

最後，通過調用合約的 +transfer+函數，讓我們從+account[0]+ 向 +account[1]+ 轉移1000.00 METoken：

[[transfer_MET]]

[TIP]
====
METoken具有2位精度的小數，這意味著1個METoken在合同中是100個單位。當我們傳輸1000個METoken時，我們在傳輸函數中將該值指定為100,000。
====

如你所見，在控制台中，+ account [0] +現在擁有20,999,000 MET，+ account [1] +擁有1000 MET。

如果切換到+ganache+圖形用戶界面，你將看到名為+transfer+函數的交易：

[[ganache_METoken_transfer]]
.METoken transfer on Ganache
image::images/ganache_meToken_transfer.png["METoken transfer on Ganache"]

[[sending_erc20_Tokens_contracts]]
==== 將ERC20Token發送到合同地址

到目前為止，我們已經設置了ERC20Token並從一個帳戶轉移到另一個帳戶。我們用於這些示範的所有帳戶都是外部擁有帳戶（EOAs），這意味著它們由私鑰控制，而不是合同。如果我們將MET發送到合同地址會發生什麼？讓我們看看！

首先，我們將其他合約部署到我們的測試環境中。對於這個例子，我們將使用我們的第一個合同+Faucet.sol+。我們將它添加到METoken項目中，方法是將它複製到+contracts+目錄。我們的目錄應該是這樣的：

[[METoken_directory]]

我們還會添加一個migration，從+METoken+單獨部署+Faucet+：

[[faucet_migration]]

讓我們從Truffle控制台編譯和遷移合同：

[[faucet_deploy]]

現在讓我們將一些MET發送到 +Faucet+ 合約：

[[send_MET_faucet]]

好的，我們已將1000 MET轉移到 +Faucet+合約。現在，我們如何從 +Faucet+ 提款呢？

請記住，+Faucet.sol+是一個非常簡單的合同。它只有一個功能，+withdraw+，這是提取_ether_。它沒有提取MET或任何其他ERC20Token的功能。如果我們使用+withdraw+它將嘗試發送ether，但由於Faucet還沒有ether的餘額，它將失敗。

+METoken+合約知道+Faucet+有餘額，但它可以轉移該餘額的唯一方法是它從合約地址收到+transfer+調用。無論如何，我們需要讓+Faucet+ 合約調用+MET+中的+transfer+函數。

如果你在思考下一步該做什麼，不必了。這個問題沒有解決辦法。MET發送到+Faucet+將永遠卡住。只有+Faucet+合約可以轉讓它，+Faucet+合約沒有調用ERC20Token合約的+transfer+函數的程式碼。

也許你預料到了這個問題。最有可能的是，你沒有。實際上，數百名以太坊用戶也無意將各種Token轉讓給沒有任何ERC20能力的合同。據估計，價值超過250萬美元的Token被這樣“卡住”，並且永遠丟失。

ERC20Token的用戶可能無意中在轉移中丟失其Token的方式之一是當他們嘗試轉移到交易所或其他服務時。他們從交易所的網站上覆制以太坊地址，認為他們可以簡單地向其發送Token。但是，許多交易所都公佈實際上是合同的接收地址！這些合同具有許多不同的功能，通常將發送給他們的所有資金清掃到“冷儲存”或另一個集中的錢包。儘管有許多警告說“不要將Token發送到這個地址”，但許多Token會以這種方式丟失。

[[transfer_workflow_demo]]
==== 演示 approve & transferFrom 流程

我們的+Faucet+合同無法處理ERC20Token。使用+transfer+函數發送Token給它，會導致這些Token的丟失。我們重寫合同，並處理ERC20Token。具體來說，我們將把它變成一個Faucet，將MET發給任何詢問的人。

對於這個例子，我們製作了Truffle項目目錄的副本，將其稱為 +METoken_METFaucet+，初始化Truffle，npm，安裝OpenZeppelin依賴項並複製+METoken.sol+合同。有關詳細說明，請參閱我們的第一個範例<<METoken_example>>。

現在，讓我們創建一個新的Faucet合同，稱之為+METFaucet.sol+。它看起來像這樣：

[[METFaucet]]
.METFaucet.sol: a faucet for METoken
[source,solidity,linenums]

我們對基本的Faucet範例做了很多改動。由於METFaucet將使用+METoken+中的+transferFrom+函數，它將需要兩個額外的變數。其中一個將保存已部署的+METoken+合約地址。另一個將持有MET所有者的地址，他們將提供Faucet提款的批准。+METFaucet+將調用+METoken.transferFrom+並指示它將MET從所有者移至Faucet提取請求所來自的地址。


[[MET_owner_var]]
我們在這裡宣告這兩個變數：

由於我們的Faucet需要使用+METoken+和+METOwner+的正確地址進行初始化，因此我們需要宣告一個自定義構造函數：

[[custom_constructor]]

下一個改變是+withdraw+函數。+METFaucet+使用+METoken+中的+transferFrom+函數，並要求+METoken+將MET傳輸給Faucet的接收者，而不是調用+transfer+。

[[transfer_met]]

最後，由於我們的Faucet不再發送ether，我們應該阻止任何人將ether送到+METFaucet+，因為我們不希望它被卡住。我們更改fallback函數以拒絕發進來的ether，使用+revert+功能還原任何收款：

[[reject_incoming_eth]]

現在我們的+METFaucet.sol+程式碼已準備就緒，我們需要修改migration腳本來部署它。這個migration腳本會有點複雜，因為+METFaucet+依賴於+METoken+的地址。我們將使用JavaScript promise按順序部署這兩個合約。創建+2_deply_contracts.js+，如下所示：

[[2_deploy_contracts]]

現在，我們可以測試Truffle控制台中的所有內容。首先，我們使用+migrate+來部署合同。當+METoken+部署時，它會將所有MET分配給創建它的帳戶，+web3.eth.accounts[0]+。然後，我們在METoken中調用+approve+函數來批准+METFaucet+代表+web3.eth.accounts[0]+發送1000 MET。最後，為了測試我們的Faucet，我們從+web3.eth.accounts[1]+調用+METFaucet.withdraw+並嘗試提取10個MET。以下是控制台命令：

[[ERC20_gananche_test]]

從結果中可以看出，我們可以使用 +approve+ and +transferFrom+ 工作流來授權一個合約轉移另一個Token中定義的Token。如果使用得當，ERC20Token可以由EOA和其他合同使用。

但是，正確管理ERC20Token的負擔會推送到用戶界面。如果用戶錯誤地嘗試將ERC20Token轉移到合同地址，並且該合同沒有配備接收ERC20Token的功能，則Token將丟失。

[[ERC20_issues]]
==== ERC20Token的問題

ERC20Token標準的採用確實是爆炸性的。成千上萬的Token已經啟動，既可以嘗試新的功能，也可以通過各種“眾籌”拍賣和初始投幣產品（ICO）籌集資金。然而，正如我們在將Token轉移到合同地址的問題所看到的那樣，存在一些潛在的陷阱。

ERC20Token不太明顯的問題之一是它們暴露了Token和ether本身之間的細微差別。如果ether通過以接收者地址為目的地的交易轉移，則Token轉移發生在 _specific Token contract state_ 中，並且將Token合同作為其目的地，而不是接收者的地址。Token合同跟蹤餘額併發布事件。在Token傳輸中，實際上沒有交易發送給Token的接收者。相反，接收者的地址將被添加到Token合約本身的映射中。將ether發送到地址的交易會改變地址的狀態。將Token轉移到地址的交易只會改變Token合約的狀態，而不會改變接收者地址的狀態。即使是支持ERC20Token的錢包，也不會意識到Token的餘額，除非用戶明確將特定Token合約添加到“監視”中。一些錢包觀察最受歡迎的Token合約，以檢測由他們控制的地址持有的餘額，但這僅限於ERC20合同的一小部分。

事實上，用戶不太可能會追蹤所有可能的ERC20Token合約中的所有餘額。許多ERC20Token更像是垃圾郵件，而不是可用的Token。他們自動為擁有ether活動的帳戶創建餘額，以吸引用戶。如果你有一個活動歷史悠久的以太坊地址，特別是如果它是在預售中創建的，你會發現它充滿了憑空出現的“垃圾”Tokens。當然，這個地址並不是真的充滿了Token，而是那些Token合約有你的地址。如果你用於查看地址的資源管理器或錢包正在監視這些Token合約，才能看到這些餘額。

Token不像ether。Ether通過+send+功能發送，並由合同中的任何payable函數或任何EOA接受。Token僅使用在ERC20合同中存在的+transfer+ 或+approve＆transferFrom+函數發送，並且不會（至少在ERC20中）觸發收款合同中的任何payable函數。Token的功能就像ether這樣的密碼貨幣，但它們帶有一些細微的區別，可以打破這種錯覺。

考慮另一個問題。要發送ether，或使用任何以太坊合同，你需要ether來支付gas。發送Token，你_也需要ether_。你無法用Token支付交易的gas，而Token合同也無法為你支付gas費用。這可能會導致一些相當奇怪的用戶體驗。例如，假設你使用交易所或Shapeshift將某些比特幣轉換為Token。你在錢包中“收到”該Token，該錢包會跟蹤該Token的合同並顯示你的餘額。它看起來與你錢包中的任何其他密碼貨幣相同。現在嘗試發送Token，你的錢包會通知你，你需要ether才能這樣做。你可能會感到困惑 - 畢竟你不需要ether接收Token。也許你沒有ether。也許你甚至不知道該Token是以太坊上的ERC20Token，也許你認為這是一個擁有自己的區塊鏈的密碼貨幣。錯覺就這樣被打破了。

其中一些問題是ERC20Token特有的。其他更一般的問題涉及到以太坊內的抽象和界面邊界。有些可以通過更改Token接口來解決，其他可能需要更改以太坊內的基礎結構（例如EOAs和合同之間以及交易和消息之間的區別）。有些可能不完全“可解決”，並且可能需要用戶界面設計來隱藏細微差別並使用戶體驗一致，而不管其底層區別如何。

在接下來的部分中，我們將看看試圖解決其中一些問題的各種提案。

[[ERC223_std]]
==== ERC223 - 一種建議的Token合同接口標準

ERC223提案試圖通過檢測目的地地址是否是合同來解決無意中將Token轉移到合同（可能支持或不支持Token）的問題。ERC223要求用於接受Token的契約實現名為+TokenFallback+的函數。如果傳輸的目的地是合同並且合同不支持Token（即不實現+TokenFallback+），則傳輸失敗。


[[is_contract]]
為了檢測目標地址是否為契約，ERC223參考實現使用了一小段內聯 Bytecode ，並採用了一種頗具創造性的方式：

你可以在這裡看到有關ERC223提案的討論：

https://github.com/ethereum/EIPs/issues/223

[[ERC223_interface]]
ERC223合同接口規範是：

[source,solidity]

ERC223沒有得到廣泛的實施，ERC討論中有一些關於向前兼容性和在合同接口級別或用戶界面上實現更改之間的折衷的爭論。爭論仍在繼續。

==== ERC777 - 一種建議的Token合同接口標準

另一項改進Token合同標準的提案是ERC777。該提案有幾個目標，包括：

* 提供ERC20兼容性界面
* 使用+send+功能傳輸Token，類似於ether傳輸
* 與ERC820兼容Token合同註冊
* 合同和地址可以通過在發送之前調用+TokensToSend+函數來控制它們發送的Token
* 通過在接收者中調用+TokensReceived+函數來通知合同和地址
* Token傳輸交易包含 +userData+ 和 +operatorData+ 欄位中的元數據
* 無論是發送到合同還是EOA，都以相同的方式運作

有關ERC777的詳細資訊和正在進行的討論可以在這裡找到：

https://github.com/ethereum/EIPs/issues/777

[[ERC777_interface]]
ERC777合同接口規範是：

[source,solidity]

ERC777的參考實現與提案相關聯。ERC777依賴於ERC820中關於註冊合同的並行提案。關於ERC777的一些爭論是關於同時採用兩個大變化的複雜性：一個新的Token標準和一個註冊標準。討論仍在繼續。

==== ERC721 - 不可替代的Token（契據）標準

我們目前看到的所有Token標準都是_可互換_Token，這意味著Token的每個單元都是完全可以互換的。ERC20Token標準僅跟蹤每個帳戶的最終餘額，並且（明確地）跟蹤任何Token的出處。

ERC721提案是_不可互換的_ Tokens標準，也稱為_契據_ _deeds_。

牛津詞典：

    契約：簽署和交付的法律檔案，尤其是關於財產或合法權利所有權的法律檔案。

契約一詞的使用旨在反映“財產所有權”部分，即使這些部分在任何司法管轄區都不被承認為“法律檔案”，至少目前不是。

不可互換的Token追蹤獨特事物的所有權。擁有的東西可以是數字項目，例如遊戲物品或數字收藏品。或者，這種東西可以是物理事物，其物主通過Token進行跟蹤，例如房屋，汽車，藝術品等。契約也可以代表負值的東西，例如貸款（債務），留置權，地役權等。ERC721標準對所有權由契約追蹤的事物的性質沒有限制或期望，只是它可以是唯一標識，在這個標準的情況下是由256位識別碼實現的。

標準和討論的細節在兩個不同的GitHub位置進行跟蹤：

初步建議：
https://github.com/ethereum/EIPs/issues/721

繼續討論：
https://github.com/ethereum/EIPs/pull/841

[[map_deed_owner]]
要掌握ERC20和ERC721之間的基本差異，只需查看ERC721中使用的內部資料結構即可：

[source,solidity]

ERC20跟蹤屬於每個所有者的餘額，所有者是映射的主鍵，ERC721跟蹤每個契約ID以及誰擁有它，契約ID是映射的主鍵。從這個基本差異衍生出不可替代的Token的所有屬性。

[[ERC721_interface]]
ERC721 合同接口規範是：


[source,solidity]

ERC721還支持兩個_*可選*_接口，一個用於元數據，一個用於枚舉契約和所有者。

[[ERC721_metadata]]
用於元數據的ERC721可選接口是：

[source,solidity]

[[ERC721_enum]]
用於枚舉的ERC721可選接口是：

[source,solidity]

[[Token_std_review]]
=== Token標準

在本節中，我們回顧幾個建議的標準和幾個廣泛部署的Token合約標準。這些標準究竟做了什麼？你應該使用這些標準嗎？你應該如何使用它們？你應該添加超出這些標準的功能嗎？你應該使用哪些標準？接下來我們將研究所有這些問題。

[[Token_std_purpose]]
==== 什麼是Token標準？他們的目的是什麼？

Token標準是實現的_最小_規範。這意味著為了符合ERC20的要求，你至少需要實施ERC20規定的功能和行為。你還可以通過實現不屬於標準的功能來自由添加功能。

這些標準的主要目的是鼓勵合同之間的互用性。因此，所有錢包，交易所，用戶界面和其他基礎設施組件都可以以可預見的方式與任何遵循規範的合同進行交流。

標準的目的是 _描述性的_ _descriptive_，而不是_規定性的_ _prescriptive_。你如何選擇實現這些功能取決於你 - 合同的內部功能與標準無關。它們有一些功能要求，它們管理特定情況下的行為，但它們沒有規定實現。例如，如果值設置為零，則傳遞函數的行為。

[[should_use_std]]
==== 你應該使用這些標準嗎？

鑑於所有這些標準，每個開發人員都面臨兩難選擇：使用現有標準還是創新超出他們施加的限制？

這種困境並不容易解決。標準必然會限制你的創新能力，創造一個你必須遵循的狹窄“車轍”。另一方面，基本標準來自數百個應用程式的經驗，並且通常與99％的用例非常吻合。

作為這一考慮的一部分，還有一個更大的問題：互操作性和廣泛採用的價值。如果你選擇使用現有標準，你將獲得設計用於該標準的所有系統的價值。如果你選擇偏離標準，則必須考慮自己構建所有基礎架構的成本，或者說服其他人支持你新標準的實施。建立自己的道路並忽視現有標準的傾向被稱為“Not Invented Here”，並且與開源文化相對立。另一方面，進步和創新有時依靠背離傳統。這是一個棘手的選擇，所以仔細考慮吧！

.維基百科“Not Invented Here”（https://en.wikipedia.org/wiki/Not_invented_here）

  Not Invented Here是由社會，企業或機構文化採取的立場，由於其外部起源和成本（如版稅），避免使用或購買已有產品，研究，標準或知識。

[[security_maturity]]
=== 安全成熟度

除了標準的選擇之外，還有_implementation_的並行選擇。當你決定使用標準（如ERC20）時，你必須決定如何實施兼容Token。以太坊生態系統中廣泛使用了一些現有的“參考”實現。或者你可以從頭開始寫你自己的。再次，這個選擇代表了一個可能產生嚴重安全隱患的困境。

現有的實施是“戰鬥測試”。雖然不可能證明它們是安全的，但其中許多都支持數百萬美元的Token。他們一再受到攻擊，並且受到了強烈的攻擊。到目前為止，沒有發現重大的漏洞。寫你自己的並不容易 - 有許多微妙的方式可以讓合約受到損害。使用經過充分測試的廣泛使用的實現更加安全。在我們上面的例子中，我們使用了ERC20標準的OpenZeppelin實現，因為這個實現從頭到尾都是安全的。

如果你使用現有的實現，你也可以擴展它。再次小心這種衝動。複雜性是安全的敵人。你添加的每一行程式碼都會擴展合約的_受攻擊面_，並可能代表處於等待狀態的漏洞。你可能沒有注意到一個問題，直到你在合同上投入了很多價值並且有人打破了它。

[[extend_Token_interface]]
=== Token接口標準的擴展

本節中討論的Token標準以非常小的接口開始，功能有限。許多項目已經創建了擴展實現，以支持他們的應用程式所需的功能。其中一些包括：

所有者控制:: 特定地址或一組地址（多重簽名）具有特殊功能，例如黑名單，白名單，鑄造，恢復等。

燃燒:: Token燃燒是指Token被轉移到不可靠的地址或刪除餘額並減少供應時故意銷燬。

Minting:: 以可預測的速率添加Token的總供應量的能力，或通過Token創建者的“命令”添加的能力。

Crowdfunding:: 提供Token銷售的能力，例如通過拍賣，市場銷售，反向拍賣等。

上限:: 總供給的預定義和不可改變的限制，與“minting”功能相反。

恢復“後門”:: 恢復資金，反向傳輸或拆除由指定地址或一組地址激活的Token（多重簽名）的功能。

白名單:: 限制Token傳輸僅限於列出的地址的功能。在經過不同司法管轄區的規則審核後，最常用於向“經認可的投資者”提供Token。通常有一種更新白名單的機制。

黑名單:: 通過禁止特定地址來限制Token傳輸的能力。通常有更新黑名單的功能。

在OpenZeppelin庫中有許多這些功能的參考實現。其中一些是面向特定用例的，僅在少數Token中實現。到目前為止，這些功能的接口還沒有被廣泛接受的標準。

如前所述，擴展具有附加功能的Token標準的決定代表了創新/風險與互操作性/安全性之間的權衡。

[[Tokens_ico]]
=== Tokens 和 ICOs

Token已經成為以太坊生態系統中的爆炸性發展。它們可能是所有智能合約平臺（如以太坊）中非常重要的基礎組件。

儘管如此，這些標準的重要性和未來影響不應該與當前Token產品的認可相混淆。就像在任何早期階段的技術一樣，第一波產品和公司幾乎都會失敗。今天在Ethereum上提供的許多Token幾乎都是偽裝的騙局，傳銷和金錢爭奪。

訣竅是將這種技術的長期願景和影響與可能非常大的Token ICO的短期泡沫區分開來，這種泡沫充斥著欺詐行為。兩者在同一時間都可以是真實的。Token標準和平臺將在目前的Token狂熱中倖存下來，然後他們可能會改變世界。
[[decentralized_applications_chap]]
== 去中心化應用 (DApps)

點對點（P2P，peer-to-peer）運動使數百萬互聯網用戶能夠連接在一起。USENET是被稱為第一個點對點架構的一種分佈式消息傳遞系統，它於1979年成立，是第一個“互聯網”ARPANET的繼承者。ARPANET是一個客戶端 - 伺服器網路，參與者運行節點請求和提供內容，但由於除了簡單的基於地址的路由，缺乏提供任何上下文的能力，USENET很有希望實施一個分散的控制模型，即客戶端 - 伺服器模型，分別從用戶或客戶角度為新聞組伺服器提供自組織方法。

1999年，著名的音樂和檔案共享應用程式Napster出現了。Napster是點對點網路運動演變為BitTorrent的開始，參與用戶建立了一個虛擬網路，完全獨立於物理網路，無需遵守任何管理機構或限制。

由於點對點機制可用於訪問任何類型的分佈式資源，因此它們在去中心化應用程式中起著核心作用。

[[what_is_a_dapp_sec]]
=== 什麼是DApp？

與傳統應用程式不同，去中心化應用（DApp）不僅屬於單個提供者或伺服器，而是整個棧將在P2P網路上以分佈式方式部署和操作。

典型的DApp棧包括前端，後端和數據儲存。創建DApp有許多優點，典型集中式架構無法提供：

1）彈性：在智能合約上編寫業務邏輯意味著DApp後端將在區塊鏈上完全分發和管理。與在中央伺服器上部署應用程式不同，DApp不會有停機時間，只要區塊鏈仍在運行，它就會繼續存在。

2）透明性：DApp的開源特性允許任何人分叉程式碼並在區塊鏈上運行相同的應用程式。同樣，任何與區塊鏈的互動都將永久儲存，任何擁有區塊鏈副本的人都可以獲得對它的訪問權限。值得注意的是，可能無法將 Bytecode 反編譯為源碼並完全理解合約的程式碼。尋求提供合約行為完全透明的開發人員必須發佈供用戶閱讀，編譯和驗證的源程式碼。

3）抗審查：只要用戶可以訪問以太坊節點，用戶將始終能夠與DApp交互而不受集中機構控制的干擾。一旦在網路上部署程式碼，任何服務提供商，甚至智能合約的所有者都不能更改程式碼。

[[components_of_a_dapp_sec]]
=== DApp的組件

[[blockchain_smart_contracts_sec]]
==== 區塊鏈（智能合約）

智能合約用於儲存去中心化應用程式的業務邏輯，狀態和計算; 將智能合約視為常規應用程式中的伺服器端組件。

在以太坊智能合約上部署伺服器端邏輯的一個優點是，你可以構建一個更復雜的架構，智能合約可以在其中相互讀取和寫入數據。部署智能合約後，未來許多其他開發人員都可以使用你的業務邏輯，而無需你管理和維護程式碼。

將智能合約作為核心業務邏輯功能運行的一個主要問題是在部署程式碼後無法更改程式碼。此外，一個非常龐大的智能合約可能需要耗費大量gas來部署和運行。因此，某些應用程式可能會選擇離線計算和外部數據源。請記住，DApp的核心業務邏輯依賴於外部數據或伺服器意味著你的用戶必須信任這些外部事物。

[[front_end_web_ui_cec]]
==== 前端（Web用戶界面(UI)）

與DApp的業務邏輯需要開發人員瞭解EVM和新語言（如Solidity）不同，DApp的客戶端界面使用基本的Web前端技術（HTML，CSS，JavaScript）。這允許傳統的Web開發人員使用他們熟悉的工具，庫和框架。與DApp的交互（例如簽名消息，發送交易和密鑰管理）通常通過瀏覽器本身使用Mist瀏覽器或Metamask瀏覽器擴展等工具進行。

雖然也可以創建行動DApp，但由於缺少可用作具有密鑰管理功能的輕客戶端的行動客戶端，目前沒有創建行動DApp前端的最佳實踐。

[[data_storage_sec]]
==== 數據儲存

由於gas成本高，智能合約目前不適合儲存大量數據。因此，大多數DApps將利用去中心化儲存（如IPFS或Swarm）來儲存和分發大型靜態資產，如圖像，視頻和客戶端應用程式（HTML，CSS，JavaScript）。

內容的雜湊值通常使用鍵值映射儲存為智能合約中的字節。然後，通過你的前端應用程式調用智能合約查詢資產，以獲取每個資產的URL。

[[on_chain_vs_off_chain_data_sec]]
===== 上鏈 vs. 脫鏈

////
TODO
////

[[ipfs_sec]]
===== IPFS

////
TODO
////

[[swarm_sec]]
===== Swarm

Swarm主頁: http://swarm-gateways.net/bzz:/theswarm.eth/

閱讀文件: https://swarm-guide.readthedocs.io/en/latest/index.html

Swarm開發人員的入門指南: https://github.com/ethersphere/swarm/wiki/swarm

Swarm討論組: https://gitter.im/ethersphere/orange-lounge

Ethereum's Swarm 和 IPFS 的相似之處與不同之處; https://github.com/ethersphere/go-ethereum/wiki/IPFS-&-SWARM

[[centralized_db_sec]]
===== 中心化數據

集中式資料庫是伺服器上的數據儲存，其特徵與描述相關聯。它們使用客戶端 - 伺服器網路架構，這允許客戶端或用戶修改儲存在集中式伺服器上的數據。資料庫的控制權仍由指定的管理員進行，管理員在提供對資料庫的訪問之前對客戶端的憑據進行身份驗證。如果管理員的安全性受到損害，則可以更改甚至刪除數據，因為管理員是唯一負責管理資料庫的人。

[[dapp_frameworks_sec]]
=== DApp框架

有許多不同的開發框架和庫，以多種語言編寫，使得開發人員可以在創建和部署DApp時獲得更好的體驗。

[[truffle_sec]]
==== Truffle

Truffle是一種流行的選擇，為以太坊提供可管理的開發環境，測試框架和資產管道。

有了Truffle，你會得到：

* 內建智能合約編譯，鏈接，部署和二進制管理。
* 與Mocha和Chai進行自動合約測試。
* 可配置的構建管道，支持自定義構建過程。
* 可編寫腳本的部署和遷移框架。
* 用於部署到許多公共和專用網路的網路管理。
* 直接與合約溝通的交互式控制台。
* 在開發過程中即時重建資產。
* 在Truffle環境中執行腳本的外部腳本運行器。

入門和文件：http://truffleframework.com/docs

Github：https://github.com/trufflesuite/truffle

Website：https://truffleframework.com

[[embark_sec]]
==== Embark Embark框架專注於使用以太坊，IPFS和其他平臺的無伺服器去中心化應用。Embark目前與EVM區塊鏈（Ethereum），去中心化儲存（IPFS）和去中心化通信平臺（Whisper和Orbit）集成。

** 區塊鏈（以太坊）
* 自動部署合約並使其在JS程式碼中可用。啟動監視更改，如果你更新合約，Embark將自動重新部署合約（如果需要）和DApp。
* JS通過Promises使用合約。
* 使用Javascript與合約進行測試驅動開發。
* 跟蹤已部署的合約; 只在真正需要時部署。
* 管理不同的鏈（例如，測試網，私人網，livenet）
* 輕鬆管理相互依賴合約的複雜系統。

** 去中心化儲存（IPFS）
* 通過EmbarkJS輕鬆儲存和查詢DApp上的數據，包括上傳和查詢檔案。
* 將完整的應用程式部署到IPFS或Swarm。

** 去中心化通信 (Whisper, Orbit)
* 通過Whisper或Orbit輕鬆通過P2P渠道發送/接收消息。

** 網路技術
* 與任何網路技術集成，包括React，Foundation等。
* 使用你想要的任何構建管道或工具，包括grunt，gulp和webpack。

入門和文件：https://embark.readthedocs.io

Github：https://github.com/embark-framework/embark

Website：https://github.com/embark-framework/embark

==== Emerald

Emerald Platform 是一個框架和工具集，用於簡化Dapps的開發以及現有服務與基於以太坊的區塊鏈的集成。

Emerald提供：

* Javascript庫和React組件構建Dapp
* 區塊鏈項目常見的SVG圖示
* 用於管理私鑰的Rust庫，包括硬體錢包和簽名交易
* 可以集成到現有app命令行或JSON RPC API中的現成的組件和服務
* SputnikVM，一個獨立的EVM實現，可用於開發和測試

它與平臺無關，為各種目標提供工具：

* 與Electron捆綁的桌面應用程式
* 行動應用程式
* 網路應用程式
* 命令行應用程式和腳本工具

入門和文件：https://docs.etcdevteam.com

Github：https://github.com/etcdevteam/emerald-platform

Website：https://emeraldplatform.io

[[dapp_develotment_tool_sec]
==== DApp（開發工具）
DApp是一個用於智能合約開發的簡單命令行工具。它支持以下常見用例：

* 包管理
* 源程式碼構建
* 單元測試
* 簡單的合約部署

入門和文件：https://dapp.readthedocs.io/en/latest/

[[live_dapps_sec]]
=== 活躍的DApps

以下列出了以太坊網路上的活躍DApp：

[[ethpm_sec]]
==== EthPM
一個旨在將包管理帶入以太坊生態系統的項目。

Website：https://www.ethpm.com/

[[radar_relay_sec]]
==== Radar Relay
DEX（去中心化交易所）專注於直接從錢包到錢包交易基於以太坊的tokens。

Website：https://radarrelay.com/

[[cryptokitties_sec]]
==== CryptoKitties
在以太坊上部署的遊戲，允許玩家購買，收集，繁殖和銷售各種類型的虛擬貓
它代表了為休閒和悠閒目的部署區塊鏈技術的最早嘗試之一。

Website：https://www.cryptokitties.co

[[ethlance_sec]]
==== Ethlance
Ethlance是一個連接自由職業者和開發者的平臺，用ether支付和收款。

Website：https://ethlance.com/

[[decentraland_sec]]
==== Decentraland
Decentraland是以太坊區塊鏈支持的虛擬現實平臺。用戶可以創建，體驗內容和應用程式並從中獲利。

Website：https://decentraland.org/
[[oracles_chap]]
== 預言機 (Oracles)

在本章中，我們將討論預言機 oracles，它是可以為以太坊智能合約提供外部數據源的系統。華人區塊鏈裡翻譯 oracle 為預言機；“神諭” Oracle一詞來自希臘神話，它提到了一個與神靈交流的人，他們可以看到未來的願景。 在區塊鏈的上下文中，oracle 是一個回答問題的系統，它可以回答來自於以太坊之外問題。 理想情況下，oracles 是不可靠 (trustless) 的系統，按造中心化原則 (decentralized)，這意味著它們不需要被信任。

=== 為什麼預言機是剛需

以太坊平台中的一個關鍵元件是以太坊虛擬機，這虛擬機能夠執行程式，並且在共識算法的規則約束中，能夠在去中心化網路中的任何一節點上更新乙太坊的狀態。為了保持共識，EVM 的執行必須是完全有確定性的 (deterministic)，並且該執行只能基於乙太坊狀態以及簽名交易的共享執行脈落進行。這有兩個特別重要的後果：第一個是 EVM 和智能合約沒有任何內在的隨機性來源；第二，外部之數據僅能以交易中資料封包 (data payload) 的方式來進入。

讓我們進一步分析這兩種後果。要了解在 EVM 中禁止使用真正的隨機函數為智能合約提供隨機性，請考慮執行此類功能後對達成共識的嘗試的影響：節點A將執行命令並代表智能合約存儲 3 在其存儲中，執行相同智能合約的節點B會存儲 7。因此，儘管在相同的上下文中運行了完全相同的代碼，但節點A和B將得出關於結果狀態應該是什麼的不同結論。確實，每次評估智能合約時，都有可能獲得不同的結果狀態。這樣一來，網絡由於其眾多節點在世界各地獨立運行，將無法就結果狀態應達成分散式共識。在實踐中，它將很快變得比本示例差很多，因為包括醚轉移在內的連鎖效應將成倍增加。

注意，偽隨機函數，例如加密安全散列函數（它們是確定性的，因此可以是，實際上是EVM的一部分），對於許多應用來說是不夠的。 採取模擬硬幣翻轉的賭博遊戲來解決投注支出，這需要隨機化頭部或尾部 - 礦工可以通過玩遊戲獲得優勢，並且僅包括他們將贏得的區塊中的交易。 那麼我們如何解決這個問題呢？ 那麼，所有節點都可以就簽名交易的內容達成一致，因此可以引入外部信息，包括隨機性，價格信息，天氣預報等，作為發送到網絡的交易的數據部分。 但是，這些數據根本無法信任，因為它來自無法核實的來源。 因此，我們剛剛推遲了這個問題。 我們使用oracles嘗試解決這些問題，我們將在本章的其餘部分詳細討論這些問題。

=== 預言機的使用例子 (Use Case) 及範例

理想情況下，神諭提供了一種無信任（或至少近乎無信任）的方式來獲取外在的（即“真實世界”或鏈下"off-chain"）信息，例如足球比賽的結果，黃金的價格，或真正的隨機數字，在以太坊平台上使用智能合約。它們還可用於直接將數據安全地中繼到 DApp 前端。因此，可以將神諭視為彌合脫軌世界與智能合約之間差距的機制。允許智能合約基於真實世界的事件和數據來強制執行合同關係，從而大大擴展了它們的範圍。但是，這也會給以太坊的安全模型帶來外部風險。考慮一個“聰明意志”合同，當一個人去世時分配資產。這是智能合約空間中經常討論的內容，並突出了可信任的oracle的風險。如果由這樣的合同控制的繼承金額足夠高，那麼在所有者死亡之前攻擊oracle並觸發資產分配的動機是非常高的。

請注意，某些oracles提供特定於特定私有數據源的數據，例如學術證書或政府ID。 這些數據的來源，如大學或政府部門，是完全可信的，數據的真實性是主觀的（真相只能通過訴諸來源的權威來確定）。 因此，不能無信地提供這樣的數據 - 即，不信任來源 - 因為沒有獨立可驗證的客觀事實。 因此，我們將這些數據源包含在我們對“神諭”的定義中，因為它們還為智能合約提供了數據橋樑。 他們提供的數據通常採用證明的形式，如護照或成就記錄。 考試將成為未來區塊鏈平台成功的重要組成部分，特別是在驗證身份或聲譽的相關問題方面，因此探索區塊鏈平台如何為其提供服務非常重要。

可能由oracles提供的更多數據示例包括：

* 來自物理來源的隨機數/熵（例如量子/熱現象）：公平地選擇彩票智能合約中的贏家
* 與自然災害相關的參數觸發器：觸發巨災債券智能合約（對於颶風債券來說的風速）
* 匯率數據：將穩定幣與法定貨幣準確掛鉤
* 資本市場數據：代幣化資產/證券的定價籃子
* 基準參考數據：將利率納入智能金融衍生品
* 靜態/僞靜態數據：安全識別碼，國家/地區程式碼，貨幣程式碼
* 時間和間隔數據：事件觸發器以精確的SI時間測量爲基礎
* 天氣數據：基於天氣預報的保險費計算
* 政治事件：預測市場決議
* 體育賽事：預測市場決議和幻想體育合約
* 地理位置數據：供應鏈跟蹤
* 損害賠償：保險合約
* 其他區塊鏈上發生的事件：互操作函數
* 交易天然氣價格：gas價格oracles
* 航班延誤：保險合約

在本節中，我們將在Solidity中檢查oracles的主要功能，oracle訂閱模式，計算oracles，去中心化的oracles和oracle客戶端實現。

[[primary_functions_sec]]
=== 主要功能

實際上，oracle可以實現爲鏈上智能合約系統和用於監控請求，查詢和返回數據的離線基礎設施。來自去中心化應用的數據請求通常是涉及許多步驟的異步過程。

首先，外部擁有帳戶將與去中心化應用進行交易，從而與oracle智能合約中定義的函數進行交互。此函數初始化對oracle的請求，除了可能包含回調函數和調度參數的補充資訊之外，還使用相關參數詳細說明所請求的數據。一旦驗證了此事務，就可以將oracle請求視爲oracle合約發出的EVM事件，或者狀態更改； 參數可以被取出並用於從脫鏈數據源執行實際查詢。oracle可能需要處理請求的費用，回調的gas費用，以及訪問所請求數據的權限/權限。最後，結果數據由oracle所有者簽署，基本上證明在給定時間數據的價值，並在交易中交付給作出請求的去中心化應用 - 直接或通過oracle合約。根據調度參數，oracle可以定期廣播進一步更新數據的事務，例如日終定價資訊。

可能有一系列替代方案。可以從外部擁有帳戶請求數據並直接返回數據，從而無需使用oracle智能合約。類似地，可以向物聯網啓用的硬體傳感器發出請求和響應。因此，oracles可以是人類，軟體或基於硬體的。

oracle的主要功能可概括如下：

* 迴應去中心化應用的查詢
* 解析查詢
* 檢查是否符合付款和數據權限/權利義務
* 從脫鏈源查詢數據
* 在交易中籤署數據
* 向網路廣播交易
* 進一步安排交易

[[subscription_paterns_sec]]
=== 訂閱模式

上述訂閱模式是典型的請求——響應模式，常見於客戶端——伺服器體系結構中。雖然這是一種有用的消息傳遞模式，允許應用程式進行雙向對話，但它是一種相對簡單的模式，在某些條件下可能不合適。例如，需要oracle提供利率的智能債券可能需要在請求-響應模式下每天請求數據，以確保利率始終是正確的。鑑於利率不經常變化，發佈——訂閱模式在這裏可能更合適，尤其是考慮到以太坊的有限帶寬。

發佈——訂閱是一種模式，其中發佈者，這裏是oracles，不直接向接收者發送消息，而是將發佈的消息分到不同的類中。訂閱者能夠表達對一個或多個類的興趣並僅查詢那些感興趣的消息。在這種模式下，oracle可以將利率寫入其自己的內部儲存，當且僅當它發生變化時。多個訂閱的去中心化應用可以簡單地從oracle合約中讀取它，從而減少對網路帶寬的影響，同時最大限度地降低儲存成本。

在廣播或多播模式中，oracle會將所有消息發佈到一個頻道，訂閱合約將在各種訂閱模式下收聽該頻道。例如，oracle可能會將消息發佈到密碼貨幣匯率通道。訂閱智能合約如果需要時間序列，例如移動平均計算，則可以請求信道的全部內容; 另一個可能只需要最後一個價格來計算現貨價格。在oracle不需要知道訂閱合約的身份的情況下，廣播模式是合適的。

[[data_authentication_sec]]
=== 數據認證

如果我們假設去中心化應用查詢的數據源既具有權威性又值得信賴，那麼一個懸而未決的問題仍然存在：假設oracle和查詢/響應機制可能由不同的實體操作，我們如何才能信任這種機制？數據在傳輸過程中可能會被篡改，因此脫鏈方法能夠證明返回數據的完整性至關重要。數據認證的兩種常用方法是真實性證明和可信執行環境（TEE）。

真實性證明是加密保證，證明數據未被篡改。基於各種證明技術（例如，數位簽章證明），它們有效地將信任從數據載體轉移到證明者，即證明方法的提供者。通過在鏈上驗證真實性，智能合約能夠在對其進行操作之前驗證數據的完整性。Oraclize[1]是利用各種真實性證明的oracle服務的一個例子。目前可用於以太坊主網路的數據查詢是TLSNotary Proof [2]。TLSNotary Proofs允許客戶端向第三方提供客戶端和伺服器之間發生HTTPS Web流量的證據。雖然HTTPS本身是安全的，但它不支持數據簽名。結果是，TLSNotary證明依賴於TLSNotary（通過PageSigner [3]）簽名。TLSNotary Proofs利用傳輸層安全性（TLS）協議，使得在訪問數據後對數據進行簽名的TLS主密鑰在三方之間分配：伺服器（oracle），受審覈方（Oraclize）和核數師。Oraclize使用Amazon Web Services（AWS）虛擬機實例作爲審覈員，可以證明自它實例化以來未經修改[4]。此AWS實例儲存TLSNotary機密，允許其提供誠實證明。雖然它提供了比純信任查詢/響應機制更高的數據篡改保證，但這種方法確實需要假設亞馬遜本身不會篡改VM實例。

TownCrier [5,6]是基於可信執行環境的經過身份驗證的數據饋送oracle系統; 這些方法採用不同的機制，利用基於硬體的安全區域來驗證數據的完整性。TownCrier使用英特爾的SGX（Software Guard eXtensions）來確保HTTPS查詢的響應可以被驗證爲可靠。SGX提供完整性保證，確保在安全區內運行的應用程式受到CPU的保護，防止任何其他進程被篡改。它還提供機密性，確保在安全區內運行時應用程式的狀態對其他進程不透明。最後，SGX允許證明，通過生成數位簽章的證據，證明應用程式 - 通過其構建的雜湊安全地識別 - 實際上是在安全區內運行。通過驗證此數位簽章，去中心化式應用程式可以證明TownCrier實例在SGX安全區內安全運行。反過來，這證明實例沒有被篡改，因此TownCrier發出的數據是真實的。機密性屬性還允許TownCrier通過允許使用TownCrier實例的公鑰加密數據查詢來處理私有數據。通過在諸如SGX的安全區內運行oracle的查詢/響應機制，可以有效地將其視爲在受信任的第三方硬體上安全運行，確保所請求的數據被返回到未被禁用的狀態（假設我們信任Intel/SGX）。

[[computation_oracles_sec]]
=== 計算 oracles

到目前爲止，我們只是在請求和提供數據的背景下討論了oracles。然而，oracles也可用於執行任意計算，這一功能在以太坊固有的區塊gas限制和相對昂貴的計算成本的情況下特別有用; Vitalik本人指出，與現有的集中服務相比，以太坊的計算成本效率低了一百萬倍[7]。計算oracles可以用於對一組輸入執行相關計算，而不是僅僅中繼查詢結果，並返回計算結果，這可能是在鏈上計算不可行的。例如，可以使用計算oracle執行計算密集型迴歸計算，以估計債券合約的收益率。

Oraclize提供的服務允許去中心化應用請求輸出在沙盒AWS虛擬機中執行的計算。AWS實例從包含在上傳到IPFS的存檔中的用戶配置的Dockerfile創建可執行容器。根據請求，Oraclize使用其雜湊查詢此存檔，然後在AWS上初始化並執行Docker容器，將作爲環境變數提供給應用程式的任何參數傳遞。容器化應用程式根據時間限制執行計算，並且必須將結果寫入標準輸出，Oraclize可以將其返回到去中心化應用。Oraclize目前在可審覈的t2.micro AWS實例上提供此服務。

作爲可驗證的oracle真理的標準，“cryptlet”的概念已被正式化爲Microsoft更廣泛的ESC框架[8]的一部分。Cryptlet在加密的封裝內執行，該封裝抽象出基礎設施，例如I/O，並附加了CryptoDelegate，以便自動對傳入和傳出的消息進行簽名，驗證和驗證。Cryptlet支持分佈式事務，因此合約邏輯可以以ACID方式處理複雜的多步驟，多區塊鏈和外部系統事務。這允許開發人員創建便攜，隔離和私有的真相解決方案，以便在智能合約中使用。Cryptlet遵循以下格式：

TrueBit [9]是可擴展和可驗證的離線計算的解決方案。它引入了一個求解器和驗證器系統，分別執行計算和驗證。如果解決方案受到挑戰，則在鏈上執行對計算子集的迭代驗證過程 - 一種“驗證遊戲”。遊戲通過一系列迴圈進行，每個迴圈遞迴地檢查計算的越來越小的子集。遊戲最終進入最後一輪，挑戰是微不足道的，以至於評委 - 以太坊礦工 - 可以對挑戰是否合理，在鏈上進行最終裁決。實際上，TrueBit是一個計算市場的實現，允許去中心化應用支付可在網路外執行的可驗證計算，但依靠以太坊來強制執行驗證遊戲的規則。理論上，這使無信任的智能合約能夠安全地執行任何計算任務。

TrueBit等系統有廣泛的應用，從機器學習到任何工作量證明的驗證。後者的一個例子是Doge-Ethereum橋，它利用TrueBit來驗證Dogecoin的工作量證明，Scrypt，一種難以在以太坊塊gas限制內計算的記憶體密集和計算密集型函數。通過在TrueBit上執行此驗證，可以在以太坊的Rinkeby測試網路上的智能合約中安全地驗證Dogecoin交易。

[[decentralized_orackes_sec]]
=== 去中心化的 oracles

上面概況的機制都描述了依賴於可信任權威的集中式oracle系統。雖然它們應該足以滿足許多應用，但它們確實代表了以太坊網路中的中心故障點。已經提出了許多圍繞去中心化oracle作爲確保數據可用性手段的方案，以及利用鏈上數據聚合系統創建獨立數據提供者網路。

ChainLink [10]提出了一個去中心化oracle網路，包括三個關鍵的智能合約：信譽合約，訂單匹配合約，彙總合約和數據提供商的脫鏈註冊。信譽合約用於跟蹤數據提供商的績效。聲譽合約中的分數用於填充離線註冊表。訂單匹配合約使用信譽合約從oracles中選擇出價。然後，它最終確定服務級別協議（SLA），其中包括查詢參數和所需的oracles數量。這意味着購買者無需直接與個別的oracles交易。聚合合約從多個oracles收集使用提交/顯示方案提交的響應，計算查詢的最終集合結果，

這種去中心化方法的主要挑戰之一是彙總函數的制定。ChainLink建議計算加權響應，允許爲每個oracle響應報告有效性分數。在這裏檢測“無效”分數是非常重要的，因爲它依賴於前提：由對等體提供的響應偏差測量的外圍數據點是不正確的。基於響應分佈中的oracle響應的位置來計算有效性分數可能會使正確答案超過普通答案。因此，ChainLink提供了一組標準的聚合合約，但也允許指定自定義的聚合合約。

一個相關的想法是SchellingCoin協議[11]。在這裏，多個參與者報告價值，並將中位數作爲“正確”答案。報告者必須提供重新分配的存款，以支持更接近中位數的價值，從而激勵報告與其他價值相似的價值。一個共同的價值，也稱爲Schelling Point，受訪者可能認爲這是一個自然而明顯的協調目標，預計將接近實際價值。

Teutsch最近提出了一種新的去中心化脫鏈數據可用性設計oracle [12]。該設計利用專用的工作證明區塊鏈，該區塊鏈能夠正確地報告在給定時期內的註冊數據是否可用。礦工嘗試下載，儲存和傳播所有當前註冊的數據，因此保證數據在本地可用。雖然這樣的系統在每個挖掘節點儲存和傳播所有註冊數據的意義上是昂貴的，但是系統允許通過在註冊週期結束之後釋放數據來重用儲存。

[[oracle_client_interfaces_in_solidity_sec]]
=== Solidity中的Oracle客戶端接口

下面是一個Solidity範例，演示如何使用API從Oraclize連續輪詢ETH/USD價格並以可用的方式儲存結果。：

要與Oraclize集成，合約EthUsdPriceTicker必須是usingOraclize的子項；usingOraclize合約在oraclizeAPI檔案中定義。數據請求是使用oraclize_query()函數生成的，該函數繼承自usingOraclize合約。這是一個重載函數，至少需要兩個參數：

* 支持的數據源，例如URL，WolframAlpha，IPFS或計算
* 給定數據源的參數，可能包括使用JSON或XML解析助手

價格查詢在queryTicke()函數中執行。爲了執行查詢，Oraclize要求在以太網中支付少量費用，包括將結果傳輸和處理到__callback()函數的gas成本以及隨附的服務附加費。此數量取決於數據源，如果指定，則取決於所需的真實性證明類型。一旦查詢到數據，__callback()函數由Oraclize控制的帳戶調用，該帳戶被允許進行回調; 它傳遞響應值和唯一的queryId參數，作爲範例，它可用於處理和跟蹤來自Oraclize的多個掛起的回調。

金融數據提供商Thomson Reuters還爲以太坊提供了一項名爲BlockOne IQ的oracle服務，允許在私有或許可網路上運行的智能合約請求市場和參考數據[13]。下面是oracle的接口，以及將發出請求的客戶端合約：

使用initRequest()函數啓動數據請求，該函數除了兩個回調函數之外，還允許指定查詢類型（在此範例中，是對日內價格的請求）。
這將返回一個uint256識別碼，然後可以使用該識別碼提供其他參數。addArgumentToRequestString()函數用於指定RIC（Reuters Instrument Code），此處用於IBM股票，addArgumentToRequestUint()允許指定時間戳。現在，傳入block.timestamp的別名將查詢IBM的當前價格。然後由executeRequest()函數執行該請求。處理完請求後，oracle合約將使用查詢識別碼調用onSuccess回調函數，允許查詢結果數據，否則在查詢失敗時使用錯誤程式碼進行onFailure回調。成功查詢的可用欄位包括開盤價，最高價，最低價，收盤價（OHLC）和買/賣價。

Reality Keys [14]允許使用POST請求對事實進行離線請求。響應以加密方式簽名，允許在鏈上進行驗證。在這裏，請求使用blockr.io API在特定時間檢查比特幣區塊鏈上的帳戶餘額：

對於此範例，參數允許指定區塊鏈，要查詢的金額（總收到金額或最終餘額）以及要與提供的值進行比較的結果，從而允許真或假的響應。除了“signature_v2”欄位之外，生成的JSON物件還包括返回值，該欄位允許使用ecrecover()函數在智能合約中驗證結果：

爲了驗證簽名，ecrecover()可以確定數據確實由ethereum_address簽名，如下所示。fact_hash和signed_value經過雜湊處理，並將三個簽名參數傳遞給ecrecover（）：

[[references_sec]]
=== 參考

[1] http://www.oraclize.it/ +
[2] https://tlsnotary.org/ +
[3] https://tlsnotary.org/pagesigner.html +
[4] https://bitcointalk.org/index.php?topic=301538.0 +
[5] http://hackingdistributed.com/2017/06/15/town-crier/ +
[6] https://www.cs.cornell.edu/~fanz/files/pubs/tc-ccs16-final.pdf +
[7] https://www.crowdfundinsider.com/2018/04/131519-vitalik-buterin-outlines-off-chain-ethereum-smart-contract-activity-at-deconomy/ +
[8] https://github.com/Azure/azure-blockchain-projects/blob/master/bletchley/EnterpriseSmartContracts.md +
[9] https://people.cs.uchicago.edu/~teutsch/papers/truebit.pdf +
[10] https://link.smartcontract.com/whitepaper +
[11] https://blog.ethereum.org/2014/03/28/schellingcoin-a-minimal-trust-universal-data-feed/ +
[12] http://people.cs.uchicago.edu/~teutsch/papers/decentralized_oracles.pdf +
[13] https://developers.thomsonreuters.com/blockchain-apis/blockone-iq-ethereum +
[14] https://www.realitykeys.com

[[other_links_sec]]
=== 其他鏈接

https://ethereum.stackexchange.com/questions/201/how-does-oraclize-handle-the-tlsnotary-secret +
https://blog.oraclize.it/on-decentralization-of-blockchain-oracles-94fb78598e79 +
https://medium.com/@YondonFu/off-chain-computation-solutions-for-ethereum-developers-507b23355b17 +
https://blog.oraclize.it/overcoming-blockchain-limitations-bd50a4cfb233 +
https://medium.com/@jeff.ethereum/optimising-the-ethereum-virtual-machine-58457e61ca15 +
http://docs.oraclize.it/#ethereum +
https://media.consensys.net/a-visit-to-the-oracle-de9097d38b2f +
https://blog.ethereum.org/2014/07/22/ethereum-and-oracles/ +
http://www.oraclize.it/papers/random_datasource-rev1.pdf +
https://blog.oraclize.it/on-decentralization-of-blockchain-oracles-94fb78598e79 +
https://www.reddit.com/r/ethereum/comments/73rgzu/is_solving_the_oracle_problem_a_paradox/ +
https://medium.com/truebit/a-file-system-dilemma-2bd81a2cba25
https://medium.com/@roman.brodetski/introducing-oracul-decentralized-oracle-data-feed-solution-for-ethereum-5cab1ca8bb64


[[gas]]
== gas（Gas）

**Gas**是以太坊用於衡量程式執行一個或一組動作所需計算量的單位。交易或合約執行的每項操作都需要一定數量的gas; 所需的gas數量與正在執行的計算步驟的類型和數量有關。與僅以千字節（kB）計算交易規模的比特幣交易費相比，以太坊交易費必須考慮智能合約程式碼可以執行的任意數量的計算步驟。程式執行的操作數越多，運行完成的成本就越高。

每次操作都需要固定量的gas。以太坊黃皮書的的一些例子：

* 添加兩個數字需要3個gas
* 計算Keccak256雜湊值，需要30個gas+ 每256位數據被雜湊6個gas
* 發送交易成本為21000 gas

gas是以太坊的重要組成部分，具有雙重作用。一，作為以太坊價格（具有波動性）和礦工對其工作的獎勵之間的抽象層。另一種是抵禦拒絕服務攻擊。為了防止網路中的意外或惡意無限迴圈或其他計算浪費，每個交易的發起者需要設置他們願意花費在gas上的金額的限制。因此，gas系統阻止攻擊者發送垃圾郵件交易，因為他們必須按比例支付他們消耗的計算，帶寬和儲存資源。

=== 停機問題

交易費和會計的想法似乎很實用，但你可能想知道為什麼以太坊首先需要gas。gas是關鍵，因為它不僅可以解決停機問題，而且對安全和活力也至關重要。什麼是停機問題，安全和活力，為什麼要關心？

=== 支付gas

雖然gas有價格，但它不能“擁有”也不能“花”。gas僅存在於以太坊虛擬機（EVM）內部，作為計算工作量的計數。發起方被收取ether交易費，然後轉換為gas，然後轉回到ether，作為礦工的塊獎勵。這些轉換步驟用於將計算的價格（與“工作量”相關）與ether的價格（與市場波動相關）分開。

=== gas成本與gas價格

雖然**gas成本**是EVM中執行的操作步驟的度量，但gas本身也具有以ether測量的**gas價格**。在執行交易時，發起方指定他們願意為每個gas單位支付的gas價格（以ether為單位），允許市場決定ether的價格與計算操作的成本之間的關係（以gas衡量） 。

`total gas used * gas price paid = transaction fee`，以ether為單位

此金額將在交易執行開始時從發起方的帳戶中扣除。發起方不是設置“total gas used”，而是設置**gas limit**，該限制應足以覆蓋執行交易所需的gas量。

=== gas成本限制和gas耗盡

在發送交易之前，發起方必須指定**gas limit**  - 他們願意購買的最大gas數量。他們還必須指定**gas price** - 他們願意為每單位gas支付的以太價格。

以ether計算的`gas limit * gas price`在交易執行開始時從發起方的帳戶中扣除作為存款。這是為了防止發送者在執行中期“破產”並且無法支付gas費用。由於這個原因，用戶也無法設置超出其帳戶餘額的gas限制。

理想情況下，發起方將設置一個高於或等於實際使用的gas的gas限制。如果gas限制設置高於消耗的gas量，發貨人將收到超額金額的退款，因為礦工只獲得他們實際工作的補償。

在這種情況下：

`（gas限制 - 多餘gas）*gas價格以太以礦塊作為塊獎勵

`(gas limit - excess gas) * gas price` ether作為礦工的區塊獎勵

`excess gas * gas price` ether退回發起方

但是，如果使用的gas超過規定的gas限制，即如果在執行期間交易“runs out of gas”，則操作終止。雖然交易不成功，但由於礦工已經完成了計算工作，不會退回發送人的交易費用，礦工因此得到補償。

==== 範例

如果交易是從外部擁有帳戶（EOA）發送的，則從EOA的餘額中扣除gas費。換句話說，交易的發起人正在支付gas費。發起人為交易消耗的總gas以及隨後的任何子執行提供資金。這意味著如果發起者X附加1000個gas來調用合約A，其在計算上花費500個gas然後向合約B發送另一個消息，則A用於將消息發送到B的gas也會再已開始從X的gas限制中扣除。

```
EOA帳戶X啟動交易並調用合約帳戶A上的功能，附帶1000個gas

合約A在計算上花費500gas，並向合約B發送消耗100gas的消息

合約B在計算上花費300個gas並完成交易。

100個gas退還給X.
```

因此，如果該交易的發起人在開始時沒有附加足夠高的gas費，那麼在交易中執行一部分操作的中間合約（例如，在我們的範例中為合約A）理論上可以耗盡gas。如果合約在執行中期用完，除了gas費支付外，所有狀態變更都會被撤銷。

=== 估算 Gas

通過假裝交易已經被包含在區塊鏈中來估算gas，然後返回如果操作是真實的那麼可以收取的確切gas量。換句話說，它使用與礦工用來計算實際費用但從未開採過區塊鏈的完全相同的程式。

請注意，由於各種原因（包括EVM機制和節點性能），估計值可能遠遠超過交易實際使用的gas量。

``` javascript
var result = web3.eth.estimateGas({
    to: "0xc4abd0339eb8d57087278718986382264244252f",
    data: "0xc6888fa10000000000000000000000000000000000000000000000000000000000000003"
});
console.log(result); // "0x0000000000000000000000000000000000000000000000000000000000000015"
```

=== gas價格和交易優先順序

gas價格是交易發起方願意為每個gas單位支付的ether量。開採下一個區塊的礦工決定要包括哪些交易。由於gas價格被計入他們將作為獎勵的交易費中，他們更可能首先包括具有最高gas價格的交易。如果發起方將gas價格設置得太低，他們可能需要等待很長時間才能將其交易進入一個區塊。

礦工還可以決定塊中包含交易的順序。由於多個礦工競爭將其區塊附加到區塊鏈，因此區塊內的交易順序由“獲勝”礦工任意決定，然後其他礦工用該訂單核實。雖然可以任意排列來自不同帳戶的交易，但是來自個人帳戶的交易是按照自動遞增的隨機數的順序執行的。

=== 區塊gas限制

區塊gas限制是區塊中允許的最大gas量，用於確定區塊中可以容納的交易數量。例如，假設我們有5個交易，其中每個交易的gas限制為10,20,30,40和50.如果區塊gas限制為100，那麼前四個交易可以適合該區塊，而交易5必須等待未來的區塊。如前所述，礦工決定在一個區塊中包含哪些交易。不同的礦工可以嘗試包括塊中的最後2個交易（50 + 40），並且它們僅具有包括第一個交易（10）的空間。如果你嘗試包含的交易需要的gas量超過當前的gas限制，則網路將拒絕該交易，你的以太坊客戶將向你發送消息“交易超過區塊gas限制。根據https://etherscan.io的數據，目前區塊的gas限制在500萬左右。即一個區塊可以容納約238個交易，每個交易消耗21000個gas。

=== 誰來決定區塊gas限制是多少？

網路上的礦工決定區塊gas限制是什麼。想要在以太坊網路上挖礦的個人使用挖礦程式，例如ethminer，它連接到Geth或Parity Ethereum客戶端。以太坊協議有一個內建機制，礦工可以對gas限制進行投票，因此無需在硬分叉上進行協調就可以增加容量。塊的礦工能夠在任一方向上將塊氣限制調整1/1024（0.0976％）。其結果是根據當時網路的需要調整塊大小。這一機制與預設的開採策略結合在一起，礦工預設將投票決定至少470萬的gas限制，但如果這一數字更高的話，將把目標對準最近的(1024區塊指數移動)平均gas的150%，從而使數量有機地增加。礦工們可以選擇改變這一點，但是他們中的許多人不這樣做，並保留預設值。

=== gas退款

以太坊通過退還高達一半的gas費用來鼓勵刪除儲存的變數。
EVM中有2個負的gas操作：

清理合約是-24,000（SELFDESTRUCT）
清理儲存為-15,000（SSTORE [x] = 0）

==== GasToken

GasToken是一種符合ERC20標準的token，允許任何人在gas價格低時“儲存”gas，並在gas價格高時使用gas。通過使其成為可交易的資產，它基本上創造了一個gas市場。
它的工作原理是利用前面描述的gas退款機制。

你可以在[https://gastoken.io/](https://gastoken.io/)瞭解計算盈利能力以及如何使用釋放gas所涉及的數學

=== 租金
目前，以太坊社區提出了一項關於向智能合約收取“租金”以保持活力的建議。

在沒有支付租金的情況下，智能合約將被“睡眠”，即使是簡單的讀取操作也無法獲得數據。需要通過支付租金和提交Merkle證據來喚醒進入睡眠狀態的合約。

https://github.com/ethereum/EIPs/issues/35
https://ethresear.ch/t/a-simple-and-principled-way-to-compute-rent-fees/1455
https://ethresear.ch/t/improving-the-ux-of-rent-with-a-sleeping-waking-mechanism/1480
[[evm_chapter]]
== 以太坊虛擬機 (The Ethereum Virtual Machine)
((("EVM (Ethereum Virtual Machine)", id="ix_13evm-asciidoc0", range="startofrange")))以太坊虛擬機，簡稱　EVM，是以太坊協議和運作的心臟。 正如您可能從名稱中猜到的那樣，它是一個計算引擎，與或者是其他字節碼編譯(bytecode-complied)的編程語言（如Java）的直譯器，或是像 Microsoft .NET Framework的虛擬機，並沒有太大差別。 在本章中，我們將會詳細介紹 EVM, 在乙太坊狀態更新的執行脈落之中，介紹包含指令集 (instruction set), 結構以及運作。

[[evm_description]]
=== 什麼是以太坊虛擬機 (EVM) ?
以太坊虛擬機 (EVM) 是以太坊的一部份，用來處理智能合約的部署以及執行。當外部擁有帳戶 (EOA) 送交易至其它接收者時，若是交易中只用到 value 欄位時，就不需要動到以太坊虛擬機的運算。但是實際上來說，大部份的情形都會需要作到狀態 (state) 的更新，而狀態更新就會運用 EVM 的計算。從高階的角度來看，以太坊區塊鏈上所執行的 EVM 可以被想成一個全域的去中心化電腦，此電腦上面包有數以百萬計的可執行物件，每個物件都擁有永久的數據儲存空間。

EVM 是一個類圖靈完備的狀態機; 用“類”來形容是因為EVM上所有執行程序都有計算步數的限制，因為啟動智能合約之執行時，會設定 Gas 的總量限制。有鑒於此，停機問題(halting problem)就被解決了，所有程式文本之執行都有其終點。當惡意或意外的不當程式被執行時，程序本來將會永遠無法停止，但因為有 Gas 的限制，所以能夠避免該狀況；所以說，以太坊平台遇到這些不當程式時，並不會停機。

EVM 具有基於堆疊的體系結構，將所有記憶體內(in-memory) 的值存儲在堆疊中。它的字(word)大小為256位元（主要用於簡化原生散列和橢圓曲線操作），並具有多個可尋址的數據組件：

[role="pagebreak-before"]
* 一個不可變的程序代碼 (program code) ROM，加載了可執行的智能合約字節碼 (bytecode)
* 揮發性記憶體 (volatile memory) 中每個位置都明確初始化為零
* 作為以太坊狀態的一部分的永久存儲器，也是零初始化的

在執行期間還有一組可用的環境變量和數據。我們將在本章後面詳細介紹這些內容。

<<evm_architecture>> 顯示以太坊虛擬機架構及執行脈落
[[evm_architecture]]
.以太坊虛擬機 (EVM) 架構與執行脈落
image::images/evm-architecture.png["以太坊虛擬機 (EVM) 架構與執行脈落"]


[[evm_comparison]]
==== 與現有的虛擬機科技作比較

* 虛擬機（Virtual Machine）（Virtualbox, QEMU, 雲計算）

* Java 虛擬機（VM）

虛擬機技術（如Virtualbox和QEMU / KVM）與EVM的不同之處在於它們的目的是提供管理程式功能，或者處理客戶作業系統與底層主機作業系統和硬體之間的系統調用，任務調度和資源管理的軟體抽象。

然而，Java VM（JVM）規範的某些方面確實包含與EVM的相似之處。從高級概述來看，JVM 旨在提供與底層主機作業系統或硬體無關的運行時環境，從而實現各種系統的兼容性。在JVM上運行的高級程式語言（如Java或Scala）被編譯到相應的指令集 Bytecode 中。這與編譯要在EVM上運行的Solidity源檔案相當。

[[evm_bytecode_overview]]
==== EVM機器語言（ Bytecode 操作）

EVM機器語言分為特定的指令集組，例如算術運算，邏輯和比較運算，控制流，系統調用，堆疊操作和儲存器操作。除典型的 Bytecode 操作外，EVM還必須管理帳戶資訊（即地址和餘額），當前gas價格和區塊資訊。

[[common_stack_opcodes]]
通用堆疊操作:: 堆疊和記憶體管理的操作碼指令：

[[common_system_opcodes]]
通用系統操作:: 執行程式的系統的操作碼指令：

[[common_arithmetic_opcodes]]
算術運算:: 通用算術運算程式碼指令：

[[common_environment_opcodes]]
環境操作碼:: 處理執行環境資訊的通用操作碼：

[[evm_state_descriptions]]
==== 狀態

與任何計算系統一樣，狀態概念也很重要。就像CPU跟蹤執行過程一樣，EVM必須跟蹤各種組件的狀態以支持交易。這些組件的狀態最終會推動總體區塊鏈的變化程度。這方面導致將以太坊描述為_基於交易的狀態機_，包含以下組件：

World State:: 160位地址識別碼和帳戶狀態之間的映射，在不可變的_Merkle Patricia Tree_資料結構中維護。

Account State:: 包含以下四個組件：

* _nonce_：表示從該相應帳戶發送的交易數量的值。

* _balance_：帳戶地址擁有的_wei_的數量。

* _storageRoot_：Merkle Patricia Tree根節點的256位雜湊值。

* _codeHash_：各個帳戶的EVM程式碼的不可變雜湊值。

Storage State:: 在EVM上運行時維護的帳戶特定狀態資訊。

Block State:: 交易所需的狀態值包括以下內容：

* _blockhash_：最近完成的塊的雜湊值。

* _coinbase_：收件人的地址。

* _timestamp_：當前塊的時間戳。

* _number_：當前塊的編號。

* _difficulty_：當前區塊的難度。

* _gaslimit_：當前區塊的gas限制。

Runtime Environment Information:: 用於使用交易的資訊。

* _gasprice_：當前gas價格，由交易發起人指定。

* _codesize_：交易程式碼庫的大小。

* _caller_：執行當前交易的帳戶的地址。

* _origin_：當前交易原始發件人的地址。


狀態轉換使用以下函數計算：

以太坊狀態轉換函數:: 用於計算_valid state transition_。

區塊終結狀態轉換函數:: 用於確定最終塊的狀態，作為挖礦過程的一部分，包含區塊獎勵。

區塊級狀態轉換函數:: 應用於交易狀態時的區塊終結狀態轉換函數的結果狀態。


[[compiling_solidity_to_evm]]
==== 將Solidity編譯為EVM Bytecode

[[solc_help]]
可以通過命令行完成將Solidity源檔案編譯為EVM Bytecode 。有關其他編譯選項的列表，只需運行以下命令：

[[solc_opcodes_option]]
使用_--opcodes_命令行選項可以輕鬆實現生成Solidity源檔案的原始操作碼流。此操作碼流會遺漏一些資訊（_--asm_選項會生成完整資訊），但這對於第一次介紹是足夠的。例如，編譯範例Solidity檔案_Example.sol_並將操作碼輸出填充到名為_BytecodeDir_的目錄中，使用以下命令完成：

或

[[solc_asm_option]]

[[solc_bin_option]]
以下命令將為我們的範例程式生成 Bytecode 二進制檔案：

生成的輸出操作碼檔案將取決於Solidity源檔案中包含的特定合約。我們的簡單Solidity檔案_Example.sol_ <<simple_solidity_example>>只有一個名為“example”的合約。

[[simple_solidity_example]]

如果查看_BytecodeDir_目錄，你將看到操作碼檔案_example.opcode_（請參閱<<simple_solidity_example>>），其中包含“example”合約的EVM機器語言操作碼指令。在文字編輯器中打開_example.opcode_檔案將顯示以下內容：

[[opcode_output]]

使用_--asm_選項編譯範例會在_BytecodeDir_目錄中生成一個檔案 _example.evm_。這包含詳細的EVM機器語言說明：


[[asm_output]]

_--bin_ 選項產生以下內容：

[[bin_output]]

讓我們檢查前兩條指令（參考<<common_stack_opcodes>>）：

[[opcode_analysis_1]]

這裡我們有_mnemonic_“PUSH1”，後跟一個值為“0x60”的原始字節。這對應於EVM指令，該操作將操作碼之後的單字節解釋為文字值並將其推入堆疊。可以將大小最多為32個字節的值壓入堆疊。例如，以下 Bytecode 將4字節值壓入堆疊：

[[opcode_analysis_2]]

第二個push操作碼將“0x40”儲存到堆疊中（在那裡已存在的“0x60”之上）。

接下來的兩個指令：

[[opcode_analysis_3]]

MSTORE是一個堆疊/記憶體操作（參見<<common_stack_opcodes>>），它將值保存到記憶體中，而CALLVALUE是一個環境操作碼（參見<<common_environment_opcodes>>），它返回正在執行的消息調用的存放值。

[[evm_bytecode_execution]]
==== 執行EVM Bytecode

[[gas_accounting_execution]]
==== Gas，會計

對於每個交易，都有一個關聯的_gas-limit_和_gas-price_，它們構成了EVM執行的費用。這些費用用於促進交易的必要資源，例如計算和儲存。gas還用於創建帳戶和智能合約。

[[turing_completeness_and_gas]]
==== 圖靈完備性和gas

簡單來說，如果系統或程式語言可以解決你輸入的任何問題，它是_圖靈完備的_。這在以太坊黃皮書中討論過：

[quote, Gavin Wood, ETHEREUM: A SECURE DECENTRALISED GENERALISED TRANSACTION LEDGER]
____________________________________________________________________
It is a _quasi_-Turing complete machine; the quasi qualification comes from the fact that the computation is intrinsically bounded through a parameter, gas, which limits the total amount of computation done.
____________________________________________________________________

雖然EVM理論上可以解決它收到的任何問題，但gas可能會阻止它這樣做。這可能在以下幾個方面發生：

1）在以太坊開採的塊具有與之相關的gas限制; 也就是說，區塊內所有交易所使用的總gas不能超過一定限度。
2）由於gas和gas價格齊頭並進，即使取消了gas限制，高度複雜的交易也可能在經濟上不可行。

但是，對於大多數用例，EVM可以解決提供給它的任何問題。

[[bytecode_vs_runtime_bytecode]]
====  Bytecode 與運行時 Bytecode

編譯合約時，你可以獲得_合約 Bytecode _或_運行時 Bytecode _。

合約 Bytecode 包含實際上最終位於區塊鏈上的 Bytecode _以及_將 Bytecode 放在區塊鏈上並運行合約構造函數所需的 Bytecode 。

另一方面，運行時 Bytecode 只是最終位於區塊鏈上的 Bytecode 。這不包括初始化合約並將其放在區塊鏈上所需的 Bytecode 。

讓我們以前面創建的簡單`Faucet.sol`合約為例。

[[faucet_example]]

要獲得合約 Bytecode ，我們將運行`solc --bin Faucet.sol`。如果我們只想要運行時 Bytecode ，我們將運行`solc --bin-runtime Faucet.sol`。

如果比較這些命令的輸出，你將看到運行時 Bytecode 是合約 Bytecode 的子集。換句話說，運行時 Bytecode 完全包含在合約 Bytecode 中。

[[disassembling_the_bytecode]]
==== 反彙編 Bytecode

反彙編EVM Bytecode 是瞭解高級別Solidity在EVM中的作用的好方法。你可以使用一些反彙編程式來執行此操作：

- *Porosity* 是一個流行的開源反編譯器：https://github.com/comaeio/porosity
- *Ethersplay* 是Binary Ninja的EVM插件，一個反彙編程式：https://github.com/trailofbits/ethersplay
- *IDA-Evm* 是IDA的EVM插件，另一個反彙編程式：https://github.com/trailofbits/ida-evm

在本節中，我們將使用 Binary Ninja 的 *Ethersplay* 插件。

在獲取Faucet.sol的運行時 Bytecode 後，我們可以將其提供給Binary Ninja（在匯入Ethersplay插件之後）以查看EVM指令。

[[Faucet_disassembled]]
.Disassembling the Faucet runtime bytecode
image::images/Faucet_disassembled.png["Faucet.sol runtime bytecode disassembled"]

當你將交易發送到智能合約時，交易首先會與該智能合約的**調度員（dispatcher）**進行交互。調度程式讀入交易的數據欄位並將其發送到適當的函數。

在熟悉的MSTORE指令之後，我們在編譯的Faucet.sol合約中看到以下創建：

[[faucet_instructions]]

"PUSH1 0x4" 將0x4置於堆疊頂部，棧初始為空。“CALLDATASIZE”獲取接收到的交易的calldata的大小（以字節為單位）並將其推送到堆疊中。當前堆疊如下所示：

.Current stack
[width="40%",frame="topbot",options="header,footer"]
|======================
|Stack
|0x4
|length of calldata from tx (msg.data)
|======================

下一條指令是“LT”，是“小於（less than）”的縮寫。LT指令檢查堆疊上的頂部項是否小於堆疊上的下一項。在我們的例子中，它檢查CALLDATASIZE的結果是否小於4個字節。

為什麼EVM會檢查交易的calldata是否至少為4個字節？因為函數識別碼的工作原理。每個函數由其keccak256雜湊的前四個字節標識。通過將函數的名稱和它所採用的參數放入keccak256雜湊函數，我們可以推匯出它的函數識別碼。在我們的合約中，我們有：

[[faucet_function_identifier]]
```
keccak256("withdraw(uint256)") = 0x2e1a7d4d...
```

因此，“withdraw（uint256）”函數的函數識別碼是0x2e1a7d4d，因為它們是結果雜湊的前四個字節。函數識別碼總是4個字節長，所以如果發送給合約的交易的整個數據欄位小於4個字節，那麼除非定義了_fallback函數_，否則沒有交易可能與之通信的函數。因為我們在Faucet.sol中實現了這樣的fallback函數，所以當calldata的長度小於4個字節時，EVM會跳轉到此函數。

如果msg.data欄位少於4個字節，LT將彈出堆疊的前兩個值並將1推到其上。否則，它會推入0。在我們的例子中，讓我們假設發送給我們的合約的transaciton的msg.data欄位_was_少於4個字節。

“PUSH1 0x3f”指令將字節“0x3f”壓入堆疊。在此指令之後，堆疊如下所示：

.Current stack
[width="40%",frame="topbot",options="header,footer"]
|======================
|Stack
|1
|0x3f
|======================

下一條指令是“JUMPI”，代表“jump if”。它的工作原理如下：

[[faucet_jump_instruction_text]]

在我們的例子中，“label”是0x3f，這是我們的fallback函數存在於我們的智能合約中的地方。“cond”參數為1，它來自之前LT指令的結果。要將整個序列放入單詞中，如果交易數據少於4個字節，則合約將跳轉到fallback函數。

[[Faucet_jumpi_instruction]]
.JUMPI instruction leading to fallback function
image::images/Faucet_jumpi_instruction.png["JUMPI instruction leading to fallback function"]

我們來看一下調度員的核心程式碼塊。假設我們收到的長度大於4個字節的calldata，“JUMPI”指令不會跳轉到回退函數。相反，程式碼執行將遵循下一條指令：

[[faucet_instructions]]

“PUSH1 0x0”將0壓入堆疊，否則為空。“CALLDATALOAD”接受發送到智能合約的calldata中的索引作為參數，並從該索引讀取32個字節，如下所示：

[[faucet_calldataload_instruction_text]]

由於0是從PUSH1 0x0命令傳遞給它的索引，因此CALLDATALOAD從字節0開始讀取32字節的calldata，然後將其推送到堆疊的頂部（在彈出原始0x0之後）。在“PUSH29 0x1000000 ...”指令之後，堆疊如下所示：

.Current stack
[width="40%",frame="topbot",options="header,footer"]
|======================
|Stack
|32 bytes of calldata starting at byte 0
|0x1000000... (29 bytes in length)
|======================

“SWAP1”用它後面的_第i個_元素交換堆疊頂部元素。在這裡，它與密鑰數據交換0x1000000 ... 新堆疊如下所示：

.Current stack
[width="40%",frame="topbot",options="header,footer"]
|======================
|Stack
|0x1000000... (29 bytes in length)
|32 bytes of calldata starting at byte 0
|======================

下一條指令是“DIV”，其工作方式如下：

[[faucet_div_instruction_text]]

在這裡，x = 32字節的calldata從字節0開始，y = 0x100000000 ...（總共29個字節）。你能想到調度員為什麼要進行劃分嗎？這是一個提示：我們從索引0開始從calldata讀取32個字節。該calldata的前四個字節是函數識別碼。

我們之前推送的0x100000000 ....長度為29個字節，由開頭的1組成，後跟全0。將我們的32字節的calldata除以此0x100000000 ....將只留下從索引0開始的callataload的_topmost 4字節_這四個字節 - 從索引0開始的calldataload中的前四個字節 - 是函數識別碼，並且這就是EVM如何提取該欄位。

如果你不清楚這一部分，可以這樣想：在base~10~，1234000/1000 = 1234。在base~16~中，這沒有什麼不同。不是每個地方都是10的倍數，它是16的倍數。正如在我們的較小的例子中除以10^3^（1000）只保留最頂部的數字，將我們的32字節基數~16~值除以16^29^做同樣的事。

DIV（函數識別碼）的結果被推送到堆疊上，我們的新堆疊如下：

.Current stack
[width="40%",frame="topbot",options="header,footer"]
|======================
|Stack
|function identifier sent in msg.data
|======================

由於“PUSH4 0xffffffff”和“AND”指令是冗餘的，我們可以完全忽略它們，因為堆疊在完成後將保持不變。“DUP1”指令複製堆疊上的1^st^項，這是函數識別碼。下一條指令“PUSH4 0x2e1a7d4d”將抽取（uint256）函數的計算函數識別碼推送到堆疊。堆疊現在看起來如下：

.Current stack
[width="40%",frame="topbot",options="header,footer"]
|======================
|Stack
|function identifier sent in msg.data
|function identifier sent in msg.data
|0x2e1a7d4d
|======================

下一條指令“EQ”彈出堆疊的前兩項並對它們進行比較。這是調度程式完成其主要工作的地方：它比較交易的msg.data欄位中發送的函數識別碼是否與withdraw（uint256）匹配。如果它們相等，則EQ將1推入堆疊，這最終將用於跳轉到fallback函數。否則，EQ將0推入堆疊。

假設發送給我們合約的交易確實以withdraw（uint256）的函數識別碼開頭，我們的新棧看起來如下：

.Current stack
[width="40%",frame="topbot",options="header,footer"]
|======================
|Stack
|function identifier sent in msg.data
|1
|======================

接下來，我們有“PUSH1 0x41”，這是withdraw（uint256）函數在合約中的地址。在此指令之後，堆疊如下所示：

.Current stack
[width="40%",frame="topbot",options="header,footer"]
|======================
|Stack
|function identifier sent in msg.data
|1
|0x41
|======================

接下來是JUMPI指令，它再次接受堆疊上的前兩個元素作為參數。在這種情況下，我們有“jumpi（0x41,1）”，它告訴EVM執行跳轉到withdraw（uint256）函數的位置。

[[evm_tools_references]]
=== EVM工具參考
* [ByteCode To Opcode Disassembler](https://etherscan.io/opcode-tool) (用於檢查/調試編譯是否完整運行，如果源程式碼未發佈則可用於逆向工程)
[Consensus]

== 共識

以太坊網路中的共識是指多個節點或代理在給定的時間點就區塊鏈狀態達成一致的能力。這與傳統的定義爲個人或羣體之間的一般協議的共識密切相關但不同。在這裏，社區必須解決在技術上（在網路內）和社交上達成共識的挑戰（以確保協議不會分叉或破裂）。本章將概述建立共識的一些技術方法。

當涉及區塊鏈上分散記錄保存和驗證的核心功能時，單獨依靠信任來確保添加到帳本的資訊是正確的可能會成爲問題。這種挑戰在去中心化網路中更爲明顯，因爲沒有中央實體來決定什麼應該和不應該被視爲是真實的。缺乏一箇中央決策實體是區塊鏈受歡迎程度的主要吸引力之一，因爲系統能夠抵抗審查制度，並且無需對許可或資訊獲取權限的依賴。然而，這些好處可能帶來成本，因爲如果沒有可信的仲裁員，任何分歧，欺騙或差異都需要使用數學，經濟或社會技術進行協調。因此，分散的系統更有抵禦攻擊的能力，但在應對變化時卻不那麼果斷。

獲得共識和信任資訊的能力將對區塊鏈技術作爲資產類別和技術的未來採用和實用具有重要意義。爲了應對這一挑戰並保持權力下放的重要性，社區不斷嘗試不同共識模式，我們將在本章中探討。

=== 共識度量

共識度量是可測量的數據，區塊鏈網路的節點必須在該數據上達成一致，以便爲每個塊中包含的數據建立並保持一致。在區塊鏈技術中，每次將新塊添加到鏈中時，每個網路節點都會測量並批准一致性度量。作爲共識度量的結果，區塊鏈充當了從一個確定可驗證的事實延伸到下一個事實的真理鏈。由於共識度量，區塊鏈協議的節點變爲 _迷你公證人_ _mini-notaries_，能夠從真實的節點中立即分辨出區塊鏈的錯誤副本，並將該事實報告給整個網路。這些措施是必需的，以便阻止通過提交包含虛假資訊的區塊來欺騙網路不良行爲者。由於一致性度量，區塊鏈不僅建立了的完整性，而且長期保持不變。共識度量有多種形式，但對於此討論而言，最重要的兩種是基於風險的度量和基於工作量的度量。

=== 基於Hash的度量

通常稱爲工作量證明（PoW）度量，這些度量建立了共識，因爲使用它們的協議將計算機設置爲查找難題的答案。找到適合網路參數的雜湊的難題要求節點提交處理能力並使用電力與其他節點競爭以提出有效的雜湊。爲了便於說明，可以考慮超級計算機，它的唯一工作就是在整數空間中搜索質數。現在考慮由普通計算機組成的整個網路。這些計算機放在一起時，可以說具有超級計算機的組合計算能力。這個計算機網路的唯一工作類似於搜索另一種稱爲SHA-256雜湊的數字的可能數字。這些數字具有獨特的屬性，就像質數一樣，儘管在生成符合網路設定標準的雜湊方面存在很大困難，但在發現時可以輕鬆驗證它們。想象計算雜湊和驗證雜湊的一種方法是使用拼圖遊戲類比。這個難題非常困難且耗時，但是一眼就能看出它是否已經完成。

當準確計算SHA-256雜湊值時，它們可用作證明已使用一定量的計算能力來查找數字的證明。最新的質數是asciimath：[2^(77,232,917）- 1]。它是由計算機發現的，就像計算機發現的SHA-256雜湊一樣。SHA-256雜湊比新質數更容易找到，但是找到雜湊的固有難點在於基於雜湊的度量得出它們的能力。

每個SHA-256雜湊都有64個十六進制字符。例如，這裏是單詞“yank”的SHA-256雜湊。
`“yank”（SHA-256）= 45F1B9FC8FD5F760A2134289579DF920AA55830F2A23DCF50D34E16C1292D7E0`

將其與三個字母“yan”的SHA-256雜湊：

`“yan”（SHA-256）= 281ACA1A80B52620BD717E8B14A0386B8ADA92AE859AC2C8A2AC222EFA0​​2EDBB`

兩個字母“ya”的SHA-256雜湊：

`“ya”（SHA-256）= 6663103A3E47EFC879EA31FA38458BE23BE0CE0895F3D8B27B7EA19A1120B3D4`

單個字母“y”的SHA-256雜湊：

`“y”（SHA-256）= A1FCE4363854FF888CFF4B8E7875D600C2682390412A8CF79B37D0B11148B0FA`

=== 基於雜湊的度量驗證

如果你對足夠多的隨機短語進行了雜湊，有點像打字機上的猴子，最終你會發現一個匹配特定模式的雜湊。在雜湊爲“ya”的情況下，請注意它以模式“666”開頭。這類似於比特幣，但比特幣要求找到與以“000”開頭的模式匹配的雜湊值。可以通過將前一個區塊中的資訊插入到SHA-256雜湊演算法中來創建的任何雜湊，並用於創建下一個塊，只要它在數字中具有正確數量的前導零，網路就會認可，並且區塊獎勵將是你的。

由於想要挖掘比特幣的人數不斷增加，因此每秒尋找SHA-256雜湊值的算力總是越來越多。比特幣軟體通過自動調整共識度量的難度來處理這種意外事件，增加前導零的數量以形成共識。這可以保證新塊的創建時間與前面的塊大致相同。對於比特幣網路，爲十分鐘，但可以輕鬆更改。在以太坊中，平均區塊生成時間約爲10秒。

== 基於風險的度量

通常稱爲Proof-of-Stake（PoS）度量，這些度量基於以下事實建立共識：選擇創建無效區塊的每個人都會失去比通過創建有效區塊獲得的更多的東西。該度量是通過關於鏈內數據的共識創造的，而不是關於鏈外數據的共識。基於雜湊的共識度量主要關注SHA-256雜湊的質量和精確性。基於風險的度量主要關注任何特定節點在添加新塊時所承擔的風險。

所有節點在這裏達成一致的度量是哪些節點創建了正確的塊，哪些節點沒有。在某種程度上，這已經內建在比特幣協議中。比特幣協議假定正確的塊是大多數節點正在挖掘的塊。它假設礦工不會選擇不正確的區塊，因爲這不利於挖掘壞區塊。

另一方面，基於風險的鏈依賴於對未能創建網路中其他節點認可的塊的創建者的快速，即時和不可逆轉的影響。通過強制執行資源丟失的風險，基於雜湊的度量（也依賴於不想浪費資源的人員）過程可以以更簡單的方式進行縮短和實施。目前正在研究在以太坊中實現這種共識度量模型。

工作量證明是一種共識協議，它將網路中的有效區塊鏈視爲創建計算成本最高的鏈。這裏提到的計算工作是將所有塊添加到當前區塊鏈所必須完成的工作。這項工作由網路節點完成，並且必須在計算上很困難，以便使工作變得非常重要，但也必須是可行的，以便在經過合理的努力之後可以實現。最終，網路將依賴於提供此PoW的節點以維持區塊鏈，因此，網路的最佳利益是需要合理的PoW。

在以太坊網路以及許多其他區塊鏈網路中，獲取PoW需要找到要添加到區塊鏈的塊的雜湊。這個雜湊是通過雜湊由塊的數據和隨機數組成的字串獲得的（創建此字串的方法可能會有所不同，但整個過程是相同的）。該雜湊必須小於某個閾值（由網路的難度確定），並且一旦節點發現產生該雜湊的隨機數，則接受相應的塊並將其添加到區塊鏈中。

找到這個有效雜湊的方法是修改nonce，通常將其初始化爲零並在每次迭代時遞增，直到產生低於網路閾值的雜湊。此過程稱爲挖掘。由於挖掘中使用的雜湊函數的性質，找到有效隨機數的唯一方法是通過暴力搜索，即檢查隨機數的每個可能值，直到找到滿足網路要求的雜湊。因此，提供有效的隨機數被認爲是PoW。

=== PoS

權益證明（PoS，Proof-of-Stake）是公共區塊鏈的一類共識演算法，它依賴於驗證者在網路中的經濟利益。在基於工作量證明（PoW）的公共區塊鏈（例如比特幣和以太坊的當前實現）中，該演算法獎勵解密加密謎題的參與者，以便驗證交易並創建新的塊（即挖掘）。在基於PoS的公共區塊鏈中（例如以太坊即將發佈的Casper實現），一組驗證者輪流對下一個塊進行建議和投票，每個驗證者的投票權重取決於其存款的大小（即賭注）。PoS的顯着優勢包括安全性，降低集中風險和能源效率。

通常，權益證明演算法如下。區塊鏈跟蹤一組驗證者，任何持有區塊鏈基本密碼貨幣的人（在以太坊的情況下是ether）都可以通過發送一種特殊類型的交易來將其以太幣鎖定到存款中，從而成爲驗證者。然後，通過所有當前驗證者都可以參與的一致性演算法來完成創建和同意新塊的過程。

有許多種共識演算法，以及許多方法可以爲參與共識演算法的驗證人分配獎勵，因此有許多“口味”的權益證明。從演算法的角度來看，有兩種主要類型：基於鏈的權益證明和BFT風格的權益證明。

* 在基於鏈的證明中，演算法在每個時隙中僞隨機地選擇一個驗證者（例如，每個10秒的週期可能是一個時隙），併爲該驗證者分配創建單個塊的權限，這個塊必須指向一些前一個塊（通常是前一個最長鏈末端的塊），因此隨着時間的推移，大多數塊會聚成一個不斷增長的鏈。

* 在BFT風格的股權證明中，驗證者被隨機分配提出區塊的權利，但是通過多輪過程來確定哪個區塊是規範的，其中每個驗證者在每輪中發送對某個特定區塊的“投票”，在流程結束時，所有（誠實和在線）驗證者永久同意任何給定的塊是否屬於鏈條的一部分。請注意，塊可能仍然鏈接在一起; 關鍵的區別在於塊上的共識可以在一個塊內，並且不依賴於它之後的鏈的長度或大小。

==== PoA

授權證明（PoA）是PoS一致性演算法的子集，主要由測試網和私有或聯盟網路使用。在基於PoA的區塊鏈中，交易有效性最終由一組經批准的鏈上帳戶確定，稱爲“授權節點”。確定授權節點的標準是通過網路治理結構中編寫的方法確定性地決定的。

PoA被廣泛認爲是達成共識的最快途徑，但依賴於驗證節點尚未受到損害的假設。非驗證參與者可以像公共以太網那樣訪問和使用網路（通過利用p2p交易，合約，帳戶等）

PoA共識依賴於驗證者的聲譽和過去的表現。這個想法是驗證者節點將其身份/聲譽放到我的身上。私人聯盟網路的一個重要方面是鏈上地址與已知的現實世界身份之間的聯繫。因此，我們可以說驗證節點正在盯着他們的“身份”或“聲譽”（而不是他們的經濟持有）。這爲驗證者創建了一定程度的問責制，最適合企業，私有或測試網路。

PoA目前由測試網路Kovan（PoA網路）使用，並且可以在Parity中輕鬆配置用於私人聯盟網路。

==== DPoS

代理權益證明（DPoS）是一種經過修改的權益證明形式，網路參與者投票選舉一系列代表（也稱爲證人）來驗證和保護區塊鏈。這些代表有點類似於PoA中的權威節點，除非他們的權限可能被選民撤銷。

在DPoS共識中，與PoS一樣，投票權重與用戶注入的投注金額成正比。這就產生了一個場景，即較多token持有者比較少token的持有者擁有更多的投票權。從遊戲理論的角度來看，這是有道理的，因爲那些具有更多經濟的“遊戲中的皮膚”的人自然會有更大的動力來選出最有效的代表證人。

此外，代表證人會收到驗證每個區塊的獎勵，因此被激勵保持誠實和有效 - 以免被替換。然而，有一些方法可以使“賄賂”變得相當合理; 例如，交易所可以提供存款利率（或者更加含糊地，使用交易所自己的資金建立一個很好的界面和功能），交易所運營商可以使用大量存款進行DPoS共識投票。。

== 以太坊的共識

=== Ethash簡介

Ethash是以太坊*工作量證明（PoW）演算法*，它依賴於數據集的初始紀元的生成，該數據集的大小約爲1GB，稱爲有向無環圖（*DAG*）。*DAG*使用* Dagger-Hashimoto演算法*的版本，它是*Vitalik Buterin的Dagger演算法*和*Thaddeus Dryja的Hashimoto演算法*的組合。* Dagger-Hashimoto演算法*是以太坊1.0使用的挖掘演算法。隨着時間的推移，*DAG*線性增長，每*紀元*（30,000塊，125小時）更新一次。

==== 種子，緩存，數據生成

*PoW演算法*涉及： +
- 通過掃描*DAG*的先前塊頭來計算每個塊的*Seed*。+
- *Cache* 是一個16MB的僞隨機緩存，根據種子計算，用於輕量級客戶端中的儲存。 +
- 來自cache的*DAG* *Data Generation* 在完整客戶端和礦工上用於儲存 (數據集中的每一項只依賴cache中的一小部分項目）+
- *礦工*通過隨機抽取數據集的片段並將它們混合在一起進行挖掘。可以使用儲存的緩存和低記憶體進行驗證，以重新生成所需的數據集的特定部分。

.參考：
- Ethash-DAG: https://github.com/ethereum/wiki/wiki/Ethash-DAG
- Ethash Specification: https://github.com/ethereum/wiki/wiki/Ethash
- Mining Ethash DAG: https://github.com/ethereum/wiki/wiki/Mining#ethash-dag
- Dagger-Hashimoto Algorithm: https://github.com/ethereum/wiki/blob/master/Dagger-Hashimoto.md
- DAG Explanation and Images: https://ethereum.stackexchange.com/questions/1993/what-actually-is-a-dag
- Ethash in Ethereum Yellowpaper: https://ethereum.github.io/yellowpaper/paper.pdf#appendix.J
- Ethash C API Example Usage: https://github.com/ethereum/wiki/wiki/Ethash-C-API

=== Polkadot簡介

Polkadot是一種鏈間區塊鏈協議，包括與權益證明（PoS）鏈的整合，允許Parachain在沒有內部共識的情況下獲得共識。

.Polkadot包括：

-  *Relay-Chains* 連接到所有Parachains並協調區塊鏈之間的共識和交易傳遞，並使用*驗證函數*通過驗證PoV候選塊的正確性來促進Parachain交易的最終確定。
-  *Parachains*（跨網路的並行鏈），它們是區塊鏈，用於收集和並行處理交易以實現可伸縮性。
-  無需信任，交易直接在區塊鏈之間轉移，而不是通過中間人或分散交易所。
- *彙總安全*，根據共識協議規則（*Rules*）檢查Parachain交易有效性。通過結合由動態治理系統確定的每個集團成員的一定比例的權益token資本來實現安全性。羣組成員資格需要綁定來自Validators和Nominators的賭注token的輸入，如果出現不良行爲，可以在試驗中使用不當行爲證明進行扣除。
-  *Bridges* 通過解耦具有不同共識架構機制的區塊鏈網路之間的鏈接來提供可擴展性。
-  *Collators* 負責監管和維護特定的Parachain，方法是將其可用交易整理爲有效性證明（PoV）候選塊，向Validators報告以證明交易有效並在塊中正確執行。如果它有winning ticket（由最接近Golden Ticket的Polkadot地址的Collator簽名）並且變得規範和最終確定，則通過支付他們從創建PoV候選區塊所收集的任何交易費來激勵他們。Collators被給予Polkadot地址。膠合劑不與鉚接標記粘合。
-  *Golden Ticket*是包含獎勵的每個Parachain的每個區塊中的特定Polkadot地址。Collators被賦予一個Polkadot地址，並向Validator提供由Collator簽名的PoV候選塊。獎勵的獲獎者在PoV候選區塊中有一個Collator Polkadot地址，該區域最接近Golden Ticket Polkadot地址
-  *Fisherman* 監控Polkadot網路交易，以發現Polkadot社區的不良行爲。將驗證者帶到法庭並證明他們表現得很糟糕的Fisherman會被確認者的債券激勵，因爲債券被用作懲罰不良行爲的懲罰。
-  *驗證者* 是Parachain社區中的維護者，他們被部署到不同的Parachains來監管系統。驗證者同意Merkle Trees的根源。驗證者必須使交易可用。漁民可以將驗證員帶到法庭，因爲沒有進行交易，相關的Collat​​ors可能會質疑該交易是否可以作爲整理證明。
-  *提名者*（類似於PoW挖掘）被動監督並投票給他們認爲可以通過賭注代幣資助他們認可的確認者。

Polkadot的Relay-Chains使用*Proof of Stake（PoS*系統，其中結構化狀態機（SM）並行執行多個拜占庭容錯（BFT）共識，以便SM過程收斂于越多個Parachain維度的包含有效候選者的解決方案跨的塊。每個Parachain中的有效候選塊是根據交易的可用性和有效性確定的，因爲根據共識機制，目標驗證者（下一個塊）只有在具有足夠的交易資訊時才能從源驗證者（前一個塊）執行傳入消息。可用和有效。驗證人投票選擇Collators使用規則達成共識的有效候選區塊。

.參考
- Polkadot link: https://polkadot.network
- Polkadot presentation at Berlin Parity Ethereum link: https://www.youtube.com/watch?v=gbXEcNTgNco
[Vyper]
[[viper_chap]]
== Vyper: 面向合約的程式語言

研究表明，具有跟蹤漏洞的智能合約可能導致意外執行。https://arxiv.org/pdf/1802.06038.pdf[最近的一項研究] 分析了970,898份合約。它概述了跟蹤漏洞的三個基本類別（已經導致以太坊用戶的災難性資金損失）。這些類別包括::
* 自殺合約。可以被任意地址殺死的合約
* 貪婪的合約，在某個執行狀態後無法釋放ether
* 浪費合約，不經意地將ether釋放到任意地址

Vyper是一種面向合約的實驗性程式語言，面向以太坊虛擬機（EVM）。Vyper致力於通過簡化程式碼並使其對人類可讀而提供卓越的審計能力。Vyper的一個原則是讓開發人員幾乎不可能編寫誤導性程式碼。這可以通過多種方式完成，我們將在下面介紹。

[[comparison_to_solidity_sec]]
=== 與 Solidity 比較

本節是那些正在考慮使用Vyper程式語言開發智能合約的人的參考。該部分主要對比了Vyper與Solidity的對比； 概覽，合理的推理，為什麼Vyper不包括以下傳統的物件導向編程（OOP）概念：

Modifiers:: 在Solidity中，你可以使用修飾器編寫函數。例如，以下函數`changeOwner`將在一個名為`onlyBy`的修飾器中運行程式碼，作為其執行的一部分。

[source,javascript]

正如我們在下面看到的，名為`onlyBy`的修飾器強制執行與所有權相關的規則。雖然修飾器很強大（能夠改變函數體中發生的事情），但它們也可能導致誤導性的程式碼執行。例如，確保`changeOwner`函數邏輯的唯一方法是每次實現程式碼時檢查並測試`onlyBy`修飾器。顯然，如果將來更改修改器，則調用它的函數可能會產生與最初預期不同的結果。

[source,javascript]

總的來說，修飾器的通常用例是在函數執行之前執行單個檢查。鑑於這種情況，Vyper的建議是完全取消修飾器，並簡單地使用內聯檢查和斷言作為函數的一部分。這樣做將提高審計能力和可讀性，因為Vyper函數將在明顯的視線中遵循邏輯內聯序列，而不必引用已在別處編寫的修飾器程式碼。

類繼承:: 繼承允許開發者通過從現有軟體庫中獲取預先存在的功能，屬性和行為來利用預先編寫的程式碼。繼承功能強大，可以促進程式碼的重用。Solidity支持多重繼承以及多態，雖然這些被認為是物件導向編程的一些最重要的特性，但Vyper並不支持它們。Vyper堅持認為繼承的實現要求編碼人員和審計人員在多個檔案之間跳轉，以便了解程式正在做什麼。Vyper還了解優先級規則以及多個繼承如何使程式碼過於複雜而無法理解。鑑於Solidity https://github.com/ethereum/solidity/blob/release/docs/contracts#inheritance[關於繼承的文件]給出了多重繼承為何有問題的例子，這是一個公平的陳述。

內聯彙編:: 內聯彙編為開發人員提供了以低級別訪問以太坊虛擬機（EVM）的機會。使用內聯彙編程式碼（在更高級別的源程式碼中）時，開發人員可以通過直接訪問EVM操作碼指令來執行操作。例如，以下內聯彙編程式碼通過使用EVM操作碼mload在記憶體位置0x80處添加3。

[source,assembly]

如前所述，Vyper致力於為開發人員和程式碼審計人員提供最易讀的程式碼。雖然內聯彙編可以提供強大的細粒度控制，但Vyper程式語言不支持它。

函數重載:: 具有相同名稱和不同參數選項的多個函數定義會導致在任何給定時間調用哪個函數時會產生很多混淆。隨著函數重載，編寫誤導程式碼會更容易（ foo（“hello”）記錄“hello”但foo（“hello”，“world”）竊取你的資金。）函數重載的另一個問題是它使程式碼更難以搜索，因為你必須跟蹤哪個調用指的是哪個功能。

變數類型轉換:: 類型轉換是一種允許開發者將變數從一種數據類型轉換為另一種數據類型的機制。

前置條件和後置條件::
Vyper明確處理前置條件，後置條件和狀態更改。雖然這會產生冗餘程式碼，但它也允許最大的可讀性和安全性。在Vyper中編寫智能合約時，開發人員應遵守以下3點。理想情況下，應仔細考慮3個點中的每個點，然後在程式碼中進行詳細記錄。這樣做將改進程式碼的設計，最終使程式碼更具可讀性和可審計性。

* 條件 - 以太坊狀態變數的當前狀態/條件是什麼
* 效果 - 這個智能合約程式碼對執行狀態變數的條件有什麼影響，即什麼會影響，什麼不會受到影響？這些影響是否與智能合約的意圖一致？
* 交互 - 現在已經詳盡地處理了前兩個步驟，現在是運行程式碼的時候了。在部署之前，邏輯上逐步執行程式碼並考慮執行程式碼的所有可能的永久結果，後果和方案，包括與其他合約的交互。

[[a_new_programming_paradigm_sec]]
=== 一種新的編程範式

Vyper的創作為新的編程範式打開了大門。例如，Vyper正在刪除類繼承以及其他功能，因此可以說Vyper偏離了傳統的物件導向編程（OOP）範例，這很好。

歷史上，OOP提供了一種表示現實世界物件的機制。例如，OOP允許實例化可以從person類繼承的employee物件。然而，從價值轉移和/或智能合約的角度來看，那些渴望功能性編程範式的人會同意，交易性編程絕不適合上述傳統的OOP範式。簡而言之，交易計算是與現實世界物件分開的世界。例如，你最後一次持有交易或正向鏈接業務規則的時間是什麼時候？

似乎Vyper沒有與OOP範例或函數式編程範例完全一致（完整的原因列表超出了本章的範圍）。出於這個原因，在開發的早期階段，我們能夠如此大膽地推出新的軟體開發範例嗎？一個致力於未來證明區塊鏈可執行程式碼的人。一個可以防止在不可改變的環境中造成災難性資金損失的人。區塊鏈革命中經歷的過去事件有機地為這一領域的進一步研究和發展創造了新的機會。也許這種研究和開發的結果最終可能導致軟體開發的新的不變性範式分類。

[[decorators_sec]]
=== 裝飾符
向 `@private` `@public` `@constant` `@payable` 這樣的裝飾符在每個函數的開頭宣告。

Private:: `@private` 使合約外部的函數無法訪問此函數。

Public:: `@public` 使該函數公開可見和可執行。例如，即使是以太坊錢包也會在查看合約時顯示公共函數。

Constant:: 以 `@constant` 開始的函數不允許狀態變數的改變，實際上，如果函數嘗試更改狀態變數，編譯器將拒絕整個程式（帶有適當的警告）。如果該函數用於更改狀態變數，則不要在函數的開頭使用`@ constant`。

Payable:: 只有以 `@payable` 開頭宣告的函數才能接收價值。

Vyper明確地實現了裝飾符的邏輯。例如，如果一個函數前面有一個`@appay`裝飾符和一個`@ constant`裝飾符，那麼Vyper程式碼編譯過程就會失敗。當然，這是有道理的，因為常量函數（僅從全局狀態讀取的函數）永遠不需要參與值的轉移。此外，每個Vyper函數必須以`@ public`或`@private`裝飾符開頭，以避免編譯失敗。同時使用`@public`裝飾符和`@private`裝飾符的Vyper函數也會導致編譯失敗。

[[online_code_editor_and_compiler_sec]]
=== 在線程式碼編輯器和編譯器

Vyper在以下URL <<https://vyper.online>> 上有自己的在線程式碼編輯器和編譯器。這個Vyper在線編譯器允許你僅使用Web瀏覽器編寫智能合約，然後將其編譯為 Bytecode ，ABI和LLL。Vyper在線編譯器具有各種預先編寫的智能合約，以方便你使用。這些包括簡單的公開拍賣，安全的遠程購買，ERC20 token等。

[[compiling_using_the_command_line_sec]]
=== 使用命令行編譯
每個Vyper合約都保存在擴展名為.v.py的單個檔案中。
安裝完成後，Vyper可以通過運行以下命令來編譯和提供 Bytecode

vyper ~/hello_world.v.py

通過運行以下命令可以獲得人類可讀的ABI程式碼（JSON格式）

vyper -f json ~/hello_world.v.py

[[reading_and_writing_data_sec]]
=== 讀寫數據

智能合約可以將數據寫入兩個地方，即以太坊的全球狀態查找樹或以太坊的鏈數據。雖然儲存，讀取和修改數據的成本很高，但這些儲存操作是大多數智能合約的必要組成部分。

全局狀態:: 給定智能合約中的狀態變數儲存在以太坊的全局狀態查找樹中，給定的智能合約只能儲存，讀取和修改與該合約地址相關的數據（即智能合約無法讀取或寫入其他智能合約）。

Log:: 如前所述，智能合約也可以通過日誌事件寫入以太坊的鏈數據。雖然Vyper最初使用 pass:[__]logpass:[__] 語法來宣告這些事件，但已經進行了更新，使Vyper的事件宣告更符合Solidity的原始語法。例如，Vyper宣告的一個名為MyLog的事件最初是 `MyLog: pass:[__]logpass:[__]({arg1: indexed(bytes[3])})`，Vyper的語法現在變為 `MyLog: event({arg1: indexed(bytes[3])})`。需要注意的是，在Vyper中執行日誌事件仍然是如下 `log.MyLog("123")`。

雖然智能合約可以寫入以太坊的鏈數據（通過日誌事件），但智能合約無法讀取他們創建的鏈上日誌事件。儘管如此，通過日誌事件寫入以太坊的鏈數據的一個好處是，可以在公共鏈上由輕客戶端發現和讀取日誌。例如，挖到的塊中的logsBloom值可以指示是否存在日誌事件。一旦建立，就可以通過日誌路徑獲取 logs -> data inside a given transaction receipt。

[[erc20_token_interface_implementation_sec]]
=== ERC20令牌接口實現
Vyper已將ERC20實施為預編譯合約，並允許預設使用它。
Vyper中的合約必須宣告為全域變數。宣告ERC20變數的範例可以是

token: address(ERC20)

[[opcodes_sec]]
=== 操作碼（OPCODES）
智能合約的程式碼主要使用Solidity或Vyper等高階語言編寫。編譯器負責獲取高級程式碼並創建它的低級解釋，然後可以在以太坊虛擬機（EVM）上執行。編譯器可以提取程式碼的最低表示（在EVM執行之前）是操作碼。在這種情況下，需要高階語言（如Vyper）的每個實現來提供適當的編譯機制（編譯器）以允許（除其他之外）將高級程式碼編譯到通用預定義的EVM操作碼中。一個很好的例子是Vyper實現了以太坊的分片操作碼。
[[communications_between_nodes]]
== 節點間的通信 —— 一個簡單的視角

以太坊節點之間通過簡單的線路協議進行通信，形成一個虛擬或覆蓋良好的網路
為實現這一目標，該協議稱為*ÐΞVp2p*，使用*RLP*等技術和標準。

[[transport_protocol]]
=== 傳輸協議

為了提供機密性並防止網路中斷，*ÐΞVp2p*節點使用*RLPx*消息，一種加密且經過身份驗證的_transport協議。
*RLPx*使用類似於*Kademlia*的路由演算法，*Kademlia*是用於分散的對等計算機網路的分佈式雜湊表（* DHT *）。
*RLPx*，作為底層傳輸協議，允許_“節點發現和網路形成”_。
*RLPx*的另一個顯著特徵是通過單個連接支持_多個協議_。

當*ÐΞVp2p*節點通過Internet進行通信時（通常情況下），它們使用TCP，它提供面向連接的介質，但實際上*ÐΞVp2p*節點通過使用底層傳輸協議*RLPx*所提供的所謂設施（或消息），以數據包通信，允許它們通信發送和接收數據包。

數據包是 _動態構建_ _dynamicically framed_，前綴為_RLP_編碼標頭，經過加密和驗證。通過幀頭實現多路複用，幀頭指定分組的目的協議。

==== 加密握手

通過握手建立連接，並且一旦建立，就將數據包加密並封裝為幀。

此握手將分兩個階段進行，第一階段涉及密鑰交換，第二階段將執行身份驗證，作為*DEVp2p*的一部分，還將交換每個節點的功能。

==== 安全 - 基本考慮因素

所有加密操作都基於*secp256k1*，並且每個節點都應該維護一個靜態私鑰，該私鑰在會話之間保存和恢復。

在實施加密之前，數據包具有時間戳屬性，以減少執行重放攻擊的時間視窗。
建議接收方只接受最近3秒內創建的數據包。

數據包被簽名。通過從簽名中恢復公鑰並檢查它是否與預期值匹配來執行驗證。

[[devp2p_messages_subprotocols]]
=== ÐΞVp2p 消息和子協議
使用*RLP*，我們可以編碼不同類型的數據，其類型由RLP的第一個條目中使用的整數值確定。
這樣，*ÐΞVp2p*，_基礎線路協議_ _basic wire protocol_，支持_任意的子協議_。

`0x00-0x10`之間的_Message IDs_保留用於*ÐΞVp2p*消息。因此，假定_sub-protocols_的消息ID從“0x10”開始。

未在對等節點之間共享的子協議是_忽略的_。
如果共享相同（同名）子協議的多個版本，則數字最高的勝出。

==== 基本建立通信 - 基本ÐΞVp2p消息

作為一個非常基本的例子，當兩個對等節點發起他們的通信時，每個對等節點用另一個稱為*“Hello”*的特殊*ÐΞVp2p*消息來迎接另一個，該消息由“0x00”消息ID標識。
通過這個特定的*ÐΞVp2p* *“Hello”*消息，每個節點將向其對等的相關數據公開，從而允許通信以非常基本的級別開始。

在此步驟中，每個對等方將知道有關其對等方的以下資訊。

- P2P協議的實現*版本*。現在必須是'1`。
- *客戶端軟體標識*，作為人類可讀的字串（例如`Ethereum（++）/ 1.0.0`）。
- 對等節點的*capability name*為長度為3的ASCII字串。當前支持的能力名稱為“eth”和“shh”。
- 對等節點的*capability version*為正整數。目前支持的版本是`eth`為`34`，`shh`為`1`。
- 客戶端正在偵聽的*連接埠*。如果為“0”則表示客戶端沒有收聽。
- *節點的唯一標識*指定為512位雜湊。

==== 斷開連接 - 基本ÐΞVp2p消息
要執行有序的斷開連接，要斷開連接的節點將發送名為*“Disconnect”*的*ÐΞVp2p*消息，該消息由_“0x01”_消息ID標識。此外，節點使用參數*“reason”*指定斷開的原因。

* “reason”*參數可以取值從“0x00”到“0x10”，例如“0x00”表示原因*“請求斷開連接”*和“0x04”表示*“太多對等節點”*。

==== 狀態 - 以太坊子協議範例

該子協議由`+0x00`消息-id標識。

此消息應在初始握手之後和任何與以太坊相關的消息之前發送，並通知其當前狀態。

為此，節點向其對等方公開以下數據;

- *Protocol version*
- *Network Id*
- *Total Difficulty of the best chain*
- *Hash of the best known block*
- *Hash of the Genesis block*

[[known_current_networks]]
===== 已知的當前網路ID
這裡是目前已知的網路ID列表：

- 0: *Olympic*; 以太坊公共預發佈測試網
- 1: *Frontier*; Homestead，Metropolis，以太坊公共主網
- 1: *Classic*; (un)forked 公共以太坊Classic主網路，鏈ID 61
- 1: *Expanse*; 另一個以太坊實現，鏈ID 2
- 2: *Morden*; 公共以太坊測試網，現在是以太坊經典測試網
- 3: *Ropsten*; 公共跨客戶端以太坊測試網
- 4: *Rinkeby*: 公共Geth以太坊測試網
- 42: *Kovan*; 公共Parity以太坊測試網
- 77: *Sokol*; 公共POA測試網
- 99: *POA*; 公共權威證明（PoA）以太網網路
- 7762959: *Musicoin*; 音樂區塊鏈

==== GetBlocks - 另一個子協議範例
該子協議由`+ 0x05` message-id標識。

通過此消息，節點通過其自己的雜湊向其對等方請求指定的塊。

請求節點的方式是通過包含它們所有雜湊值的列表，將消息採用以下形式;

....
[+0x05: P, hash_0: B_32, hash_1: B_32, ...]
....

請求節點必須沒有包含所有請求的塊的響應消息，在這種情況下，它必須再次請求那些尚未由其對等方發送的消息。

=== 節點標識和聲譽
*ÐΞVp2p*節點的標識是*secp256k1*公鑰。

客戶端可以自由標記新節點並使用節點ID作為_決定節點的信譽_的方法。

他們可以儲存給定ID的評級並相應地給予優先權。
[appendix]
[[ethereum_standards]]
== 以太坊標準

[[eips]]
=== 以太坊改進提案（EIPs）

https://eips.ethereum.org/

來自EIP-1：

 EIP代表以太坊改進提案。EIP是一個設計文件，為以太坊社區提供資訊，或描述以太坊或其過程或環境的新功能。EIP應提供該功能的簡明技術規範和該功能的基本原理。EIP作者負責在社區內建立共識並記錄不同意見。

[[eip_workflow]]
.Ethereum改進提案工作流程
image::images/eip_workflow.png["Ethereum Improvement Proposal Workflow"]

[[ercs]]
=== 以太坊徵求意見（ERCs）
Request for Comments（RFC）是一種用於為互聯網引入技術和組織指南的方法，因為它們是由https://www.ietf.org[Internet Engineering Task Force]提出的。ERCS包括為以太坊網路設置標準的類似指南。以下部分提供了由以太坊開發人員社區開發和接受的最新列表。

ERCs的增加是通過https://github.com/ethereum/EIPs[EIPs]，以太坊改進協議來完成的，這是對比特幣自己的BIP的致敬。EIP由開發人員編寫並提交給同行評審，評估其有用性，並且能夠增加現有ERC的實用性。如果他們被接受，他們最終將成為ERC標準的一部分。

[[eip_table]]
=== 最重要的EIP和ERC表

.Important EIPs and ERCs
[options="header"]
|===
| EIP/ERC # | Title | Author | Layer | Status | Created
| https://github.com/ethereum/EIPs/blob/master/EIPS/eip-1.md[EIP-1]                                 | EIP Purpose and Guidelines                                                                  | Martin Becze, Hudson Jameson               | Meta       | Final    |
| https://github.com/ethereum/EIPs/blob/master/EIPS/eip-2.md[EIP-2]                                 | Homestead Hard-fork Changes                                                                  | Vitalik Buterin                            | Core       | Final    |

| https://github.com/ethereum/EIPs/blob/master/EIPS/eip-5.md[EIP-5]                                 | Gas Usage for `RETURN` and `CALL`                                                                  | Christian Reitwiessner           | Core       | Draft    |
| https://github.com/ethereum/EIPs/blob/master/EIPS/eip-6.md[EIP-6]                                 | Renaming Suicide Opcode                                                                      | Hudson Jameson                             | Interface  | Final    |
| https://github.com/ethereum/EIPs/blob/master/EIPS/eip-7.md[EIP-7]                                 | `DELEGATECALL`                                                                                 | Vitalik Buterin                            | Core       | Final    |
| https://github.com/ethereum/EIPs/blob/master/EIPS/eip-8.md[EIP-8]                                 | devp2p Forward Compatibility Requirements for Homestead                                      | Felix Lange                                | Networking | Final    |
| https://github.com/ethereum/EIPs/blob/master/EIPS/eip-20.md[EIP-20]                | ERC-20 Token Standard. Describes standard functions a token contract may implement to allow DApps and Wallets to handle tokens across multiple interfaces/DApps. Methods include: `totalSupply()`, `balanceOf(address)`, `transfer`, `transferFrom`, `approve`, `allowance`. Events include: `Transfer` (triggered when tokens are transferred), `Approval` (triggered when `approve` is called).                                                                       | Fabian Vogelsteller, Vitalik Buterin       | ERC        | Final    | Frontier
| https://github.com/ethereum/EIPs/blob/master/EIPS/eip-55.md[EIP-55]                               | ERC-55 Mixed-case checksum address encoding                                                  | Vitalik Buterin                            | ERC        | Final    |
| https://github.com/ethereum/EIPs/blob/bd136e662fca4154787b44cded8d2a29b993be66/EIPS/abstraction.md[EIP-86]                | Setting the stage for "abstracting out" account security, and allowing users creation of "account contracts" toward a model where in the long-term all accounts are contracts that can pay for gas, and users are free to defined their own security model (that perform any desired signature verification and nonce checks instead of using the in-protocol mechanism where ECDSA and default nonce scheme are the only "standard" way to secure an account, which is currently hard-coded into transaction processing).                                                                      | Vitalik Buterin       | Core        | Deferred (to be replaced)    | Constantinople
| https://github.com/ethereum/EIPs/pull/210[EIP-96]                | Setting the Blockhash and state root refactoring to store blockhashes in the state to reduce protocol complexity and need for client implementation complexity necessary to process the `BLOCKHASH` opcode. Extends range of how far back blockhash checking may go, with the side effect of creating direct links between blocks with very distant block numbers to facilitate much more efficient initial Light Client syncing.                                                                       | Vitalik Buterin       | Core        |  Deferred   | Constantinople
| https://github.com/ethereum/EIPs/issues/100[EIP-100] | Change formula that computes the difficulty of a block (difficulty adjustment algorithm) to target mean block time and take uncles into account. | Vitalik Buterin                            | Core       | Final    | Metropolis Byzantinium
| https://github.com/ethereum/EIPs/blob/master/EIPS/eip-101.md[EIP-101] | Serenity Currency and Crypto Abstraction. Abstracting Ether up a level with the benefit of allowing Ether and sub-Tokens to be treated similarly by contracts, reducing level of indirection required for custom-policy accounts such as Multisigs, and purifying the underlying Ethereum protocol by reducing the minimal consensus implementation complexity | Vitalik Buterin                            | Active       | Serenity feature    | Serenity Casper
| https://blog.ethereum.org/2016/03/05/serenity-poc2/[EIP-105] | "Sharding scaffolding" EIP to allow Ethereum transactions to be parallelised using a binary tree sharding mechanism, and to set the stage for a later sharding scheme. Research in progress: https://github.com/ethereum/sharding | Vitalik Buterin                            | Active       | Serenity feature    | Serenity Casper
| https://github.com/ethereum/EIPs/blob/master/EIPS/eip-137.md[EIP-137] | Ethereum Domain Name Service - Specification                                                 | Nick Johnson                               | ERC        | Final    |
| https://github.com/ethereum/EIPs/pull/206[EIP-140]   | Add `REVERT` opcode instruction, which stops execution and rolls back the EVM execution state changes without consuming all provided gas (instead the contract only has to pay for memory) or losing logs, and returning to the caller a pointer to the memory location with the error code or message.                                                                           | Alex Beregszaszi, Nikolai Mushegian        | Core       | Final    | Metropolis Byzantinium
| https://github.com/ethereum/EIPs/blob/master/EIPS/eip-141.md[EIP-141]                             | Designated invalid EVM instruction                                                           | Alex Beregszaszi                           | Core       | Final    |
| https://github.com/ethereum/EIPs/blob/master/EIPS/eip-145.md[EIP-145]                             | Bitwise shifting instructions in EVM                                                     | Alex Beregszaszi, Paweł Bylica                            | Core       | Deferred    |
| https://github.com/ethereum/EIPs/blob/master/EIPS/eip-150.md[EIP-150]                             | Gas cost changes for IO-heavy operations                                                     | Vitalik Buterin                            | Core       | Final    |
| https://github.com/ethereum/EIPs/blob/master/EIPS/eip-155.md[EIP-155]                             | Simple Replay Attack Protection. Replay Attack allows any transaction using a pre-EIP155 Ethereum Node or Client to become signed so it is valid and executed on both the Ethereum and Ethereum Classic chains.                                                               | Vitalik Buterin                            | Core       | Final    | Homestead
| https://github.com/ethereum/EIPs/blob/master/EIPS/eip-158.md[EIP-158]                             | State clearing                                                               | Vitalik Buterin                            | Core       | Superseded    |
| https://github.com/ethereum/EIPs/blob/master/EIPS/eip-160.md[EIP-160]                             | EXP cost increase                                                                            | Vitalik Buterin                            | Core       | Final    |
| https://github.com/ethereum/EIPs/blob/master/EIPS/eip-161.md[EIP-161]                           | State trie clearing (invariant-preserving alternative[EIP-161]                                       | Gavin Wood                                 | Core       | Final    |
| https://github.com/ethereum/EIPs/blob/master/EIPS/eip-162.md[EIP-162]                             | ERC-162 ENS support for reverse resolution of Ethereum addresses                             | Maurelian, Nick Johnson                    | ERC        | Final    |

| https://github.com/ethereum/EIPs/blob/master/EIPS/eip-165.md[EIP-165]                             | ERC-165 Standard Interface Detection                             | Christian Reitwiessner                    | Interface        | Draft    |
| https://github.com/ethereum/EIPs/blob/master/EIPS/eip-170.md[EIP-170]                             | Contract code size limit                                                                     | Vitalik Buterin                            | Core       | Final    |
| https://github.com/ethereum/EIPs/blob/master/EIPS/eip-181.md[EIP-181]                             | ERC-181 ENS support for reverse resolution of Ethereum addresses                             | Nick Johnson                               | ERC        | Final    |
| https://github.com/ethereum/EIPs/blob/master/EIPS/eip-190.md[EIP-190]                             | ERC-190 Ethereum Smart Contract Packaging Standard                                           | Merriam, Coulter, Erfurt, Catalano, Matias | ERC        | Final    |
| https://github.com/ethereum/EIPs/pull/213[EIP-196]   | Precompiled contracts for addition and scalar multiplication operations on the elliptic curve alt_bn128, which are required in order to perform zkSNARK verification within the block gas limit
| Christian Reitwiessner                     | Core       | Final    | Metropolis Byzantinium
| https://github.com/ethereum/EIPs/pull/212[EIP-197]   | Precompiled contracts for optimal Ate pairing check of a pairing function on a specific pairing-friendly elliptic curve alt_bn128 and is combined with EIP 196
| Vitalik Buterin, Christian Reitwiessner    | Core       | Final    | Metropolis Byzantinium
| https://github.com/ethereum/EIPs/pull/198[EIP-198]   | Precompile to support big integer modular exponentiation enabling RSA signature verification and other cryptographic applications
| Vitalik Buterin                            | Core       | Final    | Metropolis Byzantinium
| https://github.com/ethereum/EIPs/pull/211[EIP-211]   | New opcodes: `RETURNDATASIZE` and `RETURNDATACOPY`. Support for returning variable-length values inside the EVM with simple gas charging and minimal change to calling opcodes using new opcodes `RETURNDATASIZE` and `RETURNDATACOPY`. Handles similar to existing `calldata`, whereby after a call, return data is kept inside a virtual buffer from which the caller can copy it (or parts thereof) into memory, and upon the next call, the buffer is overwritten.
| Christian Reitwiessner                     | Core       | Final    | Metropolis Byzantinium
| https://github.com/ethereum/EIPs/pull/214[EIP-214]   | New opcode: `STATICCALL`. Permits non-state-changing calls to itself or other contracts whilst disallowing any modifications to state during the call (and its sub-calls, if present) to increase smart contract security and assure developers that re-entrancy bugs cannot arise from the call. Calls the child with `STATIC` flag set `true` for execution of child, causing exception to be thrown upon any attempts to make state-changing operations inside an execution instance where `STATIC` is set `true`, and resets flag once call returns.                                                                        | Vitalik Buterin, Christian Reitwiessner    | Core       | Final    | Metropolis Byzantinium
| https://github.com/ethereum/EIPs/issues/225[EIP-225]  | Rinkeby Testnet using Proof-of-Authority where blocks only mined by trusted signers    |     |        |     | Homestead
| https://github.com/ethereum/EIPs/blob/master/EIPS/eip-234.md[EIP-234]  | Add `blockHash` to JSON-RPC filter options    |  Micah Zoltu  | Interface       | Draft    |

| https://github.com/ethereum/EIPs/blob/master/EIPS/eip-615.md[EIP-615]   | Subroutines and Static Jumps for the EVM | Greg Colvin             | Core       | Draft    |

| https://github.com/ethereum/EIPs/blob/master/EIPS/eip-616.md[EIP-616]   | SIMD Operations for the EVM | Greg Colvin             | Core       | Draft    |

| https://github.com/ethereum/EIPs/blob/master/EIPS/eip-681.md[EIP-681]   | ERC-681 URL Format for Transaction Requests | Daniel A. Nagy             | Interface       | Draft    |

| https://github.com/ethereum/EIPs/pull/669[EIP-649]   | Metropolis Difficulty Bomb Delay and Block Reward Reduction - Delay of the Ice Age (aka the Difficulty Bomb by 1 year), and reduction of the block reward from 5 to 3 ether. | Afri Schoedon, Vitalik Buterin             | Core       | Final    | Metropolis Byzantinium
| https://github.com/ethereum/EIPs/pull/658[EIP-658]   | Embedding transaction status code in receipts. Fetch and embed status field indicative of success or failure state to transaction receipts for callers, as was no longer able to assume the transaction failed if and only if (iff) it consumed all gas after the introduction of the `REVERT` opcode in EIP-140.
| Nick Johnson                               | Core       | Final    | Metropolis Byzantinium
| https://github.com/ethereum/EIPs/blob/master/EIPS/eip-706.md[EIP-706]                             | DEVp2p snappy compression                                                                    | Péter Szilágyi                             | Networking | Final    |
| https://github.com/ethereum/EIPs/issues/721[EIP-721]                             | ERC-721 Non-Fungible Token (NFT) Standard. It is a standard API that would allow smart contracts to operate as unique tradable non-fungible tokens (NFT) that may be tracked in standardised wallets and traded on exchanges as assets of value, similar to ERC-20. CryptoKitties was the first popularly-adopted implementation of a digital NFT in the Ethereum ecosystem.                                     | William Entriken, Dieter Shirley, Jacob Evans, Nastassia Sachs                            | Standard | Draft    |
| https://github.com/ethereum/EIPs/blob/master/EIPS/eip-758.md[EIP-758]   | Subscriptions and filters for transaction return data                         | Jack Peterson                    | Interface | Draft    |
| https://github.com/ethereum/EIPs/blob/master/EIPS/eip-801.md[EIP-801]   | ERC-801 Canary Standard                        | ligi                   | Interface | Draft    |
| https://github.com/ethereum/EIPs/issues/827[EIP-827]                             | ERC-827 A extension of the standard interface ERC20 for tokens with methods that allows the execution of calls inside transfer and approvals. This standard provides basic functionality to transfer tokens, as well as allow tokens to be approved so they can be spent by another on-chain third party. Also it allows to execute calls on transfers and approvals.                                     | Augusto Lemble                            | ERC | Draft    |
| https://github.com/ethereum/EIPs/issues/930[EIP-930]                             | ERC-930 The ES (Eternal Storage) contract is owned by an address that have write permissions. The storage is public, which means everyone has read permissions. It store the data on mappings, using one mapping per type of variable. The use of this contract allows the developer to migrate the storage easily to another contract if needed.                                     | Augusto Lemble                            | ERC | Draft    |
|===