以太坊客戶端設計

A. 區塊鏈和智能合約，以太坊開發，183位開發者整理，知識體系匯總

在以太坊上開發應用程序的可用工具、組件、模式和平台的指南。

此列表的創建是由 ConsenSys 的產品經理推動的，他們認為需要在新的和有經驗的區塊鏈開發人員之間更好地共享工具、開發模式和組件。

開發智能合約

智能合約語言

構架

IDE

其他工具

測試區塊鏈網路

測試以太水龍頭

前端以太坊 API

後端以太坊 API

引導程序/開箱即用工具

以太坊 ABI（應用程序二進制介面）工具

以太坊客戶端

貯存

Mahuta - 具有附加搜索功能的 IPFS 存儲服務，以前稱為 IPFS-Store

OrbitDB - IPFS 之上的去中心化資料庫

JS IPFS API - IPFS HTTP API 的客戶端庫，用 JavaScript 實現

TEMPORAL - 易於使用的 API 到 IPFS 和其他分布式/去中心化存儲協議

PINATA - 使用 IPFS 的最簡單方法

消息傳遞

測試工具

安全工具

監控

其他雜項工具

Cheshire - CryptoKitties API 和智能合約的本地沙箱實現，可作為 Truffle Box 使用

ERCs-以太坊評論請求存儲庫

ERC-20 - 可替代資產的原始令牌合約

ERC-721 - 不可替代資產的令牌標准

ERC-777 - 可替代資產的改進令牌標准

ERC-918 - 可開采令牌標准

流行的智能合約庫

可擴展性

支付/狀態通道

等離子體

側鏈

POA橋

POA 橋用戶界面

POA 橋梁合同

ZK-SNARK

ZK-STARK

預構建的 UI 組件

以上內容，來自git庫：

github.com/ConsenSys/ethereum-developer-tools-list

我是魚歌，一個在深圳創業的全棧程序員，主攻區塊鏈，元宇宙和智能合約，附加小程序和app開發。

[祈禱]

B. DApp開發入門

本文僅介紹以太坊系列的DApp開發，其他鏈原理差不太多。

MetaMask安裝完成並運行後，可以在Chrome控制台列印 MetaMask注入的window.ethereum對象

關於ethereum對象，我們只需要關心 ethereum.request 就足夠了，MetaMask 使用 ethereum.request(args) 方法 來包裝 RPC API。這些 API 基於所有以太坊客戶端公開的介面。 簡單來說錢包交互的大部分操作都是由 request() 方法實現，通過傳入不同的方法名來區分。

⚠️ 即使ethereum對象中提供了chainId，isMetaMask，selectAddress屬性，我們也不能完全相信這些屬性，他們是不穩定或不標准，不建議使用。我們可以通過上面說的request方法，拿到可靠的數據 。

錢包通過method方法名，進行對應的實現 以獲取錢包地址為例

調用 ethereum.request({ method: "eth_requestAccounts" }) ，錢包實現了該方法，那麼就可以拿到錢包的地址了。

MetaMask注入的 window.ethereum 就是一個Provider，一個RPC節點也是一個Provider，通過Provider，我們有了訪問區塊鏈的能力。 在連接到錢包的情況下，通常使用錢包的Provider就可以了， ethers.providers.Web3Provider(ethereum)

如果只需要查詢一些區塊鏈數據，可以使用EtherscanProvider 和 InfuraProvider 連接公開的 第三方節點服務提供商 。JsonRpcProvider 和 IpcProvider 允許連接到我們控制或可以訪問的以太坊節點。

獲取當前賬戶余額

獲取最新區塊號

其他RPC操作，可以通過 JSON-RPC 查看。

通過 ethers.js 可以連接ERC20的合約，合約編譯後會生成ABI，合約部署後，會生成合約地址，開發者通過 ABI和合約地址 ，對合約發送消息。

合約中的方法大致分為兩種： 視圖方法(免費)，非視圖方法(消耗Gas) ，可以通過ABI查看方法類型。

⚠️ ERC20需要多加關注的是 Approve() 方法以及 transfer() 和 transferFrom() 的區別 ，授權過的代幣，被授權的那一方，可以通過調用 transferFrom() 方法,轉走你授權數量內的代幣，所以授權是一個很危險的操作，假設你授權了一個不良的合約，那你會面臨授權的token被轉走的風險，即使你沒有泄露私鑰助記詞。

便利三方庫： web3-react use-wallet

文檔： doc.metamask.io ethers

C. 怎麼在windows下啟動以太坊java客戶端ethereumj

以太坊源碼go-ethereum怎麼運行
安裝基於緩賣腔MIPS的linux頭文件
$ cd $PRJROOT/kernel
$ tar -xjvf linux-2.6.38.tar.bz2
$ cd linux-2.6.38

在指定路徑下創建include文件夾，用來存放相關頭文件配高。
$ mkdir -p $TARGET_PREFIX/include

保證linux源碼是干擾衫凈的。
$ make mrproper

生成需要的頭文件。
$ make ARCH=mips headers_check
$ make ARCH=mips INSTALL_HDR_PATH=dest headers_install

將dest文件夾下的所有文件復制到指定的include文件夾內。
$ cp -rv dest/include/* $TARGET_PREFIX/include

最後刪除dest文件夾
$ rm -rf dest
$ ls -l $TARGET_PREFIX/include

D. 輕用戶是什麼意思

什麼是輕客戶端？為什麼你需要了解它

播報文章

在以太坊的案例中，過去只有一種類型的節點，現在稱為全節點。這個軟體負責驗證和轉播網路上的交易和區塊。由於無信任環境（開放的互聯網）和區塊鏈的性質，每個全節點需要下載並驗證每個區塊，所以就是在每個區塊中驗證每一筆交易。

Parity Ethereum 和 Geth 這兩個最受歡迎的以太坊客戶端，今天都可以在一台中等功率的筆記本電腦上運行。然而，下載和驗證整個區塊鏈的區塊是需要時間和資源的。例如，現在需要使用 SSD 來完全同步以太坊區塊鏈。HDD 無法跟上每秒所需的輸入/輸出操作。

全節點使用案例

現在，組織和個人運行全節點是因為他們的業務需要。想想礦工、區塊瀏覽器、交易所。個人用戶可能希望運行全節點，因為這是與區塊鏈交互的最安全方式。在一個更小的范圍內，他們也可能是純粹的利他主義來幫助網路。7*24 小時全天候的運行一個全節點需要良好的知識和資源水平，大多數用戶不願意投資是可以理解的。除了礦工，沒有什麼內置的激勵來運行一個全節點，盡管這部分基礎設施對網路至關重要。

因此，大多數與區塊鏈交互的用戶，不管是否自願，都會使用一個中心的基礎設施。最流行的軟體錢包默認依賴於第三方託管的節點。這些客戶端連接到遠程節點，並以非密碼驗證的方式完全信任其響應。它的積極方面顯然是增強了用戶體驗，因為這些錢包的用戶不需要運行自己的節點。但是，它們被迫信任第三方節點。默認情況下，Metamask、MyEtherWallet 和 MyCrypto 連接到遠程節點，但如果用戶願意，仍然允許他們連接到自己的本地節點。這不是 Jaxx 或 Exos 錢包的情況，它們默認連接到遠程節點，而沒有連接到用戶自己的本地節點的選項。這里沒有提到移動錢包，因為手機無法運行全節點。

像 Infura 這樣的公司致力於運行全節點，並免費提供給那些需要它們的人。抽象出同步一個全節點的麻煩，允許任何用戶輕松地訪問區塊鏈。這樣的解決方案有助於讓更多用戶能夠訪問以太坊。然而，盡管這一舉措是對生態系統的一個重大補充，但它代表了一個中心化的單一失敗點，與去中心化的區塊鏈理念背道而馳。直到幾個月前，錢包開發商還沒有其他選擇。

「我們的目標是創建一個兼容不同程度『輕』的協議，從幾乎不存儲任何內容的客戶端到幾乎存儲所有內容的客戶端。」

— PIP, Parity Light Protocol（https://wiki.parity.io/The-Parity-Light-Protocol-%28PIP%29）

輕量級替代方案：輕客戶端

輕客戶端或輕節點是連接到全節點與區塊鏈交互的軟體。與全節點對應節點不同，輕節點不需要運行 24/7 或讀寫區塊鏈上的大量信息。事實上，輕客戶端並不直接與區塊鏈交互，而是使用全節點作為中介。輕客戶端依賴於全節點去執行許多操作，從請求最新的區塊頭到請求帳戶中的余額。

輕客戶端協議的設計方式允許它們以最小信任的方式與全節點交互。這是一個需要理解的關鍵方面，因此讓我們回顧一下以太坊區塊鏈的基礎知識：

1. 普通用戶使用全節點、輕節點或受信任的遠程節點在網路上發送交易。

2. 全節點從網路上的對等節點接收交易，檢查這些交易的有效性，並將它們廣播到網路。

3. 礦工是連接到特定軟體的全節點。他們像一個普通的全節點一樣從網路上接收和驗證交易，但是會額外投入大量的精力來尋找問題的解決方案，才會被允許生成下一個區塊。礦工使用的全節點通過應該將哪個區塊添加到區塊鏈並構建在其上達成共識。任何在其上構建了至少 10 個塊的塊都被認為是安全的，因為它包含的交易被還原的概率非常低。

現在，回到我們的輕客戶端。作為起點，輕客戶端需要下載區塊鏈的區塊頭。輕客戶端不需要為它對全節點的每個請求去信任全節點。這是因為區塊頭包含一個名為 Merkle 樹根的信息。Merkle 樹根就是區塊鏈上有賬戶余額和智能合約存儲的所有信息的指紋。如果有任何微小的信息改變，這個指紋也會改變。假設大多數礦工都是誠實的，那麼區塊頭和他們所包含的指紋就被認為是有效的。輕客戶端可能需要從全節點請求信息，例如特定帳戶的余額。輕客戶端知道每個區塊的指紋，就可以驗證全節點給出的答案是否與其擁有的指紋匹配。這是一個強有力的工具，可以在事先不知情的情況下證明信息的真實性。

由於輕客戶端需要發送多個請求來執行簡單的操作，因此所需的總體網路帶寬高於全節點的帶寬。另一方面，所需的資源和存儲量比全節點的資源和存儲量低幾個數量級，同時實現了非常高的安全級別。只需要大約 100MB 的存儲空間和較低的計算能力，輕節點就可以在移動設備上運行！這意味著手機可以以去中心化的方式訪問區塊鏈。

因為只需要一個全節點的一小部分信息，所以一個輕節點可以更快地與區塊鏈同步。目前，將整個以太坊主網區塊鏈同步，輕客戶端大約只需要一個小時，但節點同步超過幾秒對任何應用程序來說都太多了。為輕客戶端開發的解決方案可以快速與區塊鏈頂部同步，盡管這些解決方案通常需要權衡。目前，輕客戶端在其代碼中內置了一個可信的區塊鏈檢查點。正因為如此，客戶端只需要下載最新的區塊頭文件，就可以在幾秒鍾內實現同步。輕客戶端用戶信任客戶端開發人員集成有效的檢查點。這種折衷被認為是可以接受的，因為用戶已經需要信任客戶端實現的開發人員。為了以去中心化的方式快速執行同步，Parity Technologie 目前開發了一種替代解決方案，允許輕客戶端以與全節點類似的方式執行扭曲同步（https://wiki.parity.io/Warp-Sync）。

未來，輕客戶端會遍布各地。 — Marty McFly

輕客戶端的挑戰

輕客戶端非常適合主流應用，例如發送一些交易和驗證帳戶余額。對輕客戶端的主要批評是，輕客戶端不能直接幫助網路。它們不驗證除自己需要的信息以外的任何其他信息，也不從網路向其他對等節點提供或轉播信息，它們使用來自全節點的資源，而不提供任何的回報。

與全節點相比，輕客戶端提供了更好的最終用戶體驗，同時允許最終用戶以去中心化的和安全的方式訪問區塊鏈。關鍵是要找到一種激勵個人和機構的方式去運行全節點、服務輕節點、懲罰服務壞數據的惡意全節點。使輕客戶端可持續發展的一種方法是讓他們對全節點發出的每個請求執行小額支付。在不久的將來，輕客戶端將在以太坊分片中扮演重要角色，讓驗證節點快速同步不同的分片。輕客戶端還可用於報告惡意參與者（驗證節點或 plasma 許可權）。輕客戶端對全節點的激勵是一個活躍的研究領域，因為激勵是生態系統穩定的關鍵。

有一些很有前途的想法可以讓輕客戶端快速同步，同時避免前面提到的折衷方案。一種想法是允許全節點提供最新的已知區塊頭的零知識證明（例如，zk-STARK https://eprint.iacr.org/2018/046.pdf）。然後，輕客戶端可以驗證它並與鏈的頂部同步，而無需事先知道區塊鏈的狀態。

總之，在短期內，輕客戶端將成為去中心化應用程序的骨幹，這對用戶友好的分布式生態系統來說是一個非常好的消息。

E. 選擇以太坊客戶端

有很多以太坊客戶端供我們選擇。我們推薦在開發和部署時使用不同的客戶端。

我們推薦 Ganache ，它是一個運行在你個人電腦上的私有連客戶端。它是 truffle 套種中的一部分，
Ganache 將智能合約和交易放在前台並且中心化，從而簡化了dapp的開發。使用 Ganache 你可以
快速查看你們的應用是如何影響區塊鏈的，並且對賬戶，余額，智能合約創建以及燃料消費進行自省。

Ganache 運行在 http://127.0.0.1:7545 。默認會創建是個賬戶，重啟後賬戶依然不會變，
當然也可以手動隨機賬戶，你也可以用你自己的賬戶。

我們同樣也推薦使用 truffle develop ，它是 truffle 內置的開發鏈工具。不需要任何的額外安裝，
你要使用它只需要一條命令行即可：

Truffle Develop 運行在 http://127.0.0.1:9545 上。

當你的開發機沒有圖形界面時就無法直接使用 Ganache ，而 Ganache CLI 就提供了沒有圖形界面系統的能力。

有很多官方和非官網的以太坊客戶端你可以選擇。以下是部分:

F. 以太坊源碼分析--p2p節點發現

節點發現功能主要涉及 Server Table udp 這幾個數據結構，它們有獨自的事件響應循環，節點發現功能便是它們互相協作完成的。其中，每個以太坊客戶端啟動後都會在本地運行一個 Server ，並將網路拓撲中相鄰的節點視為 Node ，而 Table 是 Node 的容器， udp 則是負責維持底層的連接。下面重點描述它們中重要的欄位和事件循環處理的關鍵部分。

PrivateKey - 本節點的私鑰，用於與其他節點建立時的握手協商
Protocols - 支持的所有上層協議
StaticNodes - 預設的靜態 Peer ，節點啟動時會首先去向它們發起連接，建立鄰居關系
newTransport - 下層傳輸層實現，定義握手過程中的數據加密解密方式，默認的傳輸層實現是用 newRLPX() 創建的 rlpx ，這不是本文的重點
ntab - 典型實現是 Table ，所有 peer 以 Node 的形式存放在 Table
ourHandshake - 與其他節點建立連接時的握手信息，包含本地節點的版本號以及支持的上層協議
addpeer － 連接握手完成後，連接過程通過這個通道通知 Server

Server 的監聽循環，啟動底層監聽socket，當收到連接請求時，Accept後調用 setupConn() 開始連接建立過程

Server的主要事件處理和功能實現循環

Node 唯一表示網路上的一個節點

IP - IP地址
UDP/TCP - 連接使用的UDP/TCP埠號
ID - 以太坊網路中唯一標識一個節點，本質上是一個橢圓曲線公鑰(PublicKey)，與 Server 的 PrivateKey 對應。一個節點的IP地址不一定是固定的，但ID是唯一的。
sha - 用於節點間的距離計算

Table 主要用來管理與本節點與其他節點的連接的建立更新刪除

bucket - 所有 peer 按與本節點的距離遠近放在不同的桶(bucket)中，詳見之後的 節點維護
refreshReq - 更新 Table 請求通道

Table 的主要事件循環，主要負責控制 refresh 和 revalidate 過程。
refresh.C - 定時(30s)啟動Peer刷新過程的定時器
refreshReq - 接收其他線程投遞到 Table 的 刷新Peer連接 的通知，當收到該通知時啟動更新，詳見之後的 更新鄰居關系
revalidate.C - 定時重新檢查以連接節點的有效性的定時器，詳見之後的 探活檢測

udp 負責節點間通信的底層消息控制，是 Table 運行的 Kademlia 協議的底層組件

conn - 底層監聽埠的連接
addpending － udp 用來接收 pending 的channel。使用場景為：當我們向其他節點發送數據包後(packet)後可能會期待收到它的回復，pending用來記錄一次這種還沒有到來的回復。舉個例子，當我們發送ping包時，總是期待對方回復pong包。這時就可以將構造一個pending結構，其中包含期待接收的pong包的信息以及對應的callback函數，將這個pengding投遞到udp的這個channel。 udp 在收到匹配的pong後，執行預設的callback。
gotreply - udp 用來接收其他節點回復的通道，配合上面的addpending，收到回復後，遍歷已有的pending鏈表，看是否有匹配的pending。
Table - 和 Server 中的ntab是同一個 Table

udp 的處理循環，負責控制消息的向上遞交和收發控制

udp 的底層接受數據包循環，負責接收其他節點的 packet

以太坊使用 Kademlia 分布式路由存儲協議來進行網路拓撲維護，了解該協議建議先閱讀 易懂分布式 。更權威的資料可以查看 wiki 。總的來說該協議：

源碼中由 Table 結構保存所有 bucket ， bucket 結構如下

節點可以在 entries 和 replacements 互相轉化，一個 entries 節點如果 Validate 失敗，那麼它會被原本將一個原本在 replacements 數組的節點替換。

有效性檢測就是利用 ping 消息進行探活操作。 Table.loop() 啟動了一個定時器（0~10s），定期隨機選擇一個bucket，向其 entries 中末尾的節點發送 ping 消息，如果對方回應了 pong ，則探活成功。

Table.loop() 會定期（定時器超時）或不定期（收到refreshReq）地進行更新鄰居關系（發現新鄰居），兩者都調用 doRefresh() 方法，該方法對在網路上查找離自身和三個隨機節點最近的若干個節點。

Table 的 lookup() 方法用來實現節點查找目標節點，它的實現就是 Kademlia 協議，通過節點間的接力，一步一步接近目標。

當一個節點啟動後，它會首先向配置的靜態節點發起連接，發起連接的過程稱為 Dial ，源碼中通過創建 dialTask 跟蹤這個過程

dialTask表示一次向其他節點主動發起連接的任務

在 Server 啟動時，會調用 newDialState() 根據預配置的 StaticNodes 初始化一批 dialTask ， 並在 Server.run() 方法中，啟動這些這些任務。

Dial 過程需要知道目標節點( dest )的IP地址，如果不知道的話，就要先使用 recolve() 解析出目標的IP地址，怎麼解析？就是先要用藉助 Kademlia 協議在網路中查找目標節點。

當得到目標節點的IP後，下一步便是建立連接，這是通過 dialTask.dial() 建立連接

連接建立的握手過程分為兩個階段，在在 SetupConn() 中實現
第一階段為 ECDH密鑰建立 ：

第二階段為協議握手,互相交換支持的上層協議

如果兩次握手都通過，dialTask將向 Server 的 addpeer 通道發送 peer 的信息

G. 以太坊架構是怎麼樣的

以太坊最上層的是DApp。它通過Web3.js和智能合約層進行交換。所有的智能合約都運行在EVM（以太坊虛擬機）上，並會用到RPC的調用。在EVM和RPC下面是以太坊的四大核心內容，包括：blockChain, 共識演算法，挖礦以及網路層。除了DApp外，其他的所有部分都在以太坊的客戶端里，目前最流行的以太坊客戶端就是Geth（Go-Ethereum）

H. 怎麼接以太坊公鏈

建立連接以接儒以太坊公鏈。
一、1、以太坊客戶端下載，注意：需翻牆，下載版本為1.8.23-stable，否則可能出現與以太坊錢包客戶端存在不匹配問題。
2、以太坊錢包客戶端下載。
3、安裝以太坊客戶端。
二、私有鏈創建：創建創世區塊。
三、安裝並啟動以太坊錢包客戶端。

I. 011：Ethash演算法|《ETH原理與智能合約開發》筆記

待字閨中開發了一門區塊鏈方面的課程：《深入淺出ETH原理與智能合約開發》，馬良老師講授。此文集記錄我的學習筆記。

課程共8節課。其中，前四課講ETH原理，後四課講智能合約。
第四課分為三部分：

這篇文章是第四課第一部分的學習筆記：Ethash演算法。

這節課介紹的是以太坊非常核心的挖礦演算法。

在介紹Ethash演算法之前，先講一些背景知識。其實區塊鏈技術主要是解決一個共識的問題，而共識是一個層次很豐富的概念，這里把范疇縮小，只討論區塊鏈中的共識。

什麼是共識？

在區塊鏈中，共識是指哪個節點有記賬權。網路中有多個節點，理論上都有記賬權，首先面臨的問題就是，到底誰來記帳。另一個問題，交易一定是有順序的，即誰在前，前在後。這樣可以解決雙花問題。區塊鏈中的共識機制就是解決這兩個問題，誰記帳和交易的順序。

什麼是工作量證明演算法

為了決定眾多節點中誰來記帳，可以有多種方案。其中，工作量證明就讓節點去算一個哈希值，滿足難度目標值的勝出。這個過程只能通過枚舉計算，誰算的快，誰獲勝的概率大。收益跟節點的工作量有關，這就是工作量證明演算法。

為什麼要引入工作量證明演算法？

Hash Cash 由Adam Back 在1997年發表，中本聰首次在比特幣中應用來解決共識問題。

它最初用來解決垃圾郵件問題。

其主要設計思想是通過暴力搜索，找到一種Block頭部組合（通過調整nonce）使得嵌套的SHA256單向散列值輸出小於一個特定的值（Target）。

這個演算法是計算密集型演算法，一開始從CPU挖礦，轉而為GPU，轉而為FPGA，轉而為ASIC，從而使得算力變得非常集中。

算力集中就會帶來一個問題，若有一個礦池的算力達到51%，則它就會有作惡的風險。這是比特幣等使用工作量證明演算法的系統的弊端。而以太坊則吸取了這個教訓，進行了一些改進，誕生了Ethash演算法。

Ethash演算法吸取了比特幣的教訓，專門設計了非常不利用計算的模型，它採用了I/O密集的模型，I/O慢，計算再快也沒用。這樣，對專用集成電路則不是那麼有效。

該演算法對GPU友好。一是考慮如果只支持CPU，擔心易被木馬攻擊；二是現在的顯存都很大。

輕型客戶端的演算法不適於挖礦，易於驗證；快速啟動

演算法中，主要依賴於Keccake256 。

數據源除了傳統的Block頭部，還引入了隨機數陣列DAG（有向非循環圖）（Vitalik提出）

種子值很小。根據種子值生成緩存值，緩存層的初始值為16M，每個世代增加128K。

在緩存層之下是礦工使用的數據值，數據層的初始值是1G，每個世代增加8M。整個數據層的大小是128Bytes的素數倍。

框架主要分為兩個部分，一是DAG的生成，二是用Hashimoto來計算最終的結果。

DAG分為三個層次，種子層，緩存層，數據層。三個層次是逐漸增大的。

種子層很小，依賴上個世代的種子層。

緩存層的第一個數據是根據種子層生成的，後面的根據前面的一個來生成，它是一個串列化的過程。其初始大小是16M，每個世代增加128K。每個元素64位元組。

數據層就是要用到的數據，其初始大小1G，現在約2個G，每個元素128位元組。數據層的元素依賴緩存層的256個元素。

整個流程是內存密集型。

首先是頭部信息和隨機數結合在一起，做一個Keccak運算，獲得初始的單向散列值Mix[0]，128位元組。然後，通過另外一個函數，映射到DAG上，獲取一個值，再與Mix[0]混合得到Mix[1]，如此循環64次，得到Mix[64]，128位元組。

接下來經過後處理過程，得到 mix final 值，32位元組。（這個值在前面兩個小節《 009：GHOST協議 》、《 010：搭建測試網路 》都出現過）

再經過計算，得出結果。把它和目標值相比較，小於則挖礦成功。

難度值大，目標值小，就越難（前面需要的 0 越多）。

這個過程也是挖礦難，驗證容易。

為防止礦機，mix function函數也有更新過。

難度公式見課件截圖。

根據上一個區塊的難度，來推算下一個。

從公式看出，難度由三部分組成，首先是上一區塊的難度，然後是線性部分，最後是非線性部分。

非線性部分也叫難度炸彈，在過了一個特定的時間節點後，難度是指數上升。如此設計，其背後的目的是，在以太坊的項目周期中，在大都會版本後的下一個版本中，要轉換共識，由POW變為POW、POS混合型的協議。基金會的意思可能是使得挖礦變得沒意思。

難度曲線圖顯示，2017年10月，難度有一個大的下降，獎勵也由5個變為3個。

本節主要介紹了Ethash演算法，不足之處，請批評指正。

J. 以太坊是什麼丨以太坊開發入門指南

以太坊是什麼丨以太坊開發入門指南
很多同學已經躍躍欲試投入到區塊鏈開發隊伍當中來，可是又感覺無從下手，本文將基於以太坊平台，以通俗的方式介紹以太坊開發中涉及的各晦澀的概念，輕松帶大家入門。
以太坊是什麼
以太坊（Ethereum）是一個建立在區塊鏈技術之上， 去中心化應用平台。它允許任何人在平台中建立和使用通過區塊鏈技術運行的去中心化應用。
對這句話不理解的同學，姑且可以理解為以太坊是區塊鏈里的Android，它是一個開發平台，讓我們就可以像基於Android Framework一樣基於區塊鏈技術寫應用。
在沒有以太坊之前，寫區塊鏈應用是這樣的：拷貝一份比特幣代碼，然後去改底層代碼如加密演算法，共識機制，網路協議等等（很多山寨幣就是這樣，改改就出來一個新幣）。
以太坊平台對底層區塊鏈技術進行了封裝，讓區塊鏈應用開發者可以直接基於以太坊平台進行開發，開發者只要專注於應用本身的開發，從而大大降低了難度。
目前圍繞以太坊已經形成了一個較為完善的開發生態圈：有社區的支持，有很多開發框架、工具可以選擇。
智能合約
什麼是智能合約
以太坊上的程序稱之為智能合約， 它是代碼和數據(狀態)的集合。
智能合約可以理解為在區塊鏈上可以自動執行的（由事件驅動的）、以代碼形式編寫的合同（特殊的交易）。
在比特幣腳本中，我們講到過比特幣的交易是可以編程的，但是比特幣腳本有很多的限制，能夠編寫的程序也有限，而以太坊則更加完備（在計算機科學術語中，稱它為是「圖靈完備的」），讓我們就像使用任何高級語言一樣來編寫幾乎可以做任何事情的程序（智能合約）。
智能合約非常適合對信任、安全和持久性要求較高的應用場景，比如：數字貨幣、數字資產、投票、保險、金融應用、預測市場、產權所有權管理、物聯網、點對點交易等等。
目前除數字貨幣之外，真正落地的應用還不多（就像移動平台剛開始出來一樣），相信1到3年內，各種殺手級會慢慢出現。
編程語言：Solidity
智能合約的默認的編程語言是Solidity，文件擴展名以.sol結尾。
Solidity是和JavaScript相似的語言，用它來開發合約並編譯成以太坊虛擬機位元組代碼。
還有長像Python的智能合約開發語言：Serpent，不過建議大家還是使用Solidity。
Browser-Solidity是一個瀏覽器的Solidity IDE, 大家可以點進去看看，以後我們更多文章介紹Solidity這個語言。
運行環境：EVM
EVM（Ethereum Virtual Machine）以太坊虛擬機是以太坊中智能合約的運行環境。
Solidity之於EVM，就像之於跟JVM的關系一樣，這樣大家就容易理解了。
以太坊虛擬機是一個隔離的環境，在EVM內部運行的代碼不能跟外部有聯系。
而EVM運行在以太坊節點上，當我們把合約部署到以太坊網路上之後，合約就可以在以太坊網路中運行了。
合約的編譯
以太坊虛擬機上運行的是合約的位元組碼形式，需要我們在部署之前先對合約進行編譯，可以選擇Browser-Solidity Web IDE或solc編譯器。
合約的部署
在以太坊上開發應用時，常常要使用到以太坊客戶端（錢包）。平時我們在開發中，一般不接觸到客戶端或錢包的概念，它是什麼呢？
以太坊客戶端（錢包）
以太坊客戶端，其實我們可以把它理解為一個開發者工具，它提供賬戶管理、挖礦、轉賬、智能合約的部署和執行等等功能。
EVM是由以太坊客戶端提供的。
Geth是典型的開發以太坊時使用的客戶端，基於Go語言開發。 Geth提供了一個互動式命令控制台，通過命令控制台中包含了以太坊的各種功能（API）。Geth的使用我們之後會有文章介紹，這里大家先有個概念。
Geth控制台和Chrome瀏覽器開發者工具里的面的控制台是類似，不過是跑在終端里。
相對於Geth，Mist則是圖形化操作界面的以太坊客戶端。
如何部署
智能合約的部署是指把合約位元組碼發布到區塊鏈上，並使用一個特定的地址來標示這個合約，這個地址稱為合約賬戶。
以太坊中有兩類賬戶：
· 外部賬戶
該類賬戶被私鑰控制（由人控制），沒有關聯任何代碼。
· 合約賬戶
該類賬戶被它們的合約代碼控制且有代碼與之關聯。
和比特幣使用UTXO的設計不一樣，以太坊使用更為簡單的賬戶概念。
兩類賬戶對於EVM來說是一樣的。
外部賬戶與合約賬戶的區別和關系是這樣的：一個外部賬戶可以通過創建和用自己的私鑰來對交易進行簽名，來發送消息給另一個外部賬戶或合約賬戶。
在兩個外部賬戶之間傳送消息是價值轉移的過程。但從外部賬戶到合約賬戶的消息會激活合約賬戶的代碼，允許它執行各種動作（比如轉移代幣，寫入內部存儲，挖出一個新代幣，執行一些運算，創建一個新的合約等等）。
只有當外部賬戶發出指令時，合同賬戶才會執行相應的操作。
合約部署就是將編譯好的合約位元組碼通過外部賬號發送交易的形式部署到以太坊區塊鏈上（由實際礦工出塊之後，才真正部署成功）。
運行
合約部署之後，當需要調用這個智能合約的方法時只需要向這個合約賬戶發送消息（交易）即可，通過消息觸發後智能合約的代碼就會在EVM中執行了。
Gas
和雲計算相似，佔用區塊鏈的資源（不管是簡單的轉賬交易，還是合約的部署和執行）同樣需要付出相應的費用（天下沒有免費的午餐對不對!）。
以太坊上用Gas機制來計費，Gas也可以認為是一個工作量單位，智能合約越復雜（計算步驟的數量和類型，佔用的內存等），用來完成運行就需要越多Gas。
任何特定的合約所需的運行合約的Gas數量是固定的，由合約的復雜度決定。
而Gas價格由運行合約的人在提交運行合約請求的時候規定，以確定他願意為這次交易願意付出的費用：Gas價格（用以太幣計價） * Gas數量。
Gas的目的是限制執行交易所需的工作量，同時為執行支付費用。當EVM執行交易時，Gas將按照特定規則被逐漸消耗，無論執行到什麼位置，一旦Gas被耗盡，將會觸發異常。當前調用幀所做的所有狀態修改都將被回滾， 如果執行結束還有Gas剩餘，這些Gas將被返還給發送賬戶。
如果沒有這個限制，就會有人寫出無法停止（如：死循環）的合約來阻塞網路。
因此實際上（把前面的內容串起來），我們需要一個有以太幣余額的外部賬戶，來發起一個交易（普通交易或部署、運行一個合約），運行時，礦工收取相應的工作量費用。
以太坊網路
有些著急的同學要問了，沒有以太幣，要怎麼進行智能合約的開發？可以選擇以下方式：
選擇以太坊官網測試網路Testnet
測試網路中，我們可以很容易獲得免費的以太幣，缺點是需要發很長時間初始化節點。
使用私有鏈
創建自己的以太幣私有測試網路，通常也稱為私有鏈，我們可以用它來作為一個測試環境來開發、調試和測試智能合約。
通過上面提到的Geth很容易就可以創建一個屬於自己的測試網路，以太幣想挖多少挖多少，也免去了同步正式網路的整個區塊鏈數據。
使用開發者網路(模式)
相比私有鏈，開發者網路(模式)下，會自動分配一個有大量余額的開發者賬戶給我們使用。
使用模擬環境
另一個創建測試網路的方法是使用testrpc，testrpc是在本地使用內存模擬的一個以太坊環境，對於開發調試來說，更方便快捷。而且testrpc可以在啟動時幫我們創建10個存有資金的測試賬戶。
進行合約開發時，可以在testrpc中測試通過後，再部署到Geth節點中去。
更新：testrpc 現在已經並入到Truffle 開發框架中，現在名字是Ganache CLI。
Dapp：去中心化的應用程序
以太坊社區把基於智能合約的應用稱為去中心化的應用程序(DecentralizedApp)。如果我們把區塊鏈理解為一個不可篡改的資料庫，智能合約理解為和資料庫打交道的程序，那就很容易理解Dapp了，一個Dapp不單單有智能合約，比如還需要有一個友好的用戶界面和其他的東西。
Truffle
Truffle是Dapp開發框架，他可以幫我們處理掉大量無關緊要的小事情，讓我們可以迅速開始寫代碼-編譯-部署-測試-打包DApp這個流程。
總結
我們現在來總結一下，以太坊是平台，它讓我們方便的使用區塊鏈技術開發去中心化的應用，在這個應用中，使用Solidity來編寫和區塊鏈交互的智能合約，合約編寫好後之後，我們需要用以太坊客戶端用一個有餘額的賬戶去部署及運行合約（使用Truffle框架可以更好的幫助我們做這些事情了）。為了開發方便，我們可以用Geth或testrpc來搭建一個測試網路。
註：本文中為了方便大家理解，對一些概念做了類比，有些嚴格來不是准確，不過我也認為對於初學者，也沒有必要把每一個概念掌握的很細致和准確，學習是一個逐步深入的過程，很多時候我們會發現，過一段後，我們會對同一個東西有不一樣的理解。