我今天 10 月 15 日 23:03 UTC(台北 10 月 16 日 07:03)重讀 Hoodi 的 Glamsterdam 記分板:距 10 月 16 日 23:59:59 UTC 的發布期限還有 1 天 0 小時 56 分,距分叉 10.78 天。承 昨天的區塊鏈,最大的變化是含 Hoodi 時間戳的穩定版從 1 個變成 2 個:Teku 26.10.1 在 10 月 15 日 22:13:46 UTC 發布,發布說明明寫「這是 Hoodi Glamsterdam 分叉的必要更新(epoch 132352)」。執行層沒動,仍是 5/6 已合併、0 個穩定版;Geth 的 hoodi.json 仍只到 bpo2Time。
所以昨天留下的五個預測,今天只能做「期中對帳」:期限是明天,不是今天。今天有三件新東西:Teku 的合併到發布延遲(6.9956 天,和模型 B 用的 Sepolia 中位數 6.6 天幾乎一樣);五個尚未發版的客戶端各自留下的跡象(Lighthouse 的發布分支、Prysm 的兩個 rc 標籤、Ethrex 的 v30.0.0-rc.1);以及第 189 次共識層電話會議上,主網日期被收斂到 12 月 1 日與 12 月 8 日兩個選項,同場還有一個會燒掉 ETH 的 EIP-8365 設計問題。
📖 學
一、記分板:穩定版 1 變 2,執行層仍是 0
資料用 GitHub API(gh api)在 10 月 15 日 23:03 UTC 讀取,距分叉是自己算的(分叉時間 10 月 26 日 17:42:48 UTC)。11 個排程 PR 的合併時間我逐一重查,與昨天完全相同,沒有被回退或重開。
| 10/13 23:01 UTC | 10/14 23:01 UTC | 10/15 23:03 UTC | |
|---|---|---|---|
| 共識層已合併 Hoodi 時間戳 | 6/6 | 6/6 | 6/6 |
| 執行層已合併 | 4/6 | 5/6 | 5/6(缺 Geth) |
| 含 Hoodi 時間戳的穩定版 | 1 | 1 | 2(Lodestar v1.50.0、Teku 26.10.1) |
| 其中執行層 | 0 | 0 | 0 |
| 距期限 | 3 天 1 小時 | 2 天 1 小時 | 1 天 0 小時 56 分 |
其餘 10 個倉庫的最新穩定版和昨天一樣:Nimbus v26.10.0(10/4)、Prysm v7.2.1(10/5)、Lighthouse v8.2.3(10/1)、Nethermind 2.1.0(10/1)、Besu 26.9.0(9/25)、Reth v2.7.0(9/28)、Geth v1.17.8(10/8)、Erigon v3.7.1(10/2)、Ethrex v29.0.1(10/5)、Grandine 2.0.6(8/3),它們都早於各自的 Hoodi 合併時間,所以不含。三個預發布要另外記:Ethrex v30.0.0-rc.1(10 月 14 日 23:32:37 UTC)、Lighthouse v8.3.0-rc.0(10 月 1 日,早於它的合併)、Grandine 3.0.0-rc.0(9 月 30 日,早於它 10 月 13 日的合併)。我的計數標準仍是「非預發布」,所以 Ethrex 的 rc 不算。
二、Teku 26.10.1:第二個穩定版,延遲 6.9956 天
Teku 的 Hoodi PR(第 11452 號,標題 added hoodi configuration for gloas)10 月 8 日 22:20:07 UTC 合併,26.10.1 在 10 月 15 日 22:13:46 UTC 發布,中間 6 天 23 小時 53 分 39 秒,即 6.9956 天。這個數字有兩層意義:第一,它落在我昨天模型 B 用的 10 個 Sepolia 延遲範圍內(1.71 到 15.41 天,中位 6.6 天),是 Hoodi 上的第一個實測延遲;第二,它離期限還有 25.77 小時,落在模型 C 說的「期限前 47 小時」窗口(Hoodi 版從 10 月 15 日 01:18 UTC 開始)內,Teku 在 Sepolia 上的 26.9.1 則是期限前 46.7 小時,比這次早約 21 小時。
發布說明的內容很短:「Additions and Improvements」只有一行,Gloas fork scheduled for HOODI at epoch 132352;其餘是 4 個與分叉無關的修正(對等節點選擇、gossip 訂閱上限從 200 提到 500 個主題、只廣告 QUIC 位址的節點記錄不再被忽略、停用 TCP 的節點不再撥 TCP)。26.10.1 比 26.10.0 多 27 個提交、動了 181 個檔案(比較 API 的數字,我沒逐一讀),所以它不是只加一行設定的熱修,而是把一週多累積的東西一起帶出。這解釋了為什麼延遲接近一週:Teku 看起來是把 Hoodi 設定併進了一次正常的發版,而不是為它單獨發版(這是我從發布說明結構做的推論)。
三、五個尚未發版的客戶端,留下什麼跡象
我掃了各倉庫的發布、標籤、分支與近期 PR,以下是「看得到的跡象」,不是預測。
| 客戶端 | 跡象 | 能說與不能說 |
|---|---|---|
| Lighthouse | release-v8.3.0 分支 10 月 15 日 08:26:39 UTC 由 michaelsproul 建立,其 Hoodi 設定已有 GLOAS_FORK_EPOCH: 132352;目前沒有 v8.3.0 標籤 | 分支比 v8.2.3 多 267 個提交 |
| Prysm | 標籤 v7.3.0-rc.0(提交 10/13 20:23)與 v7.3.0-rc.1(提交 10/15 14:05)都存在,rc.1 比 Hoodi 合併多 29 個提交、落後 0 個,所以含 Hoodi;GitHub 上沒有對應的發布 | 標籤不是發布 |
| Ethrex | v30.0.0-rc.1 預發布(10/14 23:32:37),發布說明列出 PR 7391(Hoodi 排程) | 預發布不算 |
| Nimbus | nightly 10/15 05:39 又重建,穩定版沒動 | nightly 不算 |
| Grandine | 10 月 15 日合併兩個與發布流程有關的 PR(第 958 號讓預發布標籤發為 unstable、第 959 號在穩定版啟用 Nethermind 整合),穩定版仍是 2.0.6 | 是否為發版預備,我只有標題,待驗 |
| Nethermind、Besu、Reth、Erigon | 沒找到 rc、發布分支或發版 PR | 分支命名各家不同,不是證明沒有 |
Lighthouse 值得多說兩句。它的發布分支到發布的間隔,我找到名稱與發布一一對應的三個:release-v8.2.0 為 1.72 小時、release-v8.2.2 為 1.59 小時、release-v8.2.3 為 1.75 小時。這次的 release-v8.3.0 建立至今已 14.6 小時沒有標籤,是歷史的 8 到 9 倍,所以「分支建立後兩小時內發布」的規律這次沒有成立。我不知道原因:可能在等 Hoodi 之外的測試,也可能刻意等到下週。後面第四節的會議摘要裡有一句「Lighthouse 與 Teku 預計下週初發布」(原文片段,我讀到的版本在 early next 處被截斷,待驗),而 Teku 實際在當天就發了,所以這種預告可以早於計畫,也可能不會。
Prysm 要另外看。它的穩定版標籤指向的提交和最後一個 rc 標籤相同(v7.2.1 的 rc.0 與正式版標籤都在 10 月 3 日 03:05 的同一個提交),但 GitHub 上正式「發布」晚好幾天:v7.2.1 晚 2.76 天、v7.1.4 晚 1.06 天、v7.1.3 晚 9.06 天(以提交時間對發布時間算,不是標籤建立時間,所以只是約略)。就算 Prysm 今天切出 v7.3.0 的正式標籤,它進到我的計數(GitHub 的非預發布)的時間也可能超過期限。
Ethrex 的 rc 到穩定版間隔,我算了 4 個樣本:v24.0.0 為 7.04 天、v26.0.0(從有列出的 rc.2 起算)為 12.21 天、v28.0.0 為 6.87 天、v29.0.0 從 rc.1 起算為 2.76 天(從最後的 rc.3 起算只有 1.95 小時)。v30.0.0-rc.1 到期限是 2.02 天,4 個樣本沒有一個在 2.02 天內從第一個 rc 走到穩定版,最接近的 v29 也要 2.76 天。照這個看,Ethrex 在期限前出穩定版的機率不高,我給約 15%。這是 4 個點的外推。
四、第 189 次共識層電話會議:主網日期收斂為兩個
ethereum/pm 第 2247 號議題是 10 月 15 日 14:00 UTC 的議程,Glamsterdam 項下列了 sepolia、hoodi(client releases)與 builder onboarding。議題留言裡有兩段值得記:
- 14:02:38 UTC,barnabasbusa 提出「假設 Hoodi 分叉成功,主網建議分叉」於 epoch 493056(2026-12-01 20:38:47 UTC,Unix 1796157527),另一選項 epoch 494592(2026-12-08 16:29:11 UTC,Unix 1796747351),問大家偏好。我用主網創世 1606824023 加 epoch × 384 驗算,兩個 Unix 值都吻合,各距 Hoodi 分叉 36.12 天與 42.95 天。這兩個日期在 10 月 10 日的區塊鏈出現過,當時是議題裡三個候選之一,今天是 12 月 9 日被拿掉,剩兩個。
- 17:14:43 UTC,dgusakov 回覆選 12 月 8 日,理由是「我們還需要用真的 builder 在 Hoodi 上做很多測試,所以 12 月 8 日對 Lido 很合適」。這是單一社群成員的偏好,不是決定。
同一天的會議摘要(Magicians 討論串第 29847 號,留言時間標為當天 6:08pm、時區沒標)我用抓取工具讀到:「Lodestar 與 Etherex(應是 Ethrex)確認、Lighthouse 與 Teku 預計下週初發布」(被截斷的原文片段,待驗)、Hoodi 分叉維持 10 月 26 日、同意在分叉前做 builder 存款與補充存款交易、客戶端團隊要審 Barnabas 提議的 EIP-8365 修改。這份摘要中我讀到的片段沒有提到主網日期結論,所以「12 月 8 日或 12 月 1 日」仍是議題留言裡的提案與偏好,我沒有查到任何定案。昨天預測四(分叉時間維持 10 月 26 日 17:42:48 UTC)依這份摘要成立,但我沒看會議錄影,只憑摘要,標「依摘要成立」。
五、EIP-8365:一個修正會燒掉 ETH 的設計問題
會議上同時討論的 EIP-8365 值得單獨講,因為它示範了「一個棄用步驟如何產生副作用」。這個 EIP 想讓「新的 0x00(BLS 提款憑證)驗證者不再被啟用」,原設計是在處理存款時直接略過會建立新 0x00 驗證者的存款。Barnabas 在 10 月 15 日 10:22 UTC 開出 EIP 的第 12513 號 PR 與 consensus-specs 的第 5744 號 PR(兩個都 open,規格那份 5 個檔案 +247 -36),指出略過存款等於把存進去的 ETH 永久銷毀,因為共識層沒有退款路徑:0x00 憑證沒有執行層位址,EIP-6110 的存款請求也不帶存款人。PR 描述舉了三個數字:2026 年主網一批 50 個新 0x00 驗證者會燒掉 1,600 ETH;存款佇列每天最多排 57,600 ETH;若不做處理,佇列裡分叉時還沒處理的合法存款會被燒掉。
我只驗算了數字的算術,沒有評判設計本身。50 × 32 = 1,600 ETH 成立;57,600 ETH 一天等於 225 個 epoch(一天 86400 秒 ÷ 384 秒)乘每個 epoch 256 ETH 的啟用上限,成立;16 個 BLSToExecutionChange 一個區塊 × 32 個區塊 × 32 ETH = 16,384 ETH 每個 epoch,是 256 ETH 上限的 64 倍,也成立,這就是為什麼提案要把「參數改憑證後再次排隊」當成必要步驟,不然批次啟用會繞過佇列限制。提案改成:0x00 存款照常登記並保留完整餘額,但在持有人用 BLSToExecutionChange 換成 0x01 之前不被啟用。
Barnabas 當天另有一則 13:37 UTC 的留言,提出三步計畫:Hegotá 讓新的 0x00 驗證者停止啟用(EIP-8365)、下一個分叉「I fork」把剩餘 0x00 驗證者在分叉時一次退出(EIP-8433,餘額不動、轉 0x01 即可全額拿回)、再下一個「J fork」移除 BLSToExecutionChange 與其他 0x00 路徑,為後量子轉換做準備(他說這步還需要 EIP)。這些都是提案,不是決議;會議紀錄只說「客戶端團隊審提議的修改」。另外 dgusakov 提了 consensus-specs 第 5735 號議題(標題:Gloas 分叉上線時,存款會用相同公鑰記入 builder),這和「分叉前做 builder 存款」的決議有關,內容我只讀了標題,沒讀討論。
六、模型更新:把 Teku 算進去,以及一個零機率的缺陷
模型 B 今天改為:共識層已有 2 個穩定版,所以「至少 3 個」等於「Nimbus、Prysm、Lighthouse、Grandine 四個裡至少 1 個」;執行層 5 個(Nethermind、Besu、Reth、Erigon、Ethrex)至少 1 個。時間點 10 月 15 日 23:03:21 UTC,期限前還有 1.04 天。我跑了兩種:只用 Sepolia 的 10 個延遲,以及再把 Teku 的 Hoodi 實測延遲 6.9956 天當成第 11 個樣本。
| 客戶端 | 合併後已過(天) | 機率(10 個樣本) | 機率(加 Teku,11 個) |
|---|---|---|---|
| Nimbus | 5.85 | 0.333 | 0.286 |
| Prysm | 5.27 | 0.143 | 0.125 |
| Lighthouse | 3.76 | 0.125 | 0.111 |
| Grandine | 2.55 | 0 | 0 |
| Nethermind | 3.93 | 0.125 | 0.111 |
| Besu | 3.69 | 0.125 | 0.111 |
| Reth | 3.20 | 0 | 0 |
| Erigon | 2.31 | 0.111 | 0.100 |
| Ethrex | 1.17 | 0.100 | 0.091 |
共識層至少 3 個:50%(10 個樣本)或 44%(11 個);自助法 5% 到 95% 區間 20% 到 78% 與 18% 到 73%。執行層至少 1 個:39% 與 35%;區間 10% 到 69% 與 9% 到 64%。
這份表有一個明顯缺陷:Grandine 與 Reth 的機率是 0。原因是模型只看「剩下的延遲樣本」,Grandine 已過 2.55 天、期限前還剩 3.55 天,而 10 個樣本裡沒有任何一個落在 2.55 到 3.55 天之間(樣本是 1.71、2.48、4.44、…),Reth 同理。這是樣本稀疏造成的零,不是「Reth 不會發版」的證據。它再次說明 10 個點的條件機率不能當成精確值,零和 0.33 之間的差距主要是哪個樣本剛好落在哪裡。
模型 C 也要更新,方法是用一個「同一時間點」的比較,而不是昨天那個固定的 0.7。Sepolia 在期限前 25 小時這個時間點,8 個「期限前 3 天已合併」的客戶端裡已有 4 個發版(Teku 46.7、Reth 35.2、Lodestar 34.1、Prysm 32.2 小時前),剩下 4 個裡又有 2 個在最後 25 小時發版(Ethrex 19.9、Nimbus 8.3),比率 2/4。Hoodi 在相同時間點(期限前約 25 小時),10 個合格客戶端裡只有 2 個發版(Lodestar、Teku),落後了。用 Laplace 平滑 (2+1)/(4+2) = 0.5 套用到剩下的客戶端:共識層 4 個至少 1 個是 1 − 0.5^4 = 93.75%,執行層 4 個合格客戶端(Nethermind、Besu、Reth、Erigon)至少 1 個也是 93.75%,Ethrex 另算。獨立性與只有一次事件的限制和昨天一樣。
兩個模型的差距比昨天還大(44% 到 50% 對 94%),我自己的判斷:共識層至少 3 個約 70%(下調自昨天的 75%),因為 Lighthouse 若依預告在下週初發版就不在期限內,但 Prysm、Nimbus、Grandine 三條路還開著;執行層至少 1 個約 50%(下調自 80%):四個沒有 rc 或發布分支的客戶端沒有任何跡象,Ethrex 的 rc 到穩定版間隔歷史偏長,而兩天前我還假設「期限效應」會把它們一起拉出來。這是主觀數字,不是模型輸出。
🧠 記
- 記分板(10 月 15 日 23:03 UTC): 共識層 6/6;執行層 5/6;含 Hoodi 的穩定版 2 個(Lodestar v1.50.0、Teku 26.10.1);執行層 0 個;距分叉 10.78 天、距期限 1 天 0 小時 56 分。
- Teku 26.10.1: 10/15 22:13:46 UTC,合併後 6 天 23 小時 53 分 39 秒(6.9956 天),距期限 25.77 小時;27 個提交、181 個檔案。
- 跡象: Lighthouse 分支 10/15 08:26:39 建立、至今 14.6 小時沒發(歷史 1.6 到 1.75 小時);Prysm v7.3.0-rc.1 標籤含 Hoodi、無 GitHub 發布;Ethrex v30.0.0-rc.1 於 10/14 23:32:37 發出;Geth 無變化。
- Ethrex 的 rc 到穩定版: 4 個樣本 7.04、12.21、6.87、2.76 天,v30 離期限只有 2.02 天。
- 第 189 次會議: 主網候選收斂為 12 月 1 日(20:38:47 UTC)與 12 月 8 日(16:29:11 UTC);一則回覆偏好 12 月 8 日;摘要中沒找到主網日期結論;Hoodi 分叉維持 10 月 26 日;分叉前做 builder 存款與補充存款。
- EIP-8365: 略過 0x00 存款會燒掉存款;PR 12513 與 5744 提議改為閘住啟用;1,600 ETH、57,600 ETH、16,384 ETH 三個數字算術成立;兩個 PR 都 open。
- 模型: B 共識層至少 3 個 44% 到 50%、執行層至少 1 個 35% 到 39%,零機率是樣本稀疏;C 以 25 小時時間點比較得 94%,Hoodi 進度 2/10 對 Sepolia 4/8。我的判斷 70% 與 50%。
邊界: 資料主要是 GitHub API,時間點是 10 月 15 日 23:03 UTC;期限是 10 月 16 日 23:59:59 UTC,今天只能做期中對帳。會議摘要的引文來自抓取工具,原文被截斷,我沒看錄影也沒讀完整紀錄,所以 Lighthouse「下週初」與主網日期「沒有結論」都標待驗。Prysm 與 Lighthouse 的間隔以提交時間、分支建立時間算,不是標籤建立時間。Ethrex 的 rc 間隔只有 4 個樣本,Lighthouse 只有 3 個。模型 B 的零機率是樣本稀疏的產物,模型 C 只有 Sepolia 一次事件。Hegotá、I fork、J fork 是提案中的名稱,不是已定案。不構成任何投資、質押或營運建議。
✍️ 實踐
全部唯讀,約 25 分鐘。
- 重查 Teku 的發布與延遲(約 5 分鐘):
gh api repos/Consensys/teku/releases/tags/26.10.1 --jq '"\(.published_at)\n\(.body)"' | head -20
gh api repos/Consensys/teku/pulls/11452 --jq '.merged_at'
python3 -c "
import datetime as d
print(d.datetime(2026,10,15,22,13,46)-d.datetime(2026,10,8,22,20,7))"- 查 Lighthouse 的發布分支建立時間與目前有沒有標籤(約 5 分鐘):
gh api "repos/sigp/lighthouse/activity?ref=refs/heads/release-v8.3.0&per_page=3" --jq '.[]|"\(.timestamp) \(.activity_type) \(.actor.login)"'
gh api "repos/sigp/lighthouse/git/matching-refs/tags/v8.3" --jq '.[].ref'
gh api "repos/sigp/lighthouse/releases?per_page=3" --jq '.[]|"\(.tag_name) \(.published_at) \(.prerelease)"'- 驗算主網候選與 EIP-8365 的三個數字(約 5 分鐘):
1606824023 + 493056*384應為 1796157527,+ 494592*384應為 1796747351;50*32、86400/384*256、16*32*32對照 1,600、57,600、16,384 ETH。 - 自己做「同一時間點」比較(約 5 分鐘):取 Sepolia 六個發布距期限的小時數(46.7、35.2、34.1、32.2、19.9、8.3),數出期限前 25 小時時已發版的個數,再對照 Hoodi 現在的 2 個。
- 想一想:Hoodi 在同一時間點比 Sepolia 落後(2/10 對 4/8),如果最後 10 月 16 日的發版數追上了,你會把它歸因於「期限在驅動」還是「各團隊週期剛好到」?要什麼資料才能分辨?
可證偽預測(沒特別註明的都在 10 月 16 日 23:59:59 UTC 到期,台北 10 月 17 日 07:59:59):
- 預測一: 含 Hoodi 時間戳的共識層穩定版(非預發布,含 Lodestar、Teku)至少 3 個;模型 B 給 44% 到 50%、模型 C 給 94%,我給 70%。
- 預測二: 含 Hoodi 時間戳的執行層穩定版至少 1 個;模型 B 給 35% 到 39%、模型 C 給 94%,我給 50%。
- 預測三: Ethrex v30.0.0 在期限前以穩定版發布約 15%。
- 預測四: Lighthouse 的 v8.3.0(非預發布)在期限前發布約 45%;Prysm 的 v7.3.0 在 GitHub 上以非預發布出現約 40%。
- 預測五: Geth 的
hoodi.json在期限前出現amsterdamTime: 1793036568約 55%;含 Hoodi 的 Geth 穩定版約 10%。 - 預測六(10 月 22 日 14:00 UTC 的執行層第 248 次會議結束前): 官方會議摘要或 EF 公告明確列出 12 月 1 日或 12 月 8 日其中之一為主網日期,約 45%;若有,12 月 8 日約 70%。
- 預測七(10 月 23 日 23:59 UTC 到期): consensus-specs 第 5734 號 PR 合併約 35%(10 月 13 日後沒有動靜);EIP 第 12513 號 PR 合併約 25%。
明天接的待辦:期限前最後一次記分板(讀取時間約 10 月 16 日 23:03 UTC,離期限只剩約 1 小時,最終結算要等後天)、Lighthouse 分支是否出現標籤、Prysm 的 GitHub 發布、Geth 的 Hoodi PR。
🔗 延伸學習
- Consensys/teku 26.10.1 發布說明(GitHub) — 本文第二節的來源,含 Hoodi 的 Gloas 排程與四項修正。
- sigp/lighthouse release-v8.3.0 分支(GitHub) — 第三節的發布分支,Hoodi 設定已含 epoch 132352。
- lambdaclass/ethrex v30.0.0-rc.1 發布(GitHub) — 含 Hoodi 排程的預發布,附完整更新清單。
- ethereum/pm 第 2247 號議題:ACDC 第 189 次議程與留言(GitHub) — 主網候選日期、builder 存款與 EIP-8365 的原始留言。
- EIPs 第 12513 號 PR:Update EIP-8365,閘住啟用而非略過 0x00 存款(GitHub) — 第五節的設計問題與三個數字的出處。
- consensus-specs 第 5744 號 PR:Do not activate 0x00 validators(GitHub) — 對應的規格改動與測試。
💬 問 AI
我在追蹤 Ethereum Glamsterdam 在 Hoodi 測試網的客戶端就緒度(查證時間 2026-10-15 23:03 UTC,資料來自 GitHub API)。以下是我自己整理的主張與模型,請協助查證並嚴格區分來源:
1. 事實:共識層 6 個客戶端與執行層 5 個(Nethermind、Besu、Reth、Erigon、Ethrex)已合併 Hoodi 的 Glamsterdam 排程(epoch 132352,時間戳 1793036568);Geth 沒有;含 Hoodi 時間戳的穩定版有 2 個:Lodestar v1.50.0 與 Teku 26.10.1(2026-10-15 22:13:46 UTC,在其 Hoodi PR 合併後 6.9956 天);發布期限 2026-10-16 23:59:59 UTC,分叉 2026-10-26 17:42:48 UTC。
2. 跡象:Lighthouse release-v8.3.0 分支於 2026-10-15 08:26:39 UTC 建立,歷史上分支到發布約 1.6 到 1.75 小時,這次 14.6 小時尚未發布;Prysm 有 v7.3.0-rc.0、rc.1 標籤但無 GitHub 發布;Ethrex v30.0.0-rc.1 預發布(10/14 23:32:37),其歷史上 rc 到穩定版 4 個樣本為 7.04、12.21、6.87、2.76 天。
3. 模型 B:用 Sepolia 10 個「合併到穩定版」延遲(1.71、2.48、4.44、15.41、7.09、10.44、5.82、10.86、6.56、6.65 天)算條件機率,今天得共識層至少 3 個穩定版 44% 到 50%、執行層至少 1 個 35% 到 39%;Grandine 與 Reth 的機率因樣本稀疏為 0。
4. 模型 C:Sepolia 在期限前 25 小時時,8 個合格客戶端中已有 4 個發版,之後 4 個又有 2 個發版;Hoodi 同一時間點只有 10 個中的 2 個發版;以 Laplace 平滑 0.5 估,得 93.75%。
5. 第 189 次共識層會議:主網候選 2026-12-01 20:38:47 UTC 與 2026-12-08 16:29:11 UTC,議題留言中有人偏好 12 月 8 日;EIP-8365 的原設計(略過 0x00 存款)會燒掉存款,PR 12513 與 consensus-specs PR 5744 提議改為閘住啟用。
請幫我:
(a) 檢查兩個模型的統計設計:條件機率在樣本稀疏時出現零機率該怎麼修正(例如平滑、核密度或參數化延遲分布)、獨立假設、把 Teku 的 Hoodi 延遲加入樣本的做法是否合理,以及「同一時間點比較」這種方法的限制;
(b) 提出驗證兩個模型誰比較好的設計:需要哪些其他分叉或測試網的公開資料(Holesky、Sepolia 先前的分叉、Fusaka 等),如何做留一法或時間序列式回測;
(c) 說明 EIP-8365 若略過 0x00 存款為何會銷毀 ETH、改為閘住啟用有什麼取捨(例如參數改憑證後再次排隊的必要性),以及這與「主網日期選 12 月 1 日或 12 月 8 日」的時程壓力有什麼關係;
(d) 分三類標示每個結論:「規格或文件明說的」、「你另外查證到的(附網址)」、「你的推論」,不要編造連結或數字,查不到就說查不到。
這是技術研究,僅供學習,不需要也請不要給任何投資、質押或節點營運建議。