我的知識庫

區塊鏈 · 2026-10-11

閱讀時間約 28 分鐘

Hoodi 的 Glamsterdam 日期(10 月 26 日 17:42:48 UTC)從 8 月 20 日第一次被提出到 10 月 8 日定案,中間的 epoch 一個字都沒改,被推遲的是 Sepolia:8 月 20 日提案的 Sepolia 是 epoch 351232(9 月 28 日 14:44:48 UTC),9 月 3 日改成 epoch 353024(10 月 6 日 13:53:36 UTC),整整推後 7 格(1792 個 epoch,7.96 天,自算)。承 昨天的區塊鏈,昨天我只讀得到第 247 次執行層電話會議(ACDE)的 AI 摘要,今天讀到了校正版逐字稿,同時掃了 12 個客戶端的倉庫,看「Hoodi 的 Gloas 時間」到底進了誰的程式碼、進了哪個發布版。結論先講:到 10 月 11 日台北清晨,12 個客戶端裡有 4 個(都是共識層)把 epoch 132352 合進開發分支,但穩定版發布裡一個都沒有,離 10 月 16 日的發布期限剩約 6 天。

第二個新東西是 Prysm 開發分支剛併入的「builder 斷路器」,預設值定義了「一個節點要看到幾個壞 builder 才會放棄外部出價、改成自己組區塊」,我讀完原始碼算出這個門檻在預設值下的幾個數字,留在第四節。

📖 學

一、日期是怎麼一步步定下來的(逐字稿重建)

資料來源是 ethereum/forkcast 倉庫公開的會議產物(public/artifacts 下的 transcript_corrected.vtt、key_decisions.json、tldr.json、notes.json)。注意兩點:逐字稿是「校正版」,校正過程含 AI,說話者名稱與用字可能有錯;tldr、key_decisions 是 AI 產物。我引用的每一句,都回到逐字稿核對過,但沒有對照影片。

日期會議發生了什麼來源性質
8 月 20 日共識層電話會議(ACDC)第 185 次Parithosh 提案:Sepolia epoch 351232(9 月 28 日 14:44:48 UTC),Hoodi epoch 132352(10 月 26 日 17:42:48 UTC)。Lido 與 SSV 希望兩個都延後約 1 週;沒有人阻擋,決定延到下次我讀的是 notes.json 的摘要與聊天紀錄中的提案行,沒讀這次的逐字稿
9 月 3 日ACDC 第 186 次Grandine 說「越晚越好」;Nimbus 的 Matthew Keil 主張至少推到 10 月,讓客戶端先在開發網上走完一次成功的分叉;Parithosh 問有沒有人堅持 9 月 28 日,沒人回應,Sepolia 定為 10 月 6 日逐字稿
9 月 17 日ACDC 第 187 次stokes 再確認 Sepolia 10 月 6 日;提出「Sepolia 分叉後等一兩天,10 月 8 日的 ACD 若一切正常就說 Hoodi 在 27 日」,理由是之後有一個月讓 builder 在 Hoodi 上測試,分叉後留幾天觀察,然後 Devcon,「之後我們就能好好決定主網」逐字稿
10 月 1 日ACDC 第 188 次stokes 說 Hoodi 尚未選日,「不是 20 日就是 27 日,也許 26 日」,還是等 Sepolia逐字稿
10 月 8 日ACDE 第 247 次nixo 給兩個時段,26 日週一與 27 日週二,PR 預設是週一;Barnabas 因為「這是 Devcon 前一週,越早大家越有時間搭飛機」投週一;Ivan(ethrex)因團隊 26 到 27 日在飛行提議週二,無定論;nixo 說「默認週一」,定在 26 日 17:42 UTC逐字稿

這張表的第一個發現是:9 月 17 日 stokes 口頭說的「27 日」與最後定案的 26 日差一格(98,304 秒,27.31 小時),但 8 月 20 日提案的 epoch 其實就是 26 日這一格。最後的結果不是「Hoodi 往前移了一天」,而是「回到最初提案的那格」。第二個發現是推遲只發生在 Sepolia。8 月 20 日提案時 Sepolia 到 Hoodi 相隔 2,429,880 秒(1793036568 減 1790606688),即 28.12 天;現在是 1793036568 減 1791294816 等於 1,741,752 秒,20.16 天(都是自算)。與過往兩次比,Electra 時 Sepolia 到 Hoodi 是 21.30 天,Fulu 時是 14.47 天(用昨天的創世時間與 epoch 公式自算),所以 20.16 天落在中間,不是一次異常的壓縮。

二、10 月 8 日那場會議裡昨天沒讀到的三件事

1. 發布期限的爭論。 Barnabas 說「至少 10 天」,nixo 據此訂在 10 月 16 日(週五),給 10 月 19 日到 23 日一整週讓節點營運者升級。potuz 反對:Hoodi 與 Sepolia 不同,Sepolia「我們認識每一個驗證者」,Hoodi 上有質押池與所有家用質押者;他的說法是給營運者少於兩週大概會出問題,但客戶端自己要在 8 天內發布也「兩頭都緊」,並提到 Sepolia 上多數客戶端在分叉前一刻發了修補版,因為部落格文章裡的版本不是實際該用的版本。Barnabas 回答 10 天足夠,沒更新的人事後再更新。nixo 問「文件裡寫的兩週」是哪裡來的,james 憑記憶說是兩週,但找不到出處,最後的決定是 10 月 16 日。

我自算一下這個期限的實際長度:10 月 16 日 23:59:59 UTC 到分叉的 10 月 26 日 17:42:48 UTC 之間是 9 天 17 小時 42 分 49 秒,若發布在 10 月 16 日 00:00 UTC 則是 10 天 17 小時 42 分 48 秒。potuz 說的兩週,也就是 10 月 12 日 17:42:48 UTC,對台北時間是 10 月 13 日凌晨 01:42:48;換句話說,「兩週」的線在這篇文章發表後約兩天。Sepolia 那次的發布期限是 9 月 29 日(第 187 次會議,這個日期取自 AI 摘要,我沒逐句核對),距 10 月 6 日約 7 天,Hoodi 的 10 天比它多約 3 天,但比 potuz 想要的兩週少約 4 天(自算)。

2. potuz 點名要有的旗標。 他說 Hoodi 不是許可制,需要三件事:能從未最終確認(unfinalized)的狀態同步、有旗標可以關掉 P2P builder、有旗標能退回受信任 builder 或本地組區塊。他明說 Prysm「目前沒有辦法直接停掉 P2P 堆疊」,是個「很容易加的旗標」。nixo 追問「現在沒有嗎」,沒有人反駁。這正是昨天待辦「Prysm 的 P2P 建構者旗標」的來源。我搜了 Prysm 10 月 1 日以後更新的 PR,找不到明顯是「停用 P2P builder」的那一個(只看到第 17607 號「與本地出價並行請求出價」與第 17394 號「回填 payload envelope」),所以這一項我只能標「未見」,不能說不存在。

3. 主網影子分叉意外啟動了 Gloas。 Stefan Starflinger 說他原本要做一個壓測用的主網影子分叉(mainnet shadow fork),把 gas limit 調得「離譜地高」以便部署大型合約,結果沒有調回來;同時影子分叉也「不是刻意地」走過了主網上的 Gloas 分叉,「非常順利」,而且分叉當下就有 builder 參與。他把它留給 Snap 2 測試(有大區塊與大 BAL),跑到 10 月 9 日結束,下週一重開壓測用的那個。

還有一個決議值得記:nixo 當場確認「Hoodi 與主網的 gas limit 變更都在分叉 epoch 啟用」,沒有人反對。這與今天看到的程式碼一致:Prysm、Teku、Lodestar 的 Hoodi 設定都在 epoch 132352 同時放了 2 億的 gas limit 排程。

一個更正。 昨天我推論那份 AI 摘要的「11 UTC」較可能是誤聽。逐字稿顯示不是摘要誤聽:nixo 在決定週一之前確實說了「週二時段晚得多,大約晚上 8 點 UTC,另一個是 11 UTC」。但這兩個數字都不對:epoch 132608 是 10 月 27 日 21:01:12 UTC,epoch 132352 是 17:42:48 UTC,差距分別是 1 小時 1 分 12 秒與 6 小時 42 分 48 秒(自算);而他幾分鐘前自己說的是「1742 UTC」,後來被採用的也是這個。所以「11」是說話者口誤還是逐字稿誤植,我無法分辨(沒有音訊),但它沒有影響結果,因為設定檔寫的是 epoch,不是鐘點。

三、12 個客戶端的「Hoodi Gloas 時間」落地記分板

查證時間是 10 月 10 日 23:30 UTC 前後(台北 10 月 11 日清晨 07:30),全部用 GitHub API(gh api)讀公開倉庫。「穩定版含」的判定方法是比較 PR 合併 commit 與發布 tag(compare/<合併 commit>...<tag>),不是看發布說明。

客戶端開發分支狀態含在發布版嗎
Lodestar第 10313 號 PR 10 月 8 日 20:31:57 UTC 併入 unstable(含 2 億 gas limit 排程)v1.50.0-rc.0(10 月 9 日 21:44:31 UTC,預發布)含,領先該合併 commit 25 個提交;穩定版 v1.49.0 在 9 月 28 日,不含
Teku第 11452 號 PR 10 月 8 日 22:20:07 UTC 併入 master,hoodi.yaml 有 GLOAS_FORK_EPOCH: 132352 與 2 億排程不含。26.10.0 發布在 22:05:15 UTC,比該 commit 早 14 分 51 秒(自算),比對也確認 tag 落後 6 個提交
Nimbus第 9250 號 PR 10 月 10 日 02:39:51 UTC 併入每夜版(nightly)與該 commit 完全相同(預發布);穩定版 v26.10.0 在 10 月 4 日,落後 40 個提交,不含
Prysm第 17650 號 PR(10 月 8 日 14:18:58 UTC 開)10 月 10 日併入 develop,新增一行 GloasForkEpoch = 132352 與 2 億排程不含。v7.2.1 在 10 月 5 日,落後 36 個提交
Lighthouseunstable 與預設分支 stable 的 Hoodi config.yaml 都還是 GLOAS_FORK_EPOCH: 18446744073709551615(遠未來)不含;我也沒找到相關 PR(搜尋不等於證明沒有)
Grandine沒查到(我沒找到它的 Hoodi 設定檔位置)不明
Besu第 11531 號 PR(10 月 8 日 21:30 UTC 開)仍 open不含
Nethermind第 14489 號 PR(10 月 9 日 13:57 UTC 開)仍 open不含
Reth第 27811 號 PR(10 月 8 日 16:51 UTC 開)仍 open不含
Ethrex第 7391 號 PR(10 月 9 日 21:57 UTC 開)仍 open不含
Gethparams/chainspecs/hoodi.json 只有 osakaTime、bpo1Time、bpo2Time,沒有 Amsterdam;沒找到相關 PR不含
Erigonhoodi.json 只有 Osaka 相關欄位;沒找到相關 PR不含

歸納:共識層 6 個裡 4 個把時間放進開發分支(Lodestar、Teku、Nimbus、Prysm),Lighthouse 與 Grandine 沒有;執行層 6 個裡 4 個有開著的 PR(Besu、Nethermind、Reth、Ethrex),Geth 與 Erigon 沒找到。含這個時間的發布版只有 Lodestar 的一個預發布版。昨天我設的預測四(Lighthouse、Nethermind、Erigon、Besu 四個裡至少三個在 10 月 16 日前發布含時間戳的版本)基線仍是 0,Nethermind 與 Besu 有開 PR,Lighthouse 與 Erigon 沒有。

幾個顯眼的事實:Lodestar 的 PR 是 10 月 8 日 20:31:57 UTC 併入的,比 eth-clients/hoodi 第 31 號 PR 的合併(10 月 9 日 21:31:02 UTC)早 1 天 0 小時 59 分 5 秒(自算),也就是客戶端是根據 ACDE 的決定與 PR 內文,而不是等官方設定檔合併才動手。Prysm 那個 PR 比它的合併早 2 天 2 小時 21 分 39 秒(自算)就開了,GitHub 顯示合併時間 16:40:37 UTC,但 develop 上 commit 的時間是 15:09:42 UTC,兩者差 1 小時 30 分 55 秒,我無法解釋(可能是合併前又 rebase 或 GitHub 顯示與 commit 時間不同步),不影響結論。

四、Prysm 的 builder 斷路器:預設值能擋什麼

potuz 在第 187 次電話會議提醒:在 ETH 免費領取的測試網上開放任何人加入,攻擊者可以「免費」癱瘓鏈(逐字稿原句有「I just DoS the chain for free」);第 247 次又要求 Hoodi 前要有退路旗標。Prysm 第 17540 號 PR(10 月 8 日 18:42:16 UTC 併入 develop,1137 行新增、58 行刪除、19 個檔案,changelog 檔名帶 potuz)是這一串要求目前最具體的回應之一:追蹤「贏得拍賣卻沒揭露 payload」的 builder,加黑名單,並把提供該 builder 的直連端點(relay)一併封鎖。注意它也屬於 develop,v7.2.1(10 月 5 日)沒有。我是直接讀了 beacon-chain/cache/builder_circuit_breaker.go 與 config/params/mainnet_config.go 的原始碼,沒有執行它,以下推導是紙面推導。

預設值(mainnet_config.go):允許失敗次數 0;關鍵失敗次數 2;第一次違規的黑名單期 1 個 epoch;關鍵黑名單期 256 個 epoch;失敗計數的「冷卻」期 5 個 epoch(5 個 epoch 沒再失敗就歸零);「同時被列黑名單、強制改成只自己組區塊」的 builder 數 7;直連端點封鎖期上限 32 個 epoch。

從 RecordFailure 的邏輯推出的行為:

  • 第一次失敗:失敗數變 1,大於允許的 0,所以進黑名單,期限是失敗當下 epoch 加 1。判斷是否在黑名單的條件是「到期 epoch 大於當前 epoch」,所以只有失敗發生的那個 epoch 內有效,下一個 epoch 一開始就解除。1 個 epoch 是 32 × 12 = 384 秒(6.4 分鐘),所以這一次最多封 6.4 分鐘。
  • 5 個 epoch 內第二次失敗:冷卻期還沒過,失敗數累計為 2,達到關鍵失敗次數,封 256 個 epoch,即 256 × 384 = 98,304 秒 = 27.31 小時(與昨天的分叉 epoch 間距同一個數字,純屬巧合,因為都是 256 個 epoch)。
  • 間隔 5 個 epoch(32 分鐘)以上才失敗:失敗數歸零重算,又只被封 1 個 epoch。也就是說,同一個身分每 32 分鐘失敗一次,可以永遠只被封 6.4 分鐘以內。這是我讀原始碼得到的推論,沒有實測。

觸發「只自己組區塊」的門檻(SelfBuildOnly):需要同一時刻有 7 個 builder 因為「自己的」失敗而在黑名單(因 relay 被封而連坐的不算,原始碼註解明寫避免一個端點服務很多 builder 時第一次失敗就觸發)。最快的路徑是 7 個不同身分在同一個 epoch 內各失敗一次:這要贏得 7 個時槽,佔一個 epoch 32 個時槽的 7/32 = 21.9%(自算),而且效果只維持到那個 epoch 結束(最多 6.4 分鐘)。要把狀態維持久一點,每個身分要失敗兩次且間隔不超過 5 個 epoch,共 14 次失敗,7 個身分一起被封 256 個 epoch(27.31 小時)。成本面:要有 7 個 builder 身分;前面 10 月 2 日那篇讀到的 builder 最低質押是 1 ETH,所以門檻至少是 7 ETH 的押金(押金是否因失敗被罰沒,我沒有讀到),加上 14 次失敗各自的出價損失(付款無條件,見 10 月 2 日那篇)。這是單一節點的本地狀態,每個節點各自累計,不是全網共識。

這組預設值我覺得有兩個值得留意的取捨:第一次違規只封 6.4 分鐘,對「偶然的網路抖動」很寬容,但對「刻意每 32 分鐘失敗一次」的攻擊者也一樣寬容;7 個同時被封的門檻對「一次出 7 個壞 builder」的攻擊有效,但只要攻擊者的成本是 7 個身分加 14 次失敗,在 testnet 上免費 ETH 的前提下,成本幾乎是零。這就是 potuz 說「testnet 與 mainnet 不能同一套看」的具體樣子。至於這個預設值在 Hoodi 上是否夠用,不是我能判斷的,要看 10 月 26 日之後的實測。

🧠 記

  • Hoodi 的 epoch 沒推遲,Sepolia 推遲了。 8 月 20 日提案的 Hoodi epoch 132352 就是最後的 10 月 26 日 17:42:48 UTC;Sepolia 從 351232 改成 353024,推後 7 格(7.96 天)。Sepolia 到 Hoodi 的間隔因此從 28.12 天降成 20.16 天。
  • 第 247 次會議的決定: Hoodi 10 月 26 日週一 17:42 UTC;客戶端發布期限 10 月 16 日(10 天);Hoodi 與主網的 gas limit 變更都在分叉 epoch 啟用。逐字稿裡沒有討論主網日期(我搜 december、mainnet date、mainnet fork 都是 0 次)。
  • 昨天的「11 UTC」不是 AI 誤聽。 逐字稿裡 nixo 確實說了 11 UTC 與 8 PM UTC,但兩者都不等於 epoch 換算值(17:42:48 與 21:01:12);結果以 epoch 為準。
  • 落地記分板: 共識層 4 個合進開發分支(Lodestar、Teku、Nimbus、Prysm),執行層 0 個合併、4 個有 PR(Besu、Nethermind、Reth、Ethrex),穩定版含這個時間的是 0 個,預發布版 1 個(Lodestar v1.50.0-rc.0)。
  • Prysm 的 builder 斷路器(develop 未發布): 第一次違規封 1 個 epoch(6.4 分鐘),5 個 epoch 內第二次封 256 個 epoch(27.31 小時),7 個同時被封就改自己組區塊。

邊界: GitHub 資料用 gh api 讀,PR 狀態與提交時間以 10 月 10 日 23:30 UTC 前後為準;Lighthouse、Grandine、Geth、Erigon 的「沒找到」是搜尋結果,不是證明不存在。逐字稿是校正版,含 AI 校正,沒對照影片;第 185 次會議我只讀了摘要與聊天,沒讀逐字稿。斷路器的行為推導來自原始碼閱讀,沒有執行或測試;預設值以 10 月 11 日 develop 為準,日後可能變。Devcon 的日期我沒讀到,不採用。

✍️ 實踐

用 20 分鐘重現,全是唯讀,需要裝好 gh 並登入(未登入也可,但 API 流量限制很低)。

  1. 驗算 Sepolia 的推遲與間隔。你應該得到 1792、7.0、7.96 天,以及 20.16 天:
import datetime as d
U = d.timezone.utc
gs, gh = 1655733600, 1742213400   # Sepolia、Hoodi 創世時間
def when(g, e): return d.datetime.fromtimestamp(g + e * 384, U)
print(when(gs, 351232), when(gs, 353024))       # 9/28 14:44:48、10/6 13:53:36
print(353024 - 351232, (353024 - 351232) / 256, (353024 - 351232) * 384 / 86400)
print((when(gh, 132352) - when(gs, 353024)).total_seconds() / 86400)   # 20.16
print(when(gh, 132608), when(gh, 132352))       # 10/27 21:01:12、10/26 17:42:48
  1. 查一個 PR 的合併 commit 是否已被某個發布 tag 包含(用 base 與 head 的比較):
M=$(gh api repos/OffchainLabs/prysm/pulls/17650 --jq .merge_commit_sha)
gh api repos/OffchainLabs/prysm/compare/$M...v7.2.1 --jq '{status,ahead_by,behind_by}'
# status 為 behind:tag 落後該 commit,不含;ahead 或 identical:含;diverged:分叉的發布分支,要另外看

把 Prysm 換成 Teku(Consensys/teku、PR 11452、tag 26.10.0)、Lodestar(ChainSafe/lodestar、PR 10313、tag v1.50.0-rc.0)重做一次,你應該分別得到 behind、ahead。

  1. 打開 forkcast/public/artifacts/acde/2026-10-08_247/transcript_corrected.vtt,搜尋 Hoodi、December、11 Utc,確認我引用的三段(發布期限、旗標、影子分叉)與「主網日期沒被討論」。

  2. 如果你自己跑節點,用 10 月 16 日的期限對照:客戶端版本的發布說明是否寫明 Hoodi Gloas 與 epoch 132352,或用上面的比較法看你用的 tag 是否含 Hoodi 的合併 commit。

可證偽預測,附驗證條件:

  • 預測一: 到 10 月 16 日 23:59 UTC,6 個共識層客戶端裡至少 4 個有「穩定版」(非預發布)含 epoch 132352 的發布。目前基線 0(Lodestar 只有預發布)。驗證:用上面的 compare 法比對發布 tag 與各 PR 的合併 commit。
  • 預測二: 到 10 月 16 日 23:59 UTC,6 個執行層客戶端裡至少 3 個有穩定版含 amsterdamTime 1793036568。基線 0,Besu、Nethermind、Reth、Ethrex 的 PR 都還 open,Geth 與 Erigon 目前沒看到;風險明顯。驗證:查各倉庫的發布列表與鏈設定檔。
  • 預測三: 到 10 月 16 日 23:59 UTC,Lighthouse 的 unstable 分支的 Hoodi config.yaml 把 GLOAS_FORK_EPOCH 改成 132352(目前是 18446744073709551615)。若 Lighthouse 以別的形式(例如程式碼內建)排程,我會在驗證時另外標示。
  • 預測四: 到 10 月 23 日 23:59 UTC,Hoodi 的分叉時間仍是 10 月 26 日 17:42:48 UTC(沒有延期、沒有改 epoch)。驗證:eth-clients/hoodi 的 README 與 ethereum/pm 的 glamsterdam-pm.md。風險:potuz 對發布時間緊的警告,以及 Sepolia 上多數客戶端分叉前發修補版的先例。
  • 預測五: 到 10 月 16 日 23:59 UTC,Prysm 發布含第 17650 號 PR 與第 17540 號 PR 的新版本(v7.2.2 或 v7.3.0 之類)。驗證:同上的 compare 法,對兩個合併 commit 分別比較。

昨天預測的結算:預測一(10 月 16 日前 glamsterdam-pm.md 含 Hoodi 時間戳)尚未到期,今天讀到該檔案,Hoodi 與主網列仍是 TBD,第 2263 號 PR 仍 open、最後更新 10 月 8 日 04:05:02 UTC;預測二(10 月 23 日前主網仍 TBD)與預測三尚未到期;預測五(第 2266 號 PR 10 月 16 日前 merged 或 closed)尚未到期,仍 open,而 Pooja Ranjan 在第 247 次會議結尾補充說明它的目的是收集企業對 Sepolia 測試結果的回饋,不只是驗證者自填清單,我昨天把它描述成後者,這裡更正。

明天接的待辦:四個預測的基線變化、Lighthouse 的 Hoodi 設定、Prysm 的新版本、第 2263 號與 2266 號 PR 的狀態、Hoodi 的 P2P builder 停用旗標是否出現。

🔗 延伸學習

💬 問 AI

我在研究 Ethereum Glamsterdam 在 Hoodi 測試網的排程(查證時間 2026-10-11 台北清晨,資料來自公開 GitHub 與 ethereum/forkcast 的會議逐字稿),以下是我自己讀到的事實,請協助查證並嚴格區分來源:
 
1. 8 月 20 日(ACDC 第 185 次)提案 Sepolia epoch 351232(2026-09-28 14:44:48 UTC)與 Hoodi epoch 132352(2026-10-26 17:42:48 UTC);9 月 3 日(第 186 次)Sepolia 改為 epoch 353024(2026-10-06 13:53:36 UTC);Hoodi 沒改。Sepolia 創世 1655733600、Hoodi 創世 1742213400,每個 epoch 384 秒。
2. 我算出 Sepolia 推後 1792 個 epoch(= 7 × 256,7.96 天),Sepolia 到 Hoodi 的間隔從 28.12 天變成 20.16 天;Electra 時是 21.30 天,Fulu 時是 14.47 天。
3. 10 月 8 日 ACDE 第 247 次決定客戶端發布期限為 10 月 16 日(10 天通知),potuz 主張營運者需要兩週,理由是 Hoodi 有大量質押池與家用質押者。
4. 到 10 月 10 日 23:30 UTC,Lodestar、Teku、Nimbus、Prysm 已把 Hoodi 的 Gloas epoch 132352 合進開發分支,但只有 Lodestar 的預發布版 v1.50.0-rc.0 含它;Besu、Nethermind、Reth、Ethrex 的相關 PR 仍 open。
5. Prysm develop 的 builder 斷路器預設值:允許失敗 0、關鍵失敗 2、第一次違規封 1 epoch、關鍵封 256 epoch、冷卻 5 epoch、7 個同時被封就只自己組區塊。
 
請幫我:
(a) 用創世時間加 epoch 乘 384 驗算第 1、2 點的所有時間戳與間隔,指出任何算錯的格子;
(b) 解釋「穩定版是否含某個 PR」該怎麼用 git 判斷(compare 的 behind、ahead、identical、diverged 各代表什麼),以及為什麼看發布說明不夠;
(c) 分析第 5 點的預設值在「測試網免費 ETH、攻擊者可大量建立 builder 身分」的情境下,最少要多少次失敗才能讓一個節點進入只自己組區塊,以及攻擊者每 32 分鐘失敗一次時為何只會被封 6.4 分鐘;
(d) 回答時分三類標示:「來源明說的」、「你另外查證到的(附網址)」、「你的推論」,不要用舊記憶補。
這是技術研究,僅供學習,不需要也請不要給任何投資建議。

反向連結