6 月 1 日晚間，TON 主鏈的 masterchain 在 20 : 15–21 : 22（台灣時間，UTC + 8） 停止出塊，整整 67 分鐘。這並非第一次「心跳停格」，但這回 TON Core 團隊的補救速度與流程值得拆開來看看。
事件摘要
⚫️停擺時間與範圍：20 : 15–21 : 22（UTC + 8），僅影響 masterchain 出塊
⚫️根本原因：2024 年 8 月「Dispatch Queue」更新暗藏邏輯 bug，測試網與主網事前皆未觸發
⚫️資產安全：0 筆 TON、Jetton 或訊息遺失
⚫️修復路徑：25 分鐘內定位問題、67 分鐘內恢復出塊，無須硬分叉
⚫️協作節點：Tonwhales、Tonstakers、Unit 410、Twinstake 等主流驗證者同步熱修補
簡單講：Bug 怎麼讓鏈「熄火」？
1. 區塊生成前置作業
每個 masterchain 區塊都會把 Dispatch Queue 的訊息搬到 OutMsgQueue，並更新
max_lt（用來排序交易的邏輯時間）。2. 錯誤觸發
這次搬運時，程式把一筆 tick 交易的
current_lt 誤設得比區塊起始 start_lt 還大，所有驗證節點因此拒絕候選區塊。3. 鏈條空轉
共識需要「合法候選區塊」，當「誰都投不出合格作品」時，鏈便卡在原高度無法前進。
為何「只更新少數節點」就能救活？
Bug 發生在「生成區塊」端，而非「驗證區塊」。只要輪到一名已打補丁的驗證者提案，其餘節點就能順利驗證並簽名。這種「少數點火、多數驗證」的設計，是 TON 在效率與安全間取得平衡的關鍵。
後續行動
⚫️測試流程升級：新增 governance 交易與混合高負載腳本，未來每次節點更新都跑 stress test。
⚫️正式合併時間：修補程式將於本週 merge 進 master branch，其他驗證者可依排程更新。
這 67 分鐘證明兩件事：
1. 軟體沒有 100 % 完美 — 再小的更新也可能埋雷，需要完善監控與熱修復機制。
2. 去中心化 ≠ 無組織 — 協作網絡若能在鐘擺式輪值下同步打補丁，才算真正「抗單點故障」。
想像若相同 bug 發生在 TPS 更高、驗證者溝通稀疏的鏈上，停擺時間可能倍數成長。TON 這次「少數急救、多數驗證」策略，為這次的迅速回復打下了堅實的基礎。
⛓官方報告
———————————————
@SighToNews 看新聞
修補快、協作強，TON 穩定性再進化