--- # System prepended metadata title: 從以太坊白皮書理解 web 3 概念 - Day3 tags: [' Web 3', it 鐵人賽 30 天, ' ethereum'] --- --- tags: it 鐵人賽 30 天, Web 3, ethereum --- # 從以太坊白皮書理解 web 3 概念 - Day3 ## Ethereum 節點： 全節點，礦工節點，輕節點 Light Node， 歸檔節點 Archive Node 上一章節介紹了區塊鏈的基礎概念。 現在回過頭來看 Ethereum Ethereum 是一個建構在區塊鏈上的能夠運行智能合約的平台 Ethereum 該如何達成這個目的呢？ ## Ethereum Network Ethereum Network 是由 Ethereum 節點所串列起來的網路 ![](https://i.imgur.com/YzIUV2z.png) 所謂 Ethereum 節點是指運行 ethereum 客戶端程式並且遵守 ethereum protocol 連結其他 ethereum 節點的執行個體，可以是一台是實體伺服器或是一台虛擬機器。 這些 Ethereum 節點運行的程式裡會包含用來運行智能合約的執行環境也就是 EVM(Ethereum Virtual Machine)，透過 EVM 執行智能合約並且把狀態紀錄在 blockchain 上。 ## Ethereum Virtual Machine Ethereum Virtual Machine (簡寫 EVM) 的職責是運行智能和約，本質是一個有限狀態機。 ![](https://i.imgur.com/CVmTPxG.png) ![https://cypherpunks-core.github.io/ethereumbook_zh/images/evm-architecture.png](https://cypherpunks-core.github.io/ethereumbook_zh/images/evm-architecture.png) ## Ethereum Account Ethereum 的 blockchain 主要是用來紀錄 Ethereum Account 的狀態 ![https://ethereum.org/static/19443ab40f108c985fb95b07bac29bcb/302a4/accounts.png](https://ethereum.org/static/19443ab40f108c985fb95b07bac29bcb/302a4/accounts.png) **Ethereum Account** 分為以下兩種 | 類別 | 建立是否需要費用 | 能否以 Account 初始化 Transaction | Transaction 類別 | | ------------------ | ---------------------------------- | --------------------------------------- | -------------------------------------- | | EOA(外部持有) | 建立無需花費 | 可以 | EOA 彼此只能是 Ether/Token Transaction | | Contract(智能合約) | 建立需要費用，因為需要佔用 Storage | 不能，只能根據輸入的 Transaction 來傳送 | 除了 EOA 能送的那些之外，還能建立 Contract| Ethereum Account 狀態包含以下四個部份： ![](https://i.imgur.com/0n10K07.png) 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 如何運作 ![](https://i.imgur.com/nWx3lMK.png) EVM 有兩個模式，透過 Ethereum api 當在唯讀模式時，會透過 EVM 執行 eth_call 執行 EVM 內對應的邏輯。 當在可寫入模式時，使用者會傳送 Transaction 給礦工節點。等礦工結點會循序指派 Transaction 給 EVM 處理。 EVM 將會驗證傳入的 Transaction ，然後在根據傳入的 Transaction 更改狀態 ![](https://i.imgur.com/pYuXj41.png) ## 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://miro.medium.com/max/1400/0*vvstXw73nDKDOZvv.png](https://miro.medium.com/max/1400/0*vvstXw73nDKDOZvv.png) 圖片來源:[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)