| timezone |
|---|
UTC+8 |
- 自我介绍: Hi我是k66
- 你认为你会完成本次残酷学习吗？ 會
- 你的联系方式（推荐 Telegram）k66
- Consensus和Gasper
- 行前建議熟讀day2和day6的CL(共識層)
- 2020年論文，Combining GHOST and Casper
- 摘要: GASPER是PoS共識協議(proof-of-stake-based consensus protocol)
- 結合Casper FEG(終結裝置: 確保某些區塊不可逆轉)+LMD GHOST(分叉規則: 幫助節點在存在分叉情況下選擇正確的區塊鏈路徑)
- 目標：共識協議，有一定的安全性和可用性(certain safety and liveness claims)
- 介紹:
- Casper FFG（Friendly Finality Gadget）
- 這部分負責為區塊鏈中的某些區塊提供最終性，讓即使在資訊不完全的情況下，參與者也能確信這些區塊是正統鏈的一部分。Casper FFG本身並非完整的共識協議，而是一個可以搭配其他區塊鏈協議使用的“終結裝置”。
- LMD GHOST（Latest Message Driven Greediest Heaviest Observed SubTree）
- 這是一種分叉選擇規則，透過驗證者對區塊的投票（或稱 attestations）來決定哪條分叉應被選為正統鏈，類似於投票機制。
- 目標與架構
- 論文的目標是從理論上證明Gasper在安全性、合理活性（即使在惡劣條件下仍能達成共識）以及概率活性（在概率模型下新區塊能夠被快速最終化）的性質。後續章節中，作者將首先定義基本原語與背景知識（第2與第3節），然後詳細描述Gasper協議的具體設計（第4節），並在第5至第7節中給出形式化的證明，最後在第8節中比較Gasper與以太坊實際實現中的一些差異（例如延遲接收 attestations、延後區塊最終化、以及動態驗證者集合等），最後在第9節中提出對未來研究的展望。
- Casper FFG（Friendly Finality Gadget）
- 摘要: GASPER是PoS共識協議(proof-of-stake-based consensus protocol)
- 設定與目標
- 識協議與驗證者（Validators）的基本概念
- 協議被定義為一組演算法，供參與者（或稱驗證者）遵循，以在不可靠的網絡環境和可能存在惡意節點的情況下達成一致的狀態歷史。
- 驗證者是參與共識過程的主體，他們彼此通過點對點網絡進行通信，發送各種消息（例如區塊、投票/attestations等）。
- 區塊鏈的結構與消息傳播
- 區塊鏈被視為一棵以創世區塊（genesis block）為根的樹形結構，每個區塊都包含一個指向父區塊的引用。
- 當網絡中出現衝突時（例如兩個區塊彼此互斥），共識規則需要選出一條最終被接受的鏈。
- 為了描述這個過程，作者引入了「view」的概念：對於任何驗證者𝑉在某個時間 𝑇 所見的所有被接受消息的集合，這就是 𝑉 的 view，而網絡 view 則是所有驗證者所見消息的綜合。
-
依賴性與消息的接收
- 每個消息可能依賴於其他消息，這種依賴關係保證了驗證者在接收到某個消息之前，必須先接收到所有相關依賴消息。
- 區塊只有在其所有依賴（例如父區塊）都被接受後才被認為是有效的。
-
權益證明（Proof-of-Stake）模型
- 每個驗證者都有一個與其持有的抵押資產（stake）成正比的權重，這影響了他們在共識中的投票權重。
- 相對於傳統的工作量證明（Proof-of-Work），在權益證明中區塊產生成本較低，但需要額外的機制（如投票或 attestations）來防止出現惡意行為（例如雙重花費）。
- canonical chain: 正統鏈，也就是在所有可能的區塊鏈分叉中，透過分叉選擇規則選出來，被大家認定為正式歷史的那條鏈。這條鏈從創世區塊開始延伸到當前被認可的葉子區塊，代表了系統中一致認可的狀態轉換歷史。
-
拜占庭容錯與安全性目標
- 文中假設在系統中，拜占庭（Byzantine）行為的驗證者數量不超過總數的 1/3 （這個假設源自 PBFT 的理論）。
- 安全性：要求任何已經最終化的區塊（finalized block）都不會與其他區塊衝突；也就是說，所有最終化區塊應形成一條唯一且一致的鏈。
- 活性（Liveness）：保證區塊鏈能夠持續向前發展，不會因為某些原因而陷入死鎖。這裡又細分為：
- 合理活性（plausible liveness）：在任何情況下，只要有足夠數量的誠實驗證者存在，就總能夠推進區塊鏈。
- 概率活性（probabilistic liveness）：在概率模型下，新區塊最終化的過程具有高概率性，隨著時間推移，最終化成功的可能性逐漸提高。
-
時間、時隙與時代（Epoch）
- 為了在協議中引入時間概念，作者將時間分為固定長度的「時隙」（slots），並進一步將若干個時隙組成一個「時代」（epoch）。這種劃分方便了後續使用如 Casper FFG 這樣依賴固定時間檢查點（checkpoint）的機制。
- 時間劃分：時隙（Slot）與時代（Epoch）
- 協議中將時間劃分為固定長度的時隙（例如每個時隙12秒），而若干個連續的時隙（例如64個時隙）組成一個時代。
- 這種劃分有助於協議設計中使用檢查點（checkpoint）的概念，使得系統能夠在每個時代末確定一個“穩定”狀態，從而支持像Casper FFG這樣的終結機制。
- 同步性模型：同步、非同步與部分同步
- 同步系統（Synchronous）：在這種模型中，網絡有明確的消息傳遞上界，也就是說每條消息都能在預定的時間內傳遞到所有節點。
- 非同步系統（Asynchronous）：在這種模型中，沒有任何關於消息傳遞延遲的保證，消息可能會無限期延遲，這對共識協議來說是一大挑戰。
- 部分同步系統（Partially Synchronous）：這種模型結合了前兩者的特點，雖然在某段時間內消息可能延遲不定，但假設存在一個未知的時間點之後，所有消息都能在某個固定上界內送達。
- 協議設計中的考量
- 為了保證安全性和合理活性，作者在分析時不依賴嚴格的同步假設；也就是說，即使在非同步的情況下，只要達到一定條件（例如足夠多的驗證者是誠實的），協議也能保持安全性。
- 但在討論概率活性（probabilistic liveness）時，作者則採用部分同步模型的假設，來量化在現實情況下新區塊最終化的概率。
- 消息處理的特殊性
- 為了避免由於時鐘差異或網絡延遲而出現“提前”接收到未來時間戳的消息，作者建議誠實節點在處理消息時，應等待本地時鐘達到消息所標記的時間後再將其納入正式的 view 中。
我的猜測: 以太坊是部分同步的。也就是說，在某個未知的時間點之後，所有消息都會在一個預定的上界內傳遞到各節點，這使得協議能夠在實際網絡延遲存在的情況下仍然能夠正常運行。
- 識協議與驗證者（Validators）的基本概念
- Main Ingredients
- Casper FFG（Friendly Finality Gadget）
- 目的與作用
- Casper FFG 的主要任務是為區塊鏈提供一種「終結裝置」，即對部分區塊進行最終化（finalization），使得這些區塊一旦被最終化後就無法被撤銷或替換。這對於防止區塊鏈分叉和雙重花費等攻擊至關重要。
- 基本概念
- 檢查點（Checkpoint）：在 Casper FFG 中，區塊高度達到某個固定倍數（例如高度是常數 𝐻 的倍數）的區塊被視作檢查點。這些檢查點構成了一個子樹，用於後續的最終化過程。
- Attestations（投票）：每個驗證者對一條從上一個檢查點到當前檢查點的過渡進行投票。這些投票按其權重（通常和驗證者的抵押資產成正比）累計，達到一定比例（通常為 2/3）後，就能形成「超多數連接」（supermajority link）。
- Justification 與 Finalization：
- 當從一個已經被認定為 justified 的檢查點到下一個檢查點的投票累計超過 2/3 時，新的檢查點也就成為 justified 的。
- 如果連續兩個檢查點之間形成了超多數連接，則第一個檢查點可以被認定為 finalized，也就是被確定為區塊鏈歷史的一部分。
- 安全性與激勵機制
- Casper FFG 同時引入了懲罰條件（slashing conditions），用來約束驗證者行為，確保他們不會在相同時代內對不同檢查點進行重複投票（或作出其他違規行為），否則就會被處以罰款或「斬首」（slash）其抵押資產。
我的理解: slashing機制設計主要防二: 惡意程式重複投票或矛盾投票 TODO: (不確定)我問ChatGPT: 如果節點會因網路不穩會導致slashing嗎? 當年設計機制有考慮，但如果試圖補救(attestation inclusion delay 或 attestation consideration delay)可能會被視為違規行為而
- Casper FFG 同時引入了懲罰條件（slashing conditions），用來約束驗證者行為，確保他們不會在相同時代內對不同檢查點進行重複投票（或作出其他違規行為），否則就會被處以罰款或「斬首」（slash）其抵押資產。
[ ] TODO: Ben Edgington's Ethereum stuff: Ben現在在OP Labs, 他2017年開始寫共識層、teku(Ethereum的客戶端共識層用Java寫的)
繼續讀昨日的2020年論文，Combining GHOST and Casper，從第四節Main Protocol: Gasper開始
-
Epoch Boundary Blocks 與 Epoch Boundary Pairs
- 區塊鏈中每個區塊都能形成一條從創世區塊到該區塊的鏈，但為了在每個時代（epoch）中有明確的檢查點，作者定義了「Epoch Boundary Block」，即在每個時代開始時的最新區塊。
- 為了避免同一區塊在不同時代可能扮演檢查點角色而產生歧義，引入了「Epoch Boundary Pair」，記作 (𝐵,𝑗)，其中 𝐵 是區塊，𝑗 表示所屬的時代。這樣可以更精確地描述在某個時代內的狀態。
-
Committees（委員會）
- 驗證者被隨機劃分到不同的委員會中，每個委員會負責在各自所屬的時隙內完成區塊提議和 attestation。
- 這種劃分的目的在於分散任務，避免單一節點或小部分節點支配整個共識過程，同時提升系統的並行處理能力和安全性。
-
Blocks 與 Attestations
- 區塊（Blocks）：每個區塊包含了自身的基本數據（例如時間戳、父區塊指針等）以及「new attests」，即尚未在之前區塊中出現過的 attestation。
- Attestations（投票）：驗證者在各自時隙中通過 attestation 表示對當前鏈頭（根據某種 fork-choice 規則）的支持，這些 attestation 同時服務於 Casper FFG（作為檢查點間的投票）和 LMD GHOST 的分叉選擇。
-
Justification 與 Finalization（最終性）
- Justification：依據 Casper FFG 的概念，如果從一個已經 justified 的 epoch boundary pair 到下一個 epoch boundary pair 的過渡，獲得了超過 2/3 驗證者的投票支持，那麼後者也會被認定為 justified。
- Finalization：在 justification 的基礎上，當出現連續的、符合規定的 justified epoch boundary pairs 時，部分區塊可以被正式最終化，即認為這部分區塊鏈歷史不可更改。
- Justification：依據 Casper FFG 的概念，如果從一個已經 justified 的 epoch boundary pair 到下一個 epoch boundary pair 的過渡，獲得了超過 2/3 驗證者的投票支持，那麼後者也會被認定為 justified。
-
Hybrid LMD GHOST Fork-Choice Rule
- 為了同時利用 Casper FFG 提供的 checkpoint 信息和 LMD GHOST 的動態投票數據，作者設計了一個混合型的分叉選擇規則。
- 該規則在選擇正統鏈時，從最近被 justification 的檢查點開始，並根據各子區塊累積的最新投票權重來逐步擴展鏈條，直到找到最終的鏈頭。
-
Slashing Conditions（懲罰條件）與激勵機制
- 為了防止驗證者作弊（如重複投票或進行矛盾投票），協議明確規定了 slashing 條件。如果驗證者違反這些規定，其質押的資產將會被部分或全部扣除。
- 同時，正確執行協議（例如及時投票、正確包含 attestation）會獲得獎勵，從而激勵驗證者遵守協議規則。
- 讀fork choice和讀Phase 0 -- Honest Validator
ETH1Block、ETH2BlockETH1Block: PoW，交易/智能合約執行結果/狀態變更，紀錄用戶交易和資產狀態ETH2Block: PoS，核心是Beacon Chian，不直接包含用戶交易數據，而是用來聚合與紀錄驗證者的attestation(投票)訊息、隨機樹生成及最終性證明(Finalization)
- 讀(transactions)[https://ethereum.org/yo/developers/docs/transactions/]:
from,to,signature,nonce,value,inout,gasLimit,maxPriorityFeePerFas,maxFeePerGas(inclusive ofbaseFeePerGasandmaxPriorityFeePerGas)
- 讀Account:
nonce,balance,codeHash,storageRoot,
- 讀EVM
此圖可以看出operations直接的Gas最少，經過stack或messge call的gas較多
- 讀evm.codes <--寫solidity時可以常常查
- Day18的補充資料
- 看用wiresharp展示eth p2p節點細節, sender ip, reciver ip等
- 找到一節點
- 右鍵
Apply as Filter->selected篩選- ping與pong是一組、FindNode和Neighbor是一組
- ping與pong是一組、FindNode和Neighbor是一組
- 上方
Statistics->Ethdevp2p->Packet Stats
- Day19的libp2p介紹by David Dias
- 構想: 1x.1x.1x.1x/xx.png <-> xx.com/xx.png, Firewall, NAT, High Latency Networks, Reliablity
- IPFS -> libp2p
- libp2p的目標是在瀏覽器上能跑(Go, Node.js)像ipfs.io
- PeerPad是一款即時編輯P2P工具
- libp2p: Ethereum&polkadot支援
- 執行libp2p go版
官方寫1.20
但其實需go版本1.23
- 回去看week0: how does bittorrnt work
- 回去看day2
- 回去看day3
- 回去Day3的補充資料Gisli-Understanding Ethereum by studying the source code
- 剛組裝完新電腦+OS，正在裝WSL，預計明天裝好geth
- 安裝
WSL2、Ubuntu-24.04 - 安裝
geth、go - readme.md裡寫
make eth改成go build -o geth ./cmd/geth
改成
成功執行geth
- 提交geth PR
- 昨天PR被管理者回覆，是因為我shell設定問題，只用
go會比make少一些重要的相依。 - 讀geth github
- 進入點:
cmd/geth/main.go- main()
- init(): 裡頭有commands, 日後comnmaads快速查找區
- geth(): call StartNode()
- startNode(): 先檢查檢包，監控是否結束
- 也有consensus/: 其中consensus.go不外乎verify,加鹽,計算複雜度等
- Validator
- 目的: import, backup, edit setting, sign, remove, slashing protecting
- 格式: JSON, public and private validator key
- wallet:
- purpose block:
- webUI
- 承Validator影片，從purpose block開始
- Purpose Block function():
- PurposeBlock()
- v.signRandReveal() #RANDAO
- v.Graffti()
- v.validatorClient.BeaconBlock()
- wb = blocks.NewBeaconBlock()
- sig = v.signBlock()
- blocks.BuildSignedBeaconBlock()
- v.db.SlashableProposalCheck()
- ethpb.GenericsSignedBlock()
- Error handling for Deneb blocks, (blob?影片此處這裡沒聽懂)
- v.validatorClient.ProposedBeaconBlock()
- 好用API查詢 + Fee Recipent + Gas Limit + Graffiti + Locol key Manager
- Engine API是一個CL和EL通訊的介面規範。
- 透過
engine_forkchoiceUpdated和engine_getPayload和engine_newPayload驗證區塊執行結果、檢查交易執行是否有效。engine_forkchoiceUpdated: CL 告訴 EL「目前我決定用哪個分支作為 head block」，或「我最終確定了哪個區塊」。engine_getPayload：CL 要求 EL「打包一個執行層區塊（payload），裡面要包含交易與狀態的增減」，以便馬上出塊。engine_newPayload：CL 告訴 EL「這是某個新區塊的執行內容，麻煩幫我執行看看對不對」，EL 執行後回傳成功或失敗。
- 流程:
- CL 等到出塊時間點 (slot)
- CL 呼叫 EL
- EL 打包交易並執行
- CL 拿到執行結果
- 其他節點收到區塊
- 為跑節點
- 裝好lighthouse，之前裝過geth
- 裝lighthouse卡在build error
-
昨天問題在cmake沒裝(sudo apt install -y cmake)
-
Full node成功:geth(CL)+Lighthouse Beacon Node(CL):sepolia選測試網- geth (sepolia測試網)指令:
geth --sepolia \ --datadir ~/eth-data/geth-sepolia \ --syncmode snap \ --authrpc.port 8551 \ --authrpc.jwtsecret /home/k66/jwtsecret \ --http --http.addr 0.0.0.0 --http.port 8545 \ --http.api eth,net,engine,web3- ligthouse beacon指令:
lighthouse bn \ --network sepolia \ --datadir ~/.lighthouse/sepolia \ --execution-endpoint http://127.0.0.1:8551 \ --execution-jwt /home/k66/jwtsecret \ --checkpoint-sync-url https://sepolia.checkpoint-sync.ethdevops.io \ --disable-ssl-verification \ --metrics- 依我例子，lighthouse還需估時22小時(如下圖)
- 如果看到 Post-merge network, but no beacon client seen.有可能是沒執行lighthouse或者lighthouse還沒同步(正常現象)
Full node還在執行中(估時1天18小時)
和上圖比，下圖的slot有在減少中，只是我家網路可能真的很慢...
- 複習Engine API: A Visual Guide
- 剛好我現在位置
- 有講三種EL/CL間溝通的error:
-38003,-38002,-38001 - 完整EL/CL溝通圖
- 剛好我現在位置
- 學EIP-7702
- 2025 Pectra用
- 帳戶分兩類: 普通(EOA)、contract
- 兼容EIP-4337
- Set Code交易
- 批量調用EOA
- 解決初次使用EOA可能因原生代幣不足而無法轉帳ERC-20(原生EOA可以通過Gas抽象實現第三方用戶發起交易並支付Gas)
- AUTH: verify; AUTHCAL: excute
- 跑了4/3參加EIP-7702 workshop講者分享的實作
- source code
- terminal執行畫面
- browser執行畫面(小數點那計算顯示有誤: self=100(初始)-1(給Alice)-Bob(0.00001)=98.99999但被顯示99)
- 讀evm book
- 公鏈是根據共識處理交易的狀態機
- 2013年10月Vitalik向Mastercoin團隊提出一種方法但沒被採用、12月Vitalik分享一份白皮書，Andreas M. A(本書作者)感興趣，Gavin Wood則是提供C++幫助。
- [TODO] 從chap2往下讀