原創主題配圖: 鏈觀 BTC866 原創主題圖解 · ChainView BTC866 Editorial · CC BY 4.0
確認代表區塊中的位置
交易被某個區塊收錄後，通常開始累計確認數；後續區塊繼續建立在該歷史上，重新改寫交易位置的成本通常增加。確認數是觀察鏈狀態的指標，不是由客服發放的保證。不同網絡的共識機制、區塊間隔和安全假設不同，不能把一個網絡的六次確認機械地換算成另一個網絡相同程度的保障。
短暫分叉為何出現
傳播延遲可能使不同節點短時間看到不同的鏈頭，節點隨後按各自規則選擇有效歷史。重組會使原先被收錄的交易回到待確認狀態，或者被衝突交易替代；它不等於所有歷史都被隨意刪除。觀察時記錄舊區塊和新區塊的哈希、共同祖先及涉及交易，區分真實重組與瀏覽器顯示延遲或索引錯誤。
概率最終性與經濟最終性
工作量證明通常通過累積工作量提高改寫難度，權益證明網絡可能設置檢查點和最終性投票。經濟最終性依賴懲罰機制、參與條件與攻擊假設，也不意味著軟件絕不出現嚴重缺陷。閱讀文檔時區分“頭部”“合理化”“最終確定”等狀態，確認數據接口的含義；某個平台顯示“完成”可能只是其內部業務狀態。
離線與網絡異常情景
節點長時間離線後，需要重新同步並核對共識狀態。網絡分區、客戶端故障或驗證者參與不足可能減慢確認或最終確定，不能用平常出塊時間推算確定到賬時刻。運營者應記錄同步進度、對等連接和最終性滯後，必要時暫停依賴低確認的業務，而不是僅靠增加瀏覽器刷新次數來判斷網絡恢復。
應用層為何繼續等待
交易平台、橋和商戶會根據金額、資產與風險設置額外確認閾值。鏈上已最終確定但平台尚未入賬，可能與賬戶審查、備注字段或維護有關。用交易哈希區分鏈上狀態和業務狀態，再查閱接收方要求。對於不可逆交付，不應只依據錢包通知；應從可信節點或多個獨立數據源核驗預期金額和接收條件。
設計最終性記錄表
記錄表至少包含網絡、交易哈希、首次見到時間、收錄高度、區塊哈希、確認狀態和接收方入賬時間。發生重組時保留前後狀態，避免用單張截圖覆蓋整個過程。測試可以使用公開歷史樣本或測試網，無需發送真實資金。記錄的價值在於識別等待發生在哪一層，而不是聲稱達到某個數字後所有風險都會消失。
具體核驗案例
假設交易先進入高度一百的區塊，隨後節點切換到另一條分支，使該交易重新進入等待狀態。記錄舊塊哈希、新鏈頭與最終重新收錄高度，不能只保留最後“成功”的截圖。若平台要求更多確認，還應另記其入賬時間。這個時間線可以解釋鏈上重組和業務等待分別佔用多久，也能防止把平台延遲錯誤歸咎於協議最終性或把短暫重組誤報為永久丟失。
