上一章節介紹了區塊鏈的基礎概念。
現在回過頭來看 Ethereum
Ethereum 是一個建構在區塊鏈上的能夠運行智能合約的平台
Ethereum 該如何達成這個目的呢？
Ethereum Network 是由 Ethereum 節點所串列起來的網路
所謂 Ethereum 節點是指運行 ethereum 客戶端程式並且遵守 ethereum protocol 連結其他 ethereum 節點的執行個體，可以是一台是實體伺服器或是一台虛擬機器。
這些 Ethereum 節點運行的程式裡會包含用來運行智能合約的執行環境也就是 EVM(Ethereum Virtual Machine)，透過 EVM 執行智能合約並且把狀態紀錄在 blockchain 上。
Ethereum Virtual Machine (簡寫 EVM) 的職責是運行智能和約，本質是一個有限狀態機。
Ethereum 的 blockchain 主要是用來紀錄 Ethereum Account 的狀態
Ethereum Account 分為以下兩種
| 類別 | 建立是否需要費用 | 能否以 Account 初始化 Transaction | Transaction 類別 |
|---|---|---|---|
| EOA(外部持有) | 建立無需花費 | 可以 | EOA 彼此只能是 Ether/Token Transaction |
| Contract(智能合約) | 建立需要費用，因為需要佔用 Storage | 不能，只能根據輸入的 Transaction 來傳送 | 除了 EOA 能送的那些之外，還能建立 Contract |
Ethereum Account 狀態包含以下四個部份：
nonce: 是一個計數器，用來計算在在這個 account 送出過多少個 Transaction。避免重複傳送一樣的 Transaction。
balacne: 該 account 所擁有的貨幣數。以 wei 為單位。一個 Ether 等於 10^18 個 wei。
codeHash: 這個 code 用來對應 Contract Acoount 在 EVM 所執行程式碼的 hash。如果是 EOA，這個欄位是空字串的 hash。
storageRoot: 又稱為 storageHash，是一個長度 256 bit 的 hash 用來表示EVM 執行位置所在 Merkle 樹的 Root 節點資訊的 Hash。
這裡的 Account 都是已長度 42 字元的 16 進位表示，舉例來說: "0x5e97870f263700f46aa00d967821199b9bc5a120"。
EOA 是透過使用者非對稱加密的公鑰以 Ethereum 規範所產生的 Hash 值。
Contract Address 則是透過建立者的 address 與建立 contract 所產生的 nonce 結合在一起所產生的 Hash。
EVM 有兩個模式，透過 Ethereum api
當在唯讀模式時，會透過 EVM 執行 eth_call 執行 EVM 內對應的邏輯。
當在可寫入模式時，使用者會傳送 Transaction 給礦工節點。等礦工結點會循序指派 Transaction 給 EVM 處理。
EVM 將會驗證傳入的 Transaction ，然後在根據傳入的 Transaction 更改狀態
Ethereum 節點前面提到是運行 ethereum 客戶端程式並且遵守 ethereum protocol 連接其他 Ethereum 結點的執行個體。
具體上， Ethereum 節點的具體負責項目如下：
Receive Transactions：接收來自 Dapp、錢包 或 其它節點 的交易資訊
Receive Blocks：從其它節點接收區塊資訊同步至最新的區塊高度
Validating：驗證新的區塊之正確性、驗證待處理交易之有效性
Executing：處理交易，進行運算並更改狀態值，打包成新區塊
Mining：用電腦算力來計算 Hash 值，最先找到 Hash 值出塊並廣播的礦工可以獲得區塊獎勵與所有交易之手續費（Gas）
Consensus：通過共識機制達成全網帳本之一致性或區塊重組（reorg）
以下根據節點不同功能來分類介紹：
全節點是擁有完整區塊鏈帳本資料的節點，具備獨立驗證的能力來確認交易之有效性。
具體來說全節點主要在處理下列四件事：
一個節點只要下載了完整且最新的區塊鏈資料，穩定運行驗證交易和同步區塊資訊，那它就是一個全節點了。由於每一個全節點都保有全網資料，所以即使其中部分節點出現問題，例如斷網或被駭客攻擊，都不會影響整個區塊鏈網路的資料一致性。這即是「去中心化」記帳系統的優勢所在。
挖礦的過程即是將驗證過的待處理交易打包成新區塊，並以電腦算力來計算 「Hash 值」，最先找到 Hash 值成功出塊並廣播的礦工會獲得區塊獎勵與所有交易之手續費（gas）作為報酬。
礦工必須要運行全節點才能即時瀏覽區塊鏈歷史資料進行交易驗證，再將驗證通過的交易進行打包。因此，所有礦工必定是全節點；然而全節點未必是礦工，運行全節點的人未必會花費電腦算力去參與新區塊 Hash 值的運算來爭取區塊獎勵。
輕節點顧名思義即是輕量級的節點，具體定義是不儲存或維護完整的區塊鏈副本，只儲存最小量的狀態來作為發送或傳遞交易訊息的節點。至於輕節點究竟儲存了哪些狀態，我們得先透過下圖瞭解以太坊的資料結構：
圖片來源:https://blog.ethereum.org/
以太坊的每個區塊主要分為 Header 和 Body 兩個部分存儲，Body 即是交易列表；Block Header 則較為複雜，包含了前個區塊的 Hash、時間戳及挖礦難度等相關參數。
在 Block Header 中採用一種名為 Merkle-Patricia Trie (MPT) 的核心資料結構來儲存區塊鏈資訊，可以理解為把帳本分割成無數個小的資料塊，每個資料塊像是一棵樹中的無數葉片，而我們把每兩個相鄰的葉片合併成一個字串，並算出該字串的 Hash 值。如此過程經過無數次後，最終如同所有樹枝歸向一個樹幹一般，會得到一個包含了所有區塊資料的 Hash 值，稱為「Merkle Root」。
全節點儲存了所有區塊的 Block Header 與 Body（交易列表），而輕節點只儲存最小量的狀態：即「區塊標頭 Block Header」，藉此大幅降低儲存空間的需求。
由於割捨掉區塊的 Body，即所有歷史的交易列表，因此當輕節點需要驗證某個交易的合法性時，具體做法為：
需要向全節點請求的原因是：假設有一個合約執行的交易，那麼便必須要有該合約部署時的原始碼（位在 Contract Created 之交易中）。由於該交易位於某個區塊之 Body，故輕節點必須要向全節點請求該合約之相關資訊方能進行交易驗證。
整體而言，輕節點大致上具備以下幾點特色：
由於輕節點必須要向全節點請求與交易驗證相關的 Block Body 資訊，那麼要怎麼知道全節點回傳的資訊是正確的呢？
這時就要回到以太坊的資料結構來談，前面提到輕節點為了減少儲存空間，而割捨掉 Block Body，僅保留作為驗證之用的 Block Header。由於存有已經驗證合法之 Block Header，因此當未來需要驗證相關交易時只要透過跟全節點請求相關的 Block Body 資訊即可進行驗證，不需要從頭驗證整個區塊。
輕節點能夠利用 Block Header 驗證交易的原因為： Block Header 中的 Merkle Root 即是由 Block Body 中的交易資訊經由雜湊演算法（Hash Algorithm）生成的「數位指紋（Digital Fingerprint）」，因此 Block Header 可以充分代表 Block Body 內的資訊。
Block Header 中的 Merkle-Patricia Trie 是一個生成 Hash 需要花費大量算力，但驗證非常迅速的結構。當輕節點收到全節點提供的資訊時，便能夠利用已有的 Block Header 相關訊息迅速驗證該資訊是否正確，進一步進行交易驗證。
「歸檔節點」是在全節點的基礎之上，額外儲存了每個區塊高度的區塊狀態（個人帳戶與合約帳戶之當時餘額等資訊），即針對每個區塊高度當下的狀態進行快照並存檔。歸檔節點能讓你快速回到某個區塊高度去查詢當下狀態：例如你想要知道某一個帳戶在區塊高度 #5,000,000 的餘額時便會派上用場。
今天介紹了 Ethereum 用來運行智能合約的機制 EVM。
Ethereum 可以透過 ethereum api 來執行寫在 EVM 上的智能合約，並且把狀態更新到鏈上。
https://ethereum.org/en/developers/docs/
https://www.youtube.com/watch?v=HfTTbxQWWvg
https://ethereum.org/en/developers/docs/accounts/#externally-owned-accounts-and-key-pairs/
https://medium.com/pelith/ethereum-nodes-d3e07745d189
iThome鐵人賽
看影片追技術