| timezone |
|---|
Asia/Taipei |
- 自我介绍: Hello，大家好，第一次參加以太坊協議殘酷共學，之前做過私有鏈。期待對以太坊底層協議有更深刻的理解。
- 你认为你会完成本次残酷学习吗？會的
EPF #1 week 協定的基本原則 該協定會隨著時間而改變，每次網路升級都會帶來新的改進。儘管架構不斷變化，但它的演變反映了一些基本原則。具體可總結如下： 簡單性、通用性、模組化、無歧視性、敏捷性 實施的方式 執行層（EL）或共識層（CL）的實作稱為客戶端。運行此客戶端並連接到網路的電腦稱為節點。因此，一個節點是一對積極參與網路的 EL 和 CL客戶端 開發週期 新功能或變更的傳統開發週期是Idea - Research - Development - Testing - Adoption。然而，在這個循環的任何時候都可能出現問題，導致需要從頭開始再次迭代。
改進方式 使用EIP 流程來協調來自社區的想法和提議的變更.
觀看EL 的設計概念 狀態轉換函數（STF）
- 所需參數：
- parent block（需要驗證從父區塊到目前區塊的轉換邏輯）
- current block
- StateDB（最後已知的有效狀態，儲存與父區塊相關的所有狀態資料）
- 回傳結果：
- 更新 stateDB（包括當前區塊的資訊）
- 錯誤（如果函數失敗且沒有更新 StateDB）
- 步驟 1：驗證標題
- 如果發生以下情況，則可能發生錯誤
- gas 限制變化超過前一個區塊的 1/1024
- 區塊編號不是連續的
- EIP-1559 基本費用未正確更新
- ETC。
- 步驟 2：如果標題正確，則套用 Tx
- 遍歷區塊交易，透過虛擬機器執行每個交易，如果交易正確則更新狀態
- 如果發生以下情況，則可能發生錯誤
- 存在無效交易，則整個區塊無效，狀態不會更新
區塊建立函數
- 參數部分
- 環境 (Environment)： 這部分提供了區塊生成過程所必需的基本背景信息，例如當前時間、區塊鏈中的位置（區塊編號）、前一個區塊的資訊以及區塊費用的基準值。這些數據對確保區塊的正確生成和區塊鏈的連續性非常重要。
- 交易池 (Tx pool)： 這是一個臨時儲存待執行交易的集合。系統會根據交易的價值（例如支付的手續費）來排序，確保高價值交易能夠優先被執行，從而最大化收益。
- 狀態資料庫 (StateDB)： 此資料庫保存著所有與賬戶、合約狀態等相關的信息，任何交易執行後都可能對這些狀態做出改變，故需在區塊生成後更新。
- 返回結果
- 區塊 (Block)： 生成的新區塊，包含了一系列已執行的交易及相關區塊資訊。
- 更新後的狀態資料庫 (Updated StateDB)： 反映了所有交易執行後的最新狀態，這是整個區塊鏈運行過程中的核心數據。
- 錯誤 (Error)： 在區塊生成或交易執行過程中可能出現錯誤，這一部分用來返回和記錄相關錯誤信息。 步驟詳解 步驟 1：追蹤 gas 使用量並存儲交易
- 在這一階段，系統不斷從交易池中選取交易，並將它們加入到待生成的區塊中，同時監控累積的 gas 消耗。當達到預定的 gas 限制時，就不再添加新的交易，確保區塊不會因為交易數量過多而超出計算或存儲的限制。 這裡提到的「gas」是 Ethereum 用來衡量計算工作量的單位，每個區塊都有一個最大 gas 限制（例如 3000 萬），以防止過多計算影響網絡穩定性。 步驟 2：從交易池中取得並執行最佳交易
- 使用 Pop() 方法從排序好的交易池中取出最有價值的交易。這裡的「最佳」交易通常是指那些支付較高手續費的交易，因為礦工（或驗證者）傾向於優先處理這些交易以獲取更多收益。 交易通過 Ethereum 的虛擬機（VM）進行執行，執行結果會更新狀態資料庫，並將成功執行的交易記錄到區塊中。 如果在執行過程中某筆交易被發現無效（例如簽名錯誤或執行失敗），系統會記錄錯誤，但仍會繼續處理後續交易，直到沒有足夠的 gas 或交易池被清空。 步驟 3：使用 Finalize 函數組裝區塊
- 最後，Finalize 函數會根據已執行的交易列表以及區塊相關的資訊（如區塊頭資料）生成一個完整且可驗證的區塊。這個區塊會被添加到區塊鏈上，成為區塊鏈歷史的一部分。
狀態轉移函數
newPayload 函數：
起點與檢查： 此函數是從共識層（CL）觸發的，代表一個新的區塊提案進入流程。執行層（EL）在這個階段會檢查區塊的完整性，例如確認區塊數據的正確性與一致性。 流程延伸： 當初步檢查通過後，流程深入到 insertBlockWithoutSetHead，正式啟動區塊的鏈上添加操作。 insertBlockWithoutSetHead 函數：
執行與驗證： 這個函數負責將區塊中的交易執行，並對區塊內容進行各項驗證。驗證通過後，將區塊及其交易狀態寫入資料庫。 區別與後續： 與 insertChain 函數不同，此處不會立即更新正則鏈狀態，而是需要後續額外的 SetCanonical 操作來最終確定區塊在正則鏈中的地位。這種分步驟的設計有助於更細緻地控制區塊的驗證與最終確認過程。 insertChain 函數及其子流程：
verifyHeaders： 在正式執行區塊之前，首先必須對區塊頭進行嚴格檢查。這包括： EIP-1559 屬性： 確保區塊頭中的 gas 限制符合網絡規範。 其他檢查項目： 如 gas 限制、實際使用的 gas、區塊生成時間等，確保整體數據正確無誤。 驗證通過後，區塊才被認為是有效的，可進入下一步執行。 Process 函數： 參數與執行環境： 該函數需要區塊數據、狀態資料庫以及虛擬機配置。這些參數共同確保區塊在執行過程中能夠正確地影響狀態。 狀態轉移機制： Geth 使用 state_processor 來完成狀態轉移。這個過程將每筆交易依次執行，更新狀態資料庫，並計算出新的狀態。 後續更新： 當所有交易都處理完畢後，系統會更新其他關鍵指標，最終把區塊的最終狀態寫入區塊鏈，確保區塊成為鏈上歷史的一部分。
Digital scarcity 區塊鏈創造了一種製造數位稀缺性的方法，這在以前是難以實現的。 因此，數位稀缺性的這個特性可以用於在數位領域模擬各種實體資產，例如：貨幣、代幣、產權等等。
製造數位稀缺性的方法：創建具有稀缺性的數位貨幣的示例 目標： 創建具有稀缺性的數位貨幣 單位： 代幣 (Coins) 稀缺性： 任何時候都只有 N 個代幣。並且用戶不能花費超過他們擁有的代幣。 需要移除單一信任營運商並最小化信任。 在任何時間點，即使有一些節點輸出錯誤，只要大多數節點對輸出狀態有相同的看法，協議就可以達成共識並繼續運行。
Byzantine fault tolerance 分散式網路處理拜占庭容錯（BFT）。 如果更多節點帶來更高的安全性，那麼我們會希望擁有更多的節點。然而，在開放和分散式的系統中，節點可能存在問題（例如：硬體故障、訊息遺失、錯誤、攻擊等），這會導致與共識不同的錯誤輸出。 拜占庭容錯（BFT）是一個系統的屬性，它能夠抵抗源自拜占庭將軍問題的故障類別。這意味著即使一些節點發生故障或惡意行為，BFT 系統也能夠繼續運行。 因此，我們需要有一定的容錯能力，使系統能夠持續運行。
Bitcoin 實BFT 比特幣被認為是第一個解決拜占庭將軍問題的方案。 該系統可以擴展到無限的節點數量。 開放和無需許可的參與。 使用 PoW 機制來達成共識(Bitcoin)
比特幣的狀態機複製 輸入： 交易 (Tx)（組織在區塊中），用於花費比特幣。 輸出： 比特幣賬本的當前狀態。 使用密碼學來減少可能的狀態空間 數位簽章： 使用密碼學來驗證交易的真實性。 父哈希： 每個新區塊都必須包含前一個區塊的哈希值。
以太坊從 PoW 轉向 PoS PoW -> PoS 的本質 從女巫攻擊保護的外生信號（工作量）轉變為系統內的內生信號（權益）。
背後的考量
- 對 PoW 的能源使用擔憂。
- 對 PoW 的激勵擔憂：與 PoW 相比，PoS 的協議內信號允許懲罰和獎勵。 以太坊共識機制 驗證者 (Validators)： 協議內共識參與者。
- 成為共識驗證者
- 用戶需要鎖定 32 個 ETH 並將其發送到 EVM 中的存款合約，這將在 CL 層（共識層）中被看到。 責任
- 進行證明 (attestation)： 即驗證者對鏈的狀態進行密碼學簽名。 不同類型的證明
- LMD GHOST 投票： 驗證者證明信標鏈的頭部 (beacon chain head)。
- Casper FFG 投票： 驗證者證明當前 epoch 中的檢查點 (checkpoint)。
關鍵概念
-
Slot (槽位) 每 12 秒鐘會產生一個新的槽位，每個槽位都會有一個區塊。 在每個槽位內，它被分為 3 個階段，每個階段消耗 4 秒。而一個槽位中最關鍵的時刻是在 t=4 秒時的證明 (attestation) 截止時間。（Paradigm 博客）
-
Epoch (時代/紀元) 每個時代 (epoch) 有 32 個槽位。創建時代背後的原因是為了降低共識處理的頻率，這樣就不需要在每個槽位都發生共識處理。 較重的處理通常在時代邊界完成，包括：罰沒 (slashing)、獎勵資訊等。 時代邊界區塊 (Epoch Boundary Blocks, EBB) 也可以被認為與檢查點 (checkpoints) 同義。（The Beacon Chain Ethereum 2.0 explainer）
-
Committee (委員會) 網路內的驗證者將被隨機分配到不同的委員會中。 每個驗證者在每個時代 (epoch) 會進行一次證明 (attestation)。驗證者被分配到的確切槽位是由協議通過 RANDAO 決定的。
-
Finality (最終性) 最終性意味著一筆交易 (tx) 是一個區塊的一部分，而這個區塊是不可更改的。 Justification (驗證/確認): 當一個時代 (epoch) 結束時，如果其檢查點 (checkpoint) 收集了 2/3 超過三分之二的多數投票，則該檢查點將被驗證 (justified)。 Finality (最終性): 當一個檢查點 (checkpoint) 被驗證 (justified) 時，前一個已經被驗證 (justified) 的檢查點就變成最終的 (finalized)。
執行層測試
EVM 測試 主要目的： 驗證每個執行客戶端是否都遵守規範，否則可能會在鏈中引起潛在的正向分叉。 設定： 為每個客戶端提供相同的輸入，並期望在給定相同的環境、前狀態、硬分叉激活規則的情況下，從每個客戶端獲得相同的輸出。 測試的重要特徵： 前狀態 (Pre-state)： 以太坊鏈的完整組成，由包含餘額、nonce 值、程式碼和儲存的帳戶組成。 環境 (Environment)： 根據測試的類型，環境可以指定諸如時間戳、先前的 RANDAO、區塊號、先前的區塊哈希值、總 gas 限制、基礎費用和硬分叉激活時間等內容。 交易 (Transaction(s))： 發送到區塊鏈的消息，用於在區塊鏈上執行操作，其中包含發起和目標帳戶、以太幣價值、gas 限制和資料。 後狀態 (Post-state)： 由修改或創建的帳戶組成的結果狀態。
EVM 測試 - 測試填充 測試填充的定義： 將測試原始碼編譯成一個「fixture」(測試夾具) 的過程，這個 fixture 可以被任何執行客戶端所使用。 測試填充 vs 客戶端單元測試： 對於測試填充來說，完全相同的測試可以在任何客戶端實作中執行。而對於客戶端單元測試來說，不同的客戶端團隊之間的測試可能會有所不同。
特點： 所有不同格式的測試夾具 (test fixtures) 都是單一的 JSON 檔案，可供每個客戶端使用。
-
狀態測試 使用狀態根 (state root) 進行驗證： 給定相同的前狀態 (pre-state) 和相同的交易 (transaction)，不同的客戶端應該返回相同的狀態根 (state root)。 狀態根 (State root)： 安全地提交狀態的所有內容的密碼學計算結果。
-
模糊差異狀態測試 (Fuzzy differential state testing) 在設計好的交易之上，將使用 FuzzyVM 工具添加模糊測試的智能合約程式碼。 仍然期望不同的客戶端返回相同的狀態根 (state root)。
-
區塊鏈測試 (Blockchain testing) 由於我們在執行客戶端上檢查的並非所有內容都是 EVM 執行的一部分，例如先前區塊的執行結果、1559 基礎費用等，因此也需要完整的區塊測試來驗證客戶端的執行。
-
區塊鏈負面測試 (Blockchain negative testing) 在某個時間點添加一個無效區塊，以檢查客戶端是否可以為了設計目的拒絕該無效區塊，返回到先前的有效區塊並聲稱它是鏈頭 (chain head)。