---
tags: it 鐵人賽 30 天, Web 3, ethereum
---
# 從以太坊白皮書理解 web 3 概念 - Day3

## Ethereum 節點： 全節點，礦工節點，輕節點 Light Node， 歸檔節點 Archive Node

上一章節介紹了區塊鏈的基礎概念。

現在回過頭來看 Ethereum

Ethereum 是一個建構在區塊鏈上的能夠運行智能合約的平台

Ethereum 該如何達成這個目的呢？

## Ethereum Network

Ethereum Network 是由 Ethereum 節點所串列起來的網路


所謂 Ethereum 節點是指運行 ethereum 客戶端程式並且遵守 ethereum protocol 連結其他 ethereum 節點的執行個體，可以是一台是實體伺服器或是一台虛擬機器。

這些 Ethereum 節點運行的程式裡會包含用來運行智能合約的執行環境也就是 EVM(Ethereum Virtual Machine)，透過 EVM 執行智能合約並且把狀態紀錄在 blockchain 上。

## Ethereum Virtual Machine

Ethereum Virtual Machine (簡寫 EVM) 的職責是運行智能和約，本質是一個有限狀態機。



## Ethereum Account

Ethereum 的 blockchain 主要是用來紀錄 Ethereum Account 的狀態


**Ethereum Account** 分為以下兩種

| 類別 | 建立是否需要費用 | 能否以 Account 初始化 Transaction | Transaction 類別 |
| ------------------ | ---------------------------------- | --------------------------------------- | -------------------------------------- |
| EOA(外部持有) | 建立無需花費 | 可以 | EOA 彼此只能是 Ether/Token Transaction |
| Contract(智能合約) | 建立需要費用，因為需要佔用 Storage | 不能，只能根據輸入的 Transaction 來傳送 | 除了 EOA 能送的那些之外，還能建立 Contract|

Ethereum Account 狀態包含以下四個部份：


1. nonce: 是一個計數器，用來計算在在這個 account 送出過多少個 Transaction。避免重複傳送一樣的 Transaction。

2. balacne: 該 account 所擁有的貨幣數。以 wei 為單位。一個 Ether 等於 10^18 個 wei。

3. codeHash: 這個 code 用來對應 Contract Acoount 在 EVM 所執行程式碼的 hash。如果是 EOA，這個欄位是空字串的 hash。

4. storageRoot: 又稱為 storageHash，是一個長度 256 bit 的 hash 用來表示EVM 執行位置所在 Merkle 樹的 Root 節點資訊的 Hash。

這裡的 Account 都是已長度 42 字元的 16 進位表示，舉例來說: "0x5e97870f263700f46aa00d967821199b9bc5a120"。

EOA 是透過使用者非對稱加密的公鑰以 Ethereum 規範所產生的 Hash 值。

Contract Address 則是透過建立者的 address 與建立 contract 所產生的 nonce 結合在一起所產生的 Hash。

## EVM 如何運作


EVM 有兩個模式，透過 Ethereum api

當在唯讀模式時，會透過 EVM 執行 eth_call 執行 EVM 內對應的邏輯。

當在可寫入模式時，使用者會傳送 Transaction 給礦工節點。等礦工結點會循序指派 Transaction 給 EVM 處理。

EVM 將會驗證傳入的 Transaction ，然後在根據傳入的 Transaction 更改狀態

## Ethereum 節點介紹

Ethereum 節點前面提到是運行 ethereum 客戶端程式並且遵守 ethereum protocol 連接其他 Ethereum 結點的執行個體。

具體上， Ethereum 節點的具體負責項目如下：

Receive Transactions：接收來自 Dapp、錢包 或 其它節點 的交易資訊
Receive Blocks：從其它節點接收區塊資訊同步至最新的區塊高度
Validating：驗證新的區塊之正確性、驗證待處理交易之有效性
Executing：處理交易，進行運算並更改狀態值，打包成新區塊
Mining：用電腦算力來計算 Hash 值，最先找到 Hash 值出塊並廣播的礦工可以獲得區塊獎勵與所有交易之手續費（Gas）
Consensus：通過共識機制達成全網帳本之一致性或區塊重組（reorg）

以下根據節點不同功能來分類介紹：

### 全節點

全節點是擁有完整區塊鏈帳本資料的節點，具備獨立驗證的能力來確認交易之有效性。

具體來說全節點主要在處理下列四件事：

1. 儲存所有歷史交易資訊，資料公開透明
2. 監測礦工挖出來的新區塊，驗證其合法性後同步該區塊
3. 監測區塊鏈網路中的新交易資訊，驗證每個交易的合法性
4. 將驗證過的「交易／區塊資訊」廣播給全網路節點

一個節點只要下載了完整且最新的區塊鏈資料，穩定運行驗證交易和同步區塊資訊，那它就是一個全節點了。由於每一個全節點都保有全網資料，所以即使其中部分節點出現問題，例如斷網或被駭客攻擊，都不會影響整個區塊鏈網路的資料一致性。這即是「去中心化」記帳系統的優勢所在。

### 礦工節點

挖礦的過程即是將驗證過的待處理交易打包成新區塊，並以電腦算力來計算 「Hash 值」，最先找到 Hash 值成功出塊並廣播的礦工會獲得區塊獎勵與所有交易之手續費（gas）作為報酬。

礦工必須要運行全節點才能即時瀏覽區塊鏈歷史資料進行交易驗證，再將驗證通過的交易進行打包。因此，**所有礦工必定是全節點；然而全節點未必是礦工**，運行全節點的人未必會花費電腦算力去參與新區塊 Hash 值的運算來爭取區塊獎勵。

### 輕節點 Light Node

輕節點顧名思義即是輕量級的節點，具體定義是不儲存或維護完整的區塊鏈副本，只儲存最小量的狀態來作為發送或傳遞交易訊息的節點。至於輕節點究竟儲存了哪些狀態，我們得先透過下圖瞭解以太坊的資料結構：


圖片來源:[https://blog.ethereum.org/](https://blog.ethereum.org/)

#### Block Header and Body

以太坊的每個區塊主要分為 Header 和 Body 兩個部分存儲，Body 即是交易列表；Block Header 則較為複雜，包含了前個區塊的 Hash、時間戳及挖礦難度等相關參數。

在 Block Header 中採用一種名為 Merkle-Patricia Trie (MPT) 的核心資料結構來儲存區塊鏈資訊，可以理解為把帳本分割成無數個小的資料塊，每個資料塊像是一棵樹中的無數葉片，而我們把每兩個相鄰的葉片合併成一個字串，並算出該字串的 Hash 值。如此過程經過無數次後，最終如同所有樹枝歸向一個樹幹一般，會得到一個包含了所有區塊資料的 Hash 值，稱為「Merkle Root」。

#### 輕節點資訊

全節點儲存了所有區塊的 Block Header 與 Body（交易列表），而輕節點只儲存最小量的狀態：即「區塊標頭 Block Header」，藉此大幅降低儲存空間的需求。

#### 輕節點如何驗證交易
由於割捨掉區塊的 Body，即所有歷史的交易列表，因此當輕節點需要驗證某個交易的合法性時，具體做法為：

1. 向鄰近的全節點發起確認請求
2. 全節點收到請求後提供所需相關資訊供驗證

需要向全節點請求的原因是：假設有一個合約執行的交易，那麼便必須要有該合約部署時的原始碼（位在 Contract Created 之交易中）。由於該交易位於某個區塊之 Body，故輕節點必須要向全節點請求該合約之相關資訊方能進行交易驗證。

#### 輕節點的特色摘要
整體而言，輕節點大致上具備以下幾點特色：

* 只儲存每個區塊的區塊標頭 Block Header
* 不一定保持隨時在線（獲取最新的 Block Header 資訊）
* 根據需求可以只保存與自己相關的交易內容
* 無法驗證大多數交易的合法性，只能驗證與自己相關交易的合法性
* 無法驗證新區塊的正確性
* 只能檢測到當前的最長鏈，但無法知道哪條是最長合法鏈

由於輕節點必須要向全節點請求與交易驗證相關的 Block Body 資訊，那麼要怎麼知道全節點回傳的資訊是正確的呢？

這時就要回到以太坊的資料結構來談，前面提到輕節點為了減少儲存空間，而割捨掉 Block Body，僅保留作為驗證之用的 Block Header。由於存有已經驗證合法之 Block Header，因此當未來需要驗證相關交易時只要透過跟全節點請求相關的 Block Body 資訊即可進行驗證，不需要從頭驗證整個區塊。

#### Block Header 與交易驗證

輕節點能夠利用 Block Header 驗證交易的原因為： Block Header 中的 Merkle Root 即是由 Block Body 中的交易資訊經由雜湊演算法（Hash Algorithm）生成的「數位指紋（Digital Fingerprint）」，因此 Block Header 可以充分代表 Block Body 內的資訊。

Block Header 中的 Merkle-Patricia Trie 是一個生成 Hash 需要花費大量算力，但驗證非常迅速的結構。當輕節點收到全節點提供的資訊時，便能夠利用已有的 Block Header 相關訊息迅速驗證該資訊是否正確，進一步進行交易驗證。

### 歸檔節點 Archive Node

「歸檔節點」是在全節點的基礎之上，額外儲存了每個區塊高度的區塊狀態（個人帳戶與合約帳戶之當時餘額等資訊），即針對每個區塊高度當下的狀態進行快照並存檔。歸檔節點能讓你快速回到某個區塊高度去查詢當下狀態：例如你想要知道某一個帳戶在區塊高度 #5,000,000 的餘額時便會派上用場。

## 概念整理

今天介紹了 Ethereum 用來運行智能合約的機制 [EVM](https://zh.wikipedia.org/zh-tw/%E4%BB%A5%E5%A4%AA%E5%9D%8A%E8%99%9A%E6%8B%9F%E6%9C%BA)。
Ethereum 可以透過 ethereum api 來執行寫在 [EVM](https://zh.wikipedia.org/zh-tw/%E4%BB%A5%E5%A4%AA%E5%9D%8A%E8%99%9A%E6%8B%9F%E6%9C%BA) 上的智能合約，並且把狀態更新到鏈上。
## 參考文獻

[https://ethereum.org/en/developers/docs/](https://ethereum.org/en/developers/docs/)

[https://www.youtube.com/watch?v=HfTTbxQWWvg](https://www.youtube.com/watch?v=HfTTbxQWWvg)

[https://ethereum.org/en/developers/docs/accounts/#externally-owned-accounts-and-key-pairs/](https://ethereum.org/en/developers/docs/accounts/#externally-owned-accounts-and-key-pairs/)

[https://medium.com/pelith/ethereum-nodes-d3e07745d189](https://medium.com/pelith/ethereum-nodes-d3e07745d189)