| timezone |
|---|
Asia/Shanghai |
- 自我介绍 我是來自台灣的大三生，有過一些Solidity的基礎，想藉由這次的殘酷共學來推動自己學習更多以太坊底層的知識。
- 你认为你会完成本次残酷学习吗？ 會！
- TG 联系方式：@dundun326
今天是共學的第一天，主要的內容是著重在2024study group的week1，學習到了有關於一些以太坊的歷史和哲學心態的方面，沒想到居然和UNIX有關。 最重要的是這次終於了解圖靈完備是什麼意思了，簡單來說有圖靈完備就是可以跑所有圖靈機可以運行的工作，更白話就是可以做到所以有函數可以描述的工作，而以太坊具有圖靈完備性，可以運行智能合約，相較之下的bitcoin 網路就做不到。 晚點希望可以把影片看完，目前看到比較熟悉的密碼學了，另外好像可以跑一下上面code的test，應該滿有趣的。
###節點 今天進一步瞭解「節點」的定義：在操作成面有執行層和共識層，一個客戶端可以去執行其中一項或是兩個都執行，那運行這個客戶端並且連上網路的電腦就會被叫做的節點(node)。 ###測試 再來就是測試，一個成熟的應用一定需要經過大量的測試去確保他的安全性，在week1中有提到許多測試的工具可以做使用。 week1的最後總結了許多額外連結，有需要可以去看看。 也把week1的影片全部看完了。
今天時間比較少，看了一下week2的影片，他蠻詳細的講解了共識層和執行層的邏輯，我覺得滿有趣的，希望晚一點可以有時間繼續。
今天把week2影片看得差不多，但對於responsibility、p2p、snap還不太了解。可能需要去看一下文件。
今天決定將重要的內容給GPT統整
Modified Merkle-Patricia Trie (MPT) 是以太坊使用的資料結構，用來儲存區塊鏈的 狀態(state)，也就是帳戶資訊、合約儲存（storage）等。它結合了 Merkle Trie（梅克爾樹）和 Patricia Trie（壓縮前綴樹）的特性，以提供 高效的鍵值對查詢、插入、刪除，同時確保數據可驗證性。
-
Merkle Tree 結構
- 讓狀態能夠被「加密摘要」保護，確保資料完整性。
- 任何節點的改變都會影響到根雜湊（root hash），使區塊鏈能快速檢查篡改。
-
Patricia Trie 結構
- 避免標準 Trie 結構的冗長性，透過 壓縮前綴（path compression） 優化空間使用。
-
Modified（修改過的）特性
- 針對以太坊的應用，特別優化了存取效率，例如節點類型的設計（leaf node, extension node, branch node）。
以太坊主要有 三種 MPT，分別用來管理：
-
世界狀態樹（State Trie）
- 錢包帳戶（externally owned account, EOA）
- 智能合約帳戶
- 每個帳戶的 balance、nonce、code hash、storage root
-
儲存樹（Storage Trie）
- 智能合約的 storage 是一個單獨的 trie，每個合約都有自己的儲存樹。
-
交易樹（Transaction Trie） & 收據樹（Receipt Trie）
- 存交易資訊與交易執行結果的收據。
- 有 16 個子節點（對應 16 進制鍵的 0~F）。
- 有一個額外的值欄位，當鍵完整匹配時存儲數據。
- 儲存完整鍵的 剩餘部分（剩餘前綴） 及對應值。
- 用於 終端鍵值對（key-value） 的存儲。
- 儲存一段 共享的鍵前綴，避免冗餘。
- 指向下一個節點（可能是 Branch 或 Leaf）。
✅ 節省空間：Patricia Trie 壓縮了前綴，減少存儲需求。
✅ 高效查詢：Trie 結構允許 O(log(n)) 的鍵值查詢，適合區塊鏈高頻讀取需求。
✅ 可驗證性：Merkle Tree 讓資料完整性可被驗證，支援 輕客戶端（Light Client） 快速驗證區塊內容。
✅ 資料不變性：每次狀態改變時，新的 MPT 根哈希會改變，確保篡改可檢測。
❌ 插入、刪除成本較高：由於哈希運算，每次修改都需要更新樹的路徑。
❌ 存儲效率問題：節點是基於 RLP（Recursive Length Prefix）編碼，需要額外的存儲與解析成本。
❌ 遍歷困難：不像標準的鍵值存儲結構，不能高效遍歷所有鍵值。
{
"cat": "meow",
"dog": "bark",
"cow": "moo"
}這些鍵（key）會先轉換成十六進制表示：
"cat" → 636174
"dog" → 646F67
"cow" → 636F77MPT 會壓縮公共前綴來構建樹：
Root
├── 63 (c)
│ ├── 61 (a) → "meow"
│ ├── 6F (o)
│ ├── 77 (w) → "moo"
├── 64 (d) → 6F67 (og) → "bark"TODO : responsibility、p2p、snap 今天看了執行層的詳細架構，但覺得有點太難了，所以用GPT幫我生重點。
以下是針對原文中第 2、3、4、5 部分的詳細解釋：
區塊結構
- 每個區塊作為區塊鏈中的基本單位，包含區塊頭、交易列表以及其他相關元數據。
- 區塊頭： 記錄了父區塊的哈希值、時間戳、難度指標、狀態樹根、交易樹根等關鍵參數。這些資訊不僅保證了區塊內容的不可篡改性，也成為驗證區塊合法性的依據。
區塊處理流程
- 交易收集與排序： 節點從網絡中收集各筆交易，並根據一定的排序規則（例如手續費優先等）進行整理，形成待打包的交易池。
- 區塊生成： 節點根據共識規則，選取合適的交易打包成區塊，同時計算與該區塊相關的狀態轉換。
- 區塊驗證： 新生成的區塊會經過嚴格的驗證程序，包括檢查區塊頭資訊、每筆交易的合法性以及狀態轉換的正確性。
- 鏈接與確認： 驗證通過後，新區塊被其他節點認可並與之前的區塊鏈進行鏈接，從而形成完整且連續的區塊鏈。
概念說明
- 狀態轉換函數定義了從當前區塊狀態到下一個區塊狀態的轉變規則。每筆交易在執行時，都會根據該函數更新賬戶狀態、智能合約存儲以及其他鏈上數據。
細節內容
- 交易執行： 每筆交易可能涉及調用智能合約、轉賬或合約部署等操作，其執行結果將改變系統內部狀態。
- 錯誤處理： 當交易執行過程中遇到錯誤（如資金不足或非法操作）時，系統會根據預設規則進行回滾或標記錯誤，確保不會影響其他交易的正確執行。
- 數據一致性： 嚴格定義的狀態轉換邏輯確保所有節點在處理相同交易時，能夠得出一致的狀態更新結果，從而維持整個網絡的一致性。
EVM 基本架構
- 指令集與計算模型： Ethereum 虛擬機（EVM）是一個基於堆疊運算的虛擬機，內置完整的指令集，用以執行智能合約的邏輯。
- Gas 機制： 為防止無限循環和濫用資源，EVM 在執行每條指令時都需消耗一定的 gas，且由交易發起者提前支付。這不僅保護了網絡資源，同時也激勵開發者優化合約代碼。
執行流程
- 智能合約執行： 當合約被調用時，EVM 根據合約代碼逐條執行指令，同時根據設定的 gas 限制進行資源控制。
- 存儲與運算： 在合約執行過程中，EVM 負責讀取、寫入及計算相關數據，並維護一個內部存儲空間來管理合約狀態。
- 結果與回執： 執行結束後，EVM 生成交易回執，其中記錄了執行結果、剩餘 gas 以及在執行過程中產生的事件或錯誤信息。
交易結構
- 每筆交易包含發起方、接收方、轉賬金額、gas 限制與價格以及數據負載（通常用於智能合約的調用）等信息。
- 交易中必須包含數字簽名，以證明發起者的身份和交易的合法性。
驗證步驟
- 格式檢查： 首先檢查交易數據結構是否符合規範要求。
- 簽名驗證： 通過公鑰密碼學方法驗證數字簽名，確保交易來自合法的發起者。
- Gas 檢查： 驗證交易所設定的 gas 限制是否合理，並確認發起者賬戶中有足夠餘額支付所需費用，以防濫用網絡資源。
- 狀態轉換檢查： 在執行交易前後，對比系統狀態變化是否符合預期，從而防止任何非法或不當的狀態更新。
在以太坊及其他區塊鏈中，RPC（Remote Procedure Call，遠端程序呼叫）是一種協定，允許應用程式與區塊鏈節點進行互動。透過RPC，開發者可以查詢區塊鏈資料、發送交易，以及與智能合約互動。
以太坊實現了JSON-RPC規範，這是一種無狀態、輕量級的遠端程序呼叫協定，使用JSON作為資料格式。以太坊客戶端通常支援多種傳輸協定，包括HTTP、WebSocket和IPC，這使得開發者能夠以多種方式與以太坊網路互動。
在區塊鏈生態系統中，RPC是去中心化應用程式（DApps）與區塊鏈網路溝通的關鍵橋樑。開發者可以使用RPC介面查詢區塊資訊、發送交易請求，或與智能合約進行互動。例如，當使用者在DApp中發起交易時，應用程式會透過RPC將交易資訊傳送至區塊鏈節點，節點再將交易廣播至整個網路。
總而言之，RPC在以太坊和其他區塊鏈中扮演著關鍵角色，提供了應用程式與區塊鏈網路之間的溝通管道，支持各種區塊鏈操作的實現。
在以太坊架構中，「responsibility」主要描述各系統組件或層級在協議中各自承擔的明確角色與任務。例如：
-
層級職責分離
自從以太坊完成合併（The Merge）之後，整個系統被劃分為兩大層級：- 執行層（Execution Layer）：負責處理交易、執行智能合約以及維護帳戶狀態。
- 共識層（Consensus Layer）：負責區塊排序、驗證以及確保全網達成共識。
這種分工確保各層均有其明確「責任」，有助於系統模組化、易於維護和未來獨立升級。
-
節點責任
每個以太坊節點在網路中均承擔著驗證交易與區塊、維護最新網路狀態以及通過 P2P 網絡傳播數據的責任，從而確保網絡的安全性與去中心化運作。
總體而言，「responsibility」體現了以太坊中「各司其職」的設計理念，是確保系統穩定運作與安全的重要基石。
「P2P」是「peer-to-peer」的縮寫，代表以太坊中節點間進行直接通信的去中心化網路架構，主要特點包括：
-
無中心化伺服器
以太坊網絡中的節點直接互相連接，無需依賴單一中心伺服器。透過分散式網絡協議（如 devp2p），各節點可以互相傳送交易、區塊及狀態資訊，這增強了網絡的抗審查能力與容錯性。 -
節點發現與數據傳輸
節點能自動發現其他節點並建立安全加密的通信鏈路，確保數據（例如交易與區塊資訊）能夠迅速且可靠地在整個網絡中廣播與傳播。 -
網絡健壯性
去中心化的 P2P 結構能有效防止單點故障和集中式攻擊，即使部分節點下線，整個網絡依然可以穩定運作並維持共識。
在以太坊中，「snap」通常指的是snap sync（快照同步）機制，這是一種用來加速新節點同步的技術手段：
-
狀態快照機制
由於以太坊的歷史數據量龐大，若從創世區塊開始逐筆重放交易來構建最新狀態，所需時間和資源極高。snap sync 機制允許新節點直接從其他已同步的節點下載一份包含當前狀態（如帳戶餘額、智能合約存儲等）的快照，從而跳過重放所有歷史交易的步驟。 -
快速驗證與更新
節點下載快照後，會進行必要的驗證以確保資料正確無誤。隨後，新節點只需處理快照之後的新區塊，迅速趕上最新狀態，從而大幅縮短同步時間。 -
提升網絡擴展性
snap sync 使得新節點能夠更快接入網絡，降低了同步過程中的計算與存儲負擔，這對於應對網絡規模不斷增長具有重要意義。
總結來看，「snap」在以太坊中代表利用狀態快照進行快速同步的一種高效機制，使新節點無需從頭重放全部歷史交易即可快速獲得最新狀態，從而促進了網絡的高效擴展與穩定運作。
今天開始共識層的學習，並且對week2的note做了總結。 下面是一個綜合總結，幫助你快速掌握這些內容的重點：
1. 主要內容
- 區塊驗證流程
- 區塊構建機制
- 狀態轉換函式（STF）、EVM 架構與 P2P 協議
2. 區塊驗證流程
-
共識層（CL）：
- 透過
process_execution_payload函式進行初步檢查（如父區塊哈希、時間戳、前一個 randao 值等）， - 將執行 payload 發送給執行層（EL）進一步驗證。
notify_new_payload函式則負責傳送資料給 EL，但實際狀態轉換由 EL 處理。
- 透過
-
執行層（EL）：
- 執行狀態轉換函式（STF），主要步驟包括：
- 驗證區塊頭（如 gas 限制變動、區塊連續性、EIP-1559 基本費更新等），
- 應用交易：遍歷並執行區塊內的所有交易（遇到錯誤則整塊區塊無效）。
- 驗證結果回傳給共識層，若無效，區塊則被拒絕。
- 執行狀態轉換函式（STF），主要步驟包括：
3. 區塊構建流程
-
主要參數：
- 區塊環境資訊（時間戳、區塊號、前一區塊、基本費等）
- 交易池：維持一個依照 gas 價值排序的交易列表
- 最新的 StateDB（狀態資料庫）
-
構建步驟：
- 追蹤 gas 使用與累積交易： 持續加入交易直至達到 gas 限制。
- 從交易池中挑選最佳交易： 透過
Pop()方法依據每單位 gas 價值排序取出最高價值的交易執行。 - Finalize 組裝區塊： 將所有執行過的交易及區塊相關資訊整合成一個完整的區塊。
-
Q&A 重點：
- 交易池內部排序確保區塊構建者可獲得最大收益；
- 交易的有效性主要由交易池先行檢查，只有無效交易會被拒絕；
- 加密交易池仍是未來可能解決的挑戰，現階段存在部分資訊洩漏風險。
4. 進一步技術細節：STF、EVM 與 P2P 協議
-
狀態轉換函式（STF）：
- 透過 go-ethereum 原始碼中的多個函式（如
newPayload、insertBlockWithoutSetHead、insertChain）實現，驗證並更新區塊狀態。 - 每筆交易執行後會生成相應的 Receipt 來記錄執行結果。
- 透過 go-ethereum 原始碼中的多個函式（如
-
EVM 架構：
- 包含程式碼、PC、堆疊、記憶體、剩餘 gas、區塊與交易上下文等。
- 不同指令（算術、位元、環境、控制流程、堆疊與系統指令）的成本決定，反映了網路運行的負載與效率考量。
-
P2P 協議：
- 以太坊採用 devp2p 協議進行節點間的通訊，涵蓋歷史數據、待處理交易與狀態同步（snap sync）。
- 協議中設有多種方法以確保數據正確性，並利用弱主觀性檢查點驗證下載的狀態資料。
這個總結重點整理了區塊驗證、區塊構建以及相關底層技術（STF、EVM、P2P）的核心概念與流程，幫助你快速回顧整個內容的邏輯與細節。