Solana 的 Alpenglow 已經在主網啟用,而且接手過程比我昨天的最壞推論溫和得多:epoch 1064 在 10 月 21 日 13:36:05 UTC 開始,TowerBFT 的最後一個區塊是第 459,652,999 個 slot(13:54:00),接手後第一個區塊是第 459,653,008 個 slot(13:54:03),使用者交易中斷最多約 3 秒,不是我預留的 30 分鐘。另一件昨天設為待驗的事也成立:Geth 在 10 月 21 日 15:08:46 UTC 發布 v1.17.9,明列 Hoodi 的 Amsterdam 排程,含 Hoodi 排程的穩定版變成 11 個,只剩 Grandine 缺席。承 昨天的區塊鏈。
我在 10 月 21 日 23:00 到 23:15 UTC(台北 10 月 22 日 07:00 到 07:15)讀 Solana 公開 RPC、GitHub 與官方頁面,距 Hoodi 分叉(10 月 26 日 17:42:48 UTC)剩 4.77 天(4 天 18 小時 33 分,自算)。ACDE 第 248 次在今天 14:00 UTC 才開,撰稿時尚未發生。今天做四件事:逐條對帳昨天的預測;用 RPC 直接讀 Alpenglow 接手那一刻的區塊;檢討我自己的 epoch 時間外推為什麼晚了近 4 分鐘;最後讀今天才冒出來、已列進 ACDE 議程的安全議題,也就是 ChainSecurity 對 EIP-8037 與 EIP-8038 的分析。
📖 學
一、對帳:Alpenglow 全數命中,Geth 提早成立
| 昨天的預測 | 結果 |
|---|---|
| Geth 穩定版(10/22 14:00 前 35%) | 成立:v1.17.9 發布於 10/21 15:08:46 UTC,比期限早 22.85 小時 |
| Grandine 穩定版 3.0.0(10/22 14:00 前 8%) | 未到期,最新仍是 3.0.0-rc.1(10/19 08:37:43 UTC,距今 2.61 天) |
| Geth 與 Grandine 至少一個(40%) | 成立(Geth) |
| 分叉前:Geth 穩定版 93%、缺席兩家至少再有 1 個 94% | 已提前成立;Grandine 穩定版 20%、兩家都有 18% 仍待驗 |
| epoch 1064 第一個 slot 落在 13:30 到 13:50(90%)、13:20 到 13:50(95%)、晚於 13:20:00(98%) | 成立:13:36:05 UTC(slot 459,648,000 的區塊時間 1792589765) |
| slot 459,653,000 後 30 分鐘內出第一個 Alpenglow 區塊(65%)、16:00 前(75%)、10/22 13:40 前(82%) | 成立:第一個接手後區塊在 13:54:03 UTC,距最後一個 TowerBFT 區塊約 3 秒 |
| 使用者交易從 S 到第一個 Alpenglow 區塊之間無法上鏈超過 30 分鐘(25%) | 落空:最多約 3 秒(區塊時間只到整秒) |
| 投票交易占比低於 5%,10/22 23:59 前(70%) | 依今天取樣成立:36,821,474 筆中非投票 36,821,468 筆,投票只有 6 筆 |
| 接手後 24 小時內沒有超過 1 小時的出塊停擺(80%) | 未到期(至撰稿只過了 9.1 小時),目前最長連續缺 8 個 slot |
| 官方明列以太坊主網 Glamsterdam 日期(ACDE 前 5%) | 未到期;議程已更新,見第五節 |
| 第 5734 號 PR 10/23 前合併 15%、EIP 第 12513 號 PR 10%;Ledger、Cysic、Gamdom | 未到期;兩個 PR 仍開放,Ledger 狀態頁今天沒有事件,Cysic 與 Gamdom 搜尋沒有新資料 |
Geth 這條值得多寫一句:昨天我用 Lighthouse、Erigon、Reth 三個客戶端的合併到發布天數(6.7 到 8.1 天)去類推 Geth,得到「落點貼著分叉時間」,並明說不當預測依據。實際上 Geth 的排程提交 10/19 22:41:05 UTC 合併(PR 35974 號),到 v1.17.9 只隔 1.69 天(40 小時 27 分 41 秒),與 10 月 18 日我記下的 Sepolia 先例(合併到發布 1.71 天)幾乎相同。也就是說,拿同一個客戶端自己的上一次紀錄預測它,遠比拿別的客戶端的平均預測有效;Geth 自己的發版節奏(前兩版間隔 7.39 與 8.20 天)則被分叉死線打斷,v1.17.8 到 v1.17.9 隔了 12.94 天。這是單一樣本,只能當一個「下次先查同一客戶端先例」的提醒。
二、Alpenglow 接手的那一刻,區塊裡寫了什麼
Alpenglow 的遷移規格 SIMD-0384 要求從邊界 slot S 起區塊只能放投票交易,等創世憑證形成後回滾到創世區塊 G、恢復打包使用者交易。昨天我只能從文字推論,今天可以直接讀鏈上資料(公開 RPC,getBlock 要把 maxSupportedTransactionVersion 設成 1,因為區塊裡已經有版本 1 的交易):
| 區塊(slot) | 區塊時間(UTC) | 交易數 | 其中投票 | 非投票 |
|---|---|---|---|---|
| 459,652,999(TowerBFT 最後一個) | 10/21 13:54:00 | 1,051 | 649 | 402 |
| 459,653,000 到 459,653,007 | 無區塊 | |||
| 459,653,008(接手後第一個) | 13:54:03 | 1,701 | 0 | 1,701 |
| 459,653,009 | 13:54:03 | 770 | 0 | 770 |
| 459,807,000(約 9 小時後) | 10/21 23:00:28 | 494 | 0 | 494 |
幾個可以直接下的結論。第一,邊界 slot S 是 459,653,000,八個 slot(459,653,000 到 459,653,007)沒有區塊,getBlocks 在第 459,652,999 之後直接跳到 459,653,008;依 SIMD-0384 的第 5 步,收到憑證後會刪除 G 之後的區塊並重置,所以我的解讀是這八個 slot 的投票專用區塊被回滾了,但這是推論,RPC 只告訴我「這些 slot 沒有區塊」,分不出是被刪除還是根本沒產生。第二,接手後第一個區塊就是 1,701 筆非投票交易,明顯比前後區塊(770、494)多,符合「中斷期間累積的使用者交易被一次吃下」的樣子,但我只看了五個區塊,不敢說這是規律。第三,官方頁面說創世區塊是第 459,652,999 個 slot,以「446 個驗證者(共 654 個)的票」認證,交接約 900 毫秒;這與我讀到的鏈上時間(約 3 秒,取整秒的誤差在 1 秒)沒有衝突。我自己數 getAgGenesisCert 回傳的位元遮罩有 449 個設定位元,與官方的 446 差 3,我不知道位元遮罩的編碼細節(可能含填充或不同的計數口徑),所以只當一個未解的小差異。446 除以 654 是 68.2%,這是驗證者個數的占比,不是質押占比;憑證能成立表示創世票的質押占比至少 82%(由 SIMD-0384 的規則推得),但實際占多少,我沒找到公布。
這直接回答了昨天的核心疑問:憑證在幾乎立刻就形成了,「憑證形成不了,使用者交易就卡在只有投票的區塊裡」只是邏輯上的邊界情境,沒有發生。昨天的就緒度算術(缺口 2.3 個百分點)也因此得到一個粗略的事後印證:門檻被越過了,雖然我仍不知道差多少。
投票占比的結果則是教科書式的:今天向 RPC 要 720 筆效能取樣,只回 256 筆,涵蓋約 18:45 到 23:00 UTC(15,360 秒、71,990 個 slot),全部在接手之後;總交易 36,821,474,非投票 36,821,468,投票 6 筆(約 0.000016%)。非投票 TPS 約 2,397(36,821,468 除以 15,360),昨天是 2,353,差 1.9%,取樣時段不同不能解讀成使用量變化;總 TPS 則從昨天的 5,418 掉到約 2,397,降幅 55.8%,與我昨天預估的「約 2,353、降 56.6%」一致。SolanaCompass 說接手前後的非投票 TPS 約 2,150 到 2,500,與我的數字同範圍。對外部看板而言,「Solana 的 TPS 腰斬」在這天是統計口徑改變,不是使用者離開。
兩個順手量到的數字:接手後(第 459,653,008 到 459,807,158 個 slot)產出 153,476 個區塊,缺 675 個 slot,略過率 0.438%,其中最長連續缺 8 個 slot(約 1.7 秒),沒有任何超過幾秒的停擺;接手前 epoch 1064 的前 5,000 個 slot 產出 4,960 個,略過率 0.80%。前一段只有 40 個缺席樣本,差距不一定有意義。slot 間隔也變了:接手前 5,000 個 slot 用了 1,075 秒(0.2150 秒),接手後從 13:54:03 到 23:01:02 平均 0.2129 秒,快 1.0%,但 epoch 1063 整段是 0.2165 秒,我不知道這個變化來自共識換手、負載還是別的原因。Genfinity 轉述社群看板「96% 的區塊走快速路徑」,我沒有找到儀表板本身,視為未驗證;「150 毫秒最終性」仍是設計目標,我也沒有量到。
三、我的外推錯在哪:晚了 3 分 55 秒
昨天我預報 epoch 1064 在 13:36 到 13:43 開始,中位的 0.21705 秒/slot 給 13:40;實際 13:36:05,落在區間最低端,並且是比我「最近幾個 epoch 的最低」(0.21611)這一列還只晚 5 秒。事後算:epoch 1063 從 10/20 11:37:20 到 10/21 13:36:05,共 93,525 秒(25 小時 58 分 45 秒),每 slot 0.21649 秒,比 epoch 1062 的 0.21765 快 0.5%;而我外推時抓的是「epoch 1063 已走部分」的 0.21705,剩下的 242,728 個 slot 其實用了 52,443 秒,每 slot 0.21606,比前面快 0.46%。官方的「約 13:20」早了 16 分 5 秒,即快了 1.8%,不過那是估計值還是設計值,頁面始終沒說。
教訓有兩個。第一,每 slot 秒數在同一個 epoch 內不是定值,後半段傾向更快,外推應該給區間而不是單點;區間 13:36 到 13:43 包住了實際值,單點 13:40 沒有。第二,下一個邊界我可以先預報:epoch 1064 目前在 slot 索引 159,158(23:01:02 UTC),剩 272,841 個 slot;用接手後的 0.2129 秒算,epoch 1065(第 460,080,000 個 slot)在 10 月 22 日 15:09 UTC 開始;用 epoch 1063 的 0.2165 秒則是 15:25。我把這個區間記成待驗。
四、Hoodi 記分板:11 個穩定版,缺席只剩 Grandine
| 10/17 | 10/19 23:01 | 10/20 23:05 | 10/21 23:10 UTC | |
|---|---|---|---|---|
| 含 Hoodi 時間戳的穩定版 | 7 | 8 | 10 | 11 |
| 缺席 | 5 | 4 | 2 | 1(Grandine) |
| 距分叉(天) | 8.78 | 6.78 | 5.78 | 4.77 |
穩定版的定義不變:非預發布的 GitHub 發布,且含 Hoodi 排程提交。新到的是 Geth v1.17.9,發布說明第一句話是「此版在 Hoodi 測試網啟用 Amsterdam 分叉,區塊時間戳 1793036568(2026 年 10 月 26 日 17:42:48 UTC)」,「建議所有在 Hoodi 上跑節點的使用者升級」,並列出 Amsterdam 排程提交(PR 35974 號)。執行層六個客戶端現在全部有穩定版:Besu 26.10.0、Nethermind 2.2.0、Ethrex v30.0.0(另有預發布 v30.0.1-rc.1,10/20 22:00:25 UTC)、Erigon v3.8.0、Reth v2.8.0、Geth v1.17.9。共識層六個裡 Lodestar 1.50.0、Nimbus 26.10.1、Prysm v7.3.0、Teku 26.10.1、Lighthouse v8.3.0 是穩定版,Grandine 仍只有 3.0.0-rc.1。Grandine 的主分支今天還在動(最新提交 10/21 13:53:30 UTC「Handle optimistic heads in Gloas」,前面是依賴更新),rc.0 到 rc.1 隔了 19.04 天,所以 3.0.0 穩定版會不會在分叉前出,我維持 20%。
Geth 發布說明裡跟測試網營運最相關的幾條:EVM 直譯器指令分派改寫,宣稱快 16%;三個修復針對斷電造成的資料庫損毀與狀態字典樹(trie)資料庫的並行讀取;一個修復針對「RPC 呼叫與區塊處理並行時區塊級存取清單(BAL)可能損毀」;eth_call 之類的方法現在會拒絕與當前分叉不符的欄位,歷史 RPC 呼叫會拒絕尚未啟用的交易功能。後兩項會改變上層工具的行為(例如拿新欄位去查舊區塊會被拒),與昨天提醒的 Engine API 錯誤碼是同類問題。這些我讀的是發布說明原文,沒有實測。
五、ACDE 第 248 次議程變了:安全議題排第一
我昨天讀的議程(ethereum/pm 第 2267 號議題)第一項是沒有子項的 Glamsterdam;今天重讀,第一項底下多了三條:EIP-8037 與 EIP-8038 的安全疑慮(附 pcaversaccio 的留言與 ChainSecurity 文章)、Hoodi 10 月 26 日分叉、以及主網日期候選(12 月 1 日、8 日、9 日,只是知會,由 barnabasbusa 提出),議程寫「若 Hoodi 順利,目標在下週 ACDC 定日期」。ACDC 第 190 次排在 10 月 29 日,所以主網日期最早是 Hoodi 分叉後三天才有機會敲定,官方仍沒有單一日期。
安全議題的內容是這樣:pcaversaccio 在 10 月 21 日 16:20:13 UTC 留言,說 ChainSecurity 找到「嚴重」的應用層風險(對受影響協議的揭露仍在進行),根本問題是「gasleft() 可以增加」,並主張這些發現值得重新評估這次硬分叉。我讀了 ChainSecurity 的文章(WebFetch 的摘要;頁面標示發表於 10 月 13 日,但留言顯示揭露還在進行,所以日期我不確定)與 EIP-8037 原文。機制拆開來是這樣:
EIP-8037 把「建立狀態」的 gas 獨立計價。交易的執行 gas 上限(TX_MAX_GAS_LIMIT)是 16,777,216,超出的部分進一個「狀態 gas 儲備」,儲備整份傳給子呼叫,不受 EIP-150 的 63/64 規則限縮;每個狀態位元組 1,530 gas(CPSB,依原文推導目標是每年約 120 GiB 狀態成長);新儲存槽 64 位元組,即 64 乘 1,530 等於 97,920 狀態 gas,新帳戶 120 位元組、183,600。GAS 指令只回傳執行 gas,不含儲備。EIP-8038 則重新定價狀態存取。ChainSecurity 算出冷的、新的儲存槽寫入,在不能動用儲備時要 110,020 執行 gas,舊規則是 22,100(自算 110,020 除以 22,100 約 4.98 倍)。
風險有四個:一,有儲備時只剩約 15,000 執行 gas 也能寫一個冷的新槽,過去這會 revert,所以靠「剩餘 gas 夠不夠」判斷子呼叫失敗原因的合約會誤判;二,清除一個同交易建立的槽會立刻退回最多 97,920 狀態 gas,使 gasleft() 增加;三,中間合約 revert 時,它的狀態建立費用會先記回 gas_left,再把剩餘 gas 還給呼叫者;四,重新定價後,固定 gas 預算的合約可能原本夠用、現在不夠。EIP-8037 原文自己也寫:靠 gasleft() 差值計量子呼叫消耗的打包協議,無法正確歸因由儲備支付的狀態 gas。文章建議在分叉前審計失敗處理程式、在新舊兩套 gas 規則下強迫子呼叫失敗做測試。
這件事跟 Hoodi 的關係我只能說到這裡:議程把它放在 Glamsterdam 底下,EIP-8037 目前是 Last Call(截止 2026 年 11 月 1 日),而 Hoodi 的 gas 上限在分叉 epoch 升到 2 億,遠高於 16,777,216,所以儲備機制在 Hoodi 上一定會被碰到;但我沒有驗證 Hoodi 的 Amsterdam 設定是否已包含這兩個 EIP 的最終版本,也沒有看到任何客戶端因此改排程。測試網的意義之一正是讓這類問題在主網前浮現,所以風險落在主網日期而不是 10 月 26 日這個測試網日期。我的判斷(不是事實):這件事最可能的結果是規格調整(例如讓 gasleft() 不增加,或把儲備計入 GAS),而不是整個分叉延期。
🧠 記
- Alpenglow 實測: epoch 1064 開始 13:36:05 UTC,最後一個 TowerBFT 區塊第 459,652,999(13:54:00,649 筆投票、402 筆非投票),第 459,653,000 到 007 無區塊,接手後第一個區塊第 459,653,008(13:54:03,0 筆投票、1,701 筆非投票)。使用者交易中斷最多約 3 秒。官方頁面數字:446 個驗證者(共 654)簽創世票,交接約 900 毫秒;我數位元遮罩得 449,差異未解。
- 投票占比: 接手後 4.3 小時取樣 36,821,474 筆交易只有 6 筆投票;總 TPS 約 5,418 掉到 2,397,非投票 TPS 約 2,353 到 2,397,是統計口徑改變。略過率 0.438%,最長連續缺 8 個 slot。
- 我的外推: 單點 13:40,實際 13:36:05;epoch 內後半段每 slot 更快(0.21606 對 0.21705);下一個預報 epoch 1065 在 10/22 15:09 到 15:25 UTC。
- Hoodi: 穩定版 11 個,缺 Grandine;Geth 合併到發布 1.69 天,與 Sepolia 先例 1.71 天一致,同一客戶端先例比跨客戶端平均可靠。距分叉 4.77 天。
- ChainSecurity 與 EIP-8037: 儲備超出 16,777,216 的 gas、不受 63/64 規則限縮;新儲存槽 97,920 狀態 gas;
gasleft()可因退款增加;冷新槽寫入 110,020 對舊 22,100 約 4.98 倍(ChainSecurity 的數字)。主網日期候選 12/1、12/8、12/9,目標下週 ACDC 定案。
邊界: Solana RPC 與 GitHub 為 10 月 21 日 23:00 到 23:15 UTC 的讀取結果,區塊內容來自公開 RPC 的 getBlock,只看了五個區塊,取樣窗口只含接手後 4.3 小時。solana.com、SolanaCompass、The Block、Genfinity、ChainSecurity 與 EIP-8037 頁面都是 WebFetch 回的摘要,不是原始 HTML;ChainSecurity 的數字未經我重現,SolanaCompass 說的「官方帳號 13:59 UTC 宣布」是單一次級來源。「八個 slot 被回滾」是我對 SIMD-0384 的解讀,RPC 沒有直接顯示。ACDE 第 248 次尚未召開,議程可能再改。這些是技術研究,不構成任何投資、質押、購買、合約部署或節點營運建議。
✍️ 實踐
全部唯讀,約 35 分鐘。
- 驗證接手時刻(約 10 分鐘):
R=https://api.mainnet-beta.solana.com
for s in 459648000 459652999 459653008; do
curl -s $R -X POST -H 'Content-Type: application/json' \
-d "{\"jsonrpc\":\"2.0\",\"id\":1,\"method\":\"getBlockTime\",\"params\":[$s]}"; echo
done
curl -s $R -X POST -H 'Content-Type: application/json' \
-d '{"jsonrpc":"2.0","id":1,"method":"getBlocks","params":[459652995,459653012]}'
curl -s $R -X POST -H 'Content-Type: application/json' -d '{"jsonrpc":"2.0","id":1,"method":"getAgGenesisCert"}' | head -c 600把區塊時間轉成 UTC(date -u -r 或 Python),確認 epoch 起點與接手時間;用 getBlocks 數出缺的 slot。
- 數區塊內的投票交易(約 8 分鐘,公開 RPC 有速率限制,每次請求間隔幾秒):
import json, subprocess
R = "https://api.mainnet-beta.solana.com"
V = "Vote111111111111111111111111111111111111111"
def block(s):
body = {"jsonrpc":"2.0","id":1,"method":"getBlock",
"params":[s, {"transactionDetails":"full","rewards":False,"maxSupportedTransactionVersion":1}]}
out = subprocess.run(["curl","-s",R,"-X","POST","-H","Content-Type: application/json","-d",json.dumps(body)],
capture_output=True, text=True).stdout
return json.loads(out)["result"]["transactions"]
for s in (459652999, 459653008):
txs = block(s); v = 0
for t in txs:
m = t["transaction"]["message"]
keys = [k if isinstance(k, str) else k["pubkey"] for k in m["accountKeys"]]
v += any(keys[i["programIdIndex"]] == V for i in m["instructions"])
print(s, len(txs), v)對照 SIMD-0384 的第 2 與第 5 步,說明為什麼接手後第一個區塊的投票數是 0。
-
預報 epoch 1065(約 7 分鐘):用
getEpochInfo取目前 slot 索引,用接手後的 0.2129 秒與 epoch 1063 的 0.2165 秒各算一次,寫下區間;事後(約 15:30 UTC 後)用getBlockTime查第 460,080,000 個 slot,看區間有沒有包住。 -
讀 ChainSecurity 與 EIP-8037(約 10 分鐘):自己寫一段 Solidity 或偽碼,內容是「呼叫外部合約後,用
gasleft() < gasReq / 63判斷是否因 gas 不足而失敗」,逐步套四個風險機制,看哪一步判斷會錯。再回答:EIP-8037 為什麼要讓儲備不受 63/64 限縮,這個設計選擇換來什麼、又丟掉什麼? -
想一想:如果你是錢包或交易所,Alpenglow 接手後「總 TPS 腰斬」該怎麼在介面與客服說明裡不被誤解;以及為什麼 Geth 這次的發版時間,用同客戶端的 Sepolia 先例比用三個客戶端的平均預測得準。
可證偽預測(時間都是 UTC;「穩定版」指非預發布的 GitHub 發布且含 Hoodi 排程提交):
- 預測一(10 月 22 日 14:00,ACDE 第 248 次前): Grandine 穩定版 3.0.0 5%;官方文件(議程或紀錄)明列單一主網日期 8%。
- 預測二(ACDE 第 248 次之後、10 月 26 日 17:42:48 前): Grandine 穩定版 3.0.0 20%、11 個客戶端全數有穩定版 20%(沿用);Hoodi 分叉如期在 epoch 132352 啟用 88%(昨天 90%,因安全議題下修);分叉後 10 個 epoch 內最終確認出現 80%(沿用);ACDE 第 248 次後 Hoodi 時間戳被任何客戶端的新發布改動 7%。
- 預測三(EIP-8037 與 EIP-8038): 11 月 1 日(Last Call 截止)前,EIP-8037 或 EIP-8038 出現明確修改
gasleft()或儲備行為的 PR 並合併 40%;11 月 10 日前任一者被移出 Glamsterdam 12%;主網單一日期在 10 月 31 日前公布 45%,若公布,落在 12 月 8 日或 9 日 60%。 - 預測四(Alpenglow): 10 月 22 日 13:54 UTC 前沒有超過 1 小時的出塊停擺 95%(目前最長缺 8 個 slot);epoch 1065 的第一個 slot 落在 10 月 22 日 15:05 到 15:30 之間 85%;10 月 22 日 23:00 UTC 再取樣,投票占比低於 0.1% 95%、非投票 TPS 在 2,000 到 3,000 之間 85%;Anza 或可信第三方在 10 月 25 日前公布創世憑證的質押占比 25%。
- 預測五(以下沿用): 第 5734 號 PR 10 月 23 日前合併 15%、EIP 第 12513 號 PR 10%;Ledger 10 月 24 日 23:59 前官方公告受影響裝置數或損失總額其中之一 25%;Cysic 10 月 25 日 23:59 前公布事後調查報告 50%;Gamdom 10 月 23 日 23:59 前公開儲備證明 20%。
明天接的待辦:ACDE 第 248 次的結論(安全議題、Hoodi 日期、主網日期候選)、Grandine 的狀態、epoch 1065 的實際開始時間、Alpenglow 接手滿 24 小時的穩定度、創世憑證質押占比有沒有公布。
🔗 延伸學習
- Alpenglow(solana.com) — 官方遷移紀錄:epoch 1064、創世區塊第 459,652,999 個 slot、446 個驗證者、
getAgGenesisCert驗證方式。 - Geth v1.17.9 發布說明(GitHub) — Hoodi 的 Amsterdam 排程、EVM 加速與 RPC 行為變更。
- Glamsterdam 的 gas 風險分析(ChainSecurity) — EIP-8037 與 EIP-8038 對
gasleft()檢查模式的四種破壞機制與審計建議。 - EIP-8037:State Creation Gas Cost Increase — 狀態 gas 儲備、CPSB 與 63/64 規則的原文規格。
💬 問 AI
我在追蹤 Solana Alpenglow 的主網遷移與 Ethereum Glamsterdam 的 Hoodi 測試網就緒度(查證時間 2026-10-21 23:00 到 23:15 UTC,資料來自 Solana 公開 RPC、GitHub API、solana.com、ChainSecurity 與 EIP-8037 頁面)。以下是我整理的主張與推導,請協助查證並嚴格區分來源:
1. 事實(Solana RPC):epoch 1064 起點 slot 459,648,000 的區塊時間是 2026-10-21 13:36:05 UTC;最後一個 TowerBFT 區塊 459,652,999 在 13:54:00,含 1,051 筆交易(649 筆投票);459,653,000 到 459,653,007 無區塊;459,653,008 在 13:54:03,含 1,701 筆交易、0 筆投票。官方頁面稱創世憑證由 654 個驗證者中的 446 個簽署,交接約 900 毫秒;我自己數 getAgGenesisCert 位元遮罩得 449 個設定位元。
2. 我的推論:依 SIMD-0384(邊界 slot S = X + 5000,從 S 起只准投票交易,收到 82% 質押的創世憑證後回滾到創世區塊並恢復使用者交易),八個無區塊的 slot 是被回滾的投票專用區塊,使用者交易中斷最多約 3 秒。
3. 效能取樣:256 筆、71,990 個 slot、15,360 秒,總交易 36,821,474、非投票 36,821,468(投票 6 筆);非投票 TPS 約 2,397;昨天(遷移前)總 TPS 約 5,418、非投票約 2,353。
4. Epoch 時間:epoch 1063 長 93,525 秒(每 slot 0.21649 秒);我昨天的外推是 13:40,誤差 3 分 55 秒;接手後平均每 slot 0.2129 秒。
5. 以太坊:Geth v1.17.9(2026-10-21 15:08:46 UTC)明列 Hoodi 的 Amsterdam 排程(時間戳 1793036568);排程提交合併到發布 1.69 天,Sepolia 先例 1.71 天。含 Hoodi 排程的穩定版共 11 個,缺 Grandine(只有 3.0.0-rc.1)。
6. ChainSecurity 與 EIP-8037:執行 gas 上限 16,777,216,超出部分進狀態 gas 儲備且不受 63/64 規則限縮;新儲存槽 64 乘 1,530 等於 97,920 狀態 gas;ChainSecurity 稱冷的新槽寫入在不能動用儲備時要 110,020 執行 gas(舊規則 22,100);清除同交易建立的槽會退回最多 97,920,使 gasleft() 增加。
請幫我:
(a) 檢查第 2 點:八個無區塊 slot 是回滾所致還是單純沒有出塊?請引用 SIMD-0384 或 Agave 實作原文;查不到就明說;並說明 449 與 446 的差異可能怎麼來(位元遮罩編碼、填充位元、計數口徑);
(b) 檢查第 4 點:為什麼同一個 epoch 內後半段每 slot 時間會比前半段短?Alpenglow 接手後 slot 間隔變化是否與共識換手有關;
(c) 用第 6 點的機制,寫出一個 Solidity 範例(用 gasleft() < gasReq / 63 判斷子呼叫失敗原因)在 EIP-8037 與 EIP-8038 下會誤判的最小情境,並說明審計時該測什麼;
(d) 說明 Geth 用自己的 Sepolia 先例預測 Hoodi 發版時間,為什麼比用跨客戶端平均更準,以及這個推論的樣本限制;
(e) 分三類標示每個結論:「文件明說的」、「你另外查證到的(附網址)」、「你的推論」,不要編造連結或數字,不確定就說不確定。
這是技術研究,僅供學習,不需要也請不要給任何投資、質押、購買、合約部署或節點營運建議。