Ream 簽署測試揭露金鑰準備邊界與錯誤處理缺口

值得記下的 5 件事

1. [2:00]
   衝突測試應直接觀察簽署路徑 Mohit 指出，接收端能保存競爭分支，拒收第二個區塊並非合適判準

   他讓 Hive 使用與正式出塊共用的簽署器，觀察同金鑰、同時槽能否簽署不同區塊根。雖然實驗產生兩份有效簽章，他未確認測試端點承諾阻止重用，因此沒有直接判定為漏洞。

2. [4:00]
   驗證簽章必須核對預期身分與請求 Mohit 不只檢查客戶端回傳的公鑰與簽章是否相符，也從設定中的登錄資料取得預期公鑰，再用獨立的 Python LeanSpec 驗證器核對簽章、區塊根與時槽

   他提醒，未來測試另一個客戶端前，須先確認簽章參數、雜湊函數與編碼相容，避免把測試設定問題誤認為客戶端漏洞。

3. [1:00]
   金鑰啟用不等於簽署材料已備妥 Mohit 展示，針對已啟用但尚未備妥材料的時槽提出請求，會使 Ream 的 RPC 請求處理單元異常並關閉連線，但整個程式仍繼續運作

   他區分啟用範圍、準備範圍與簽署歷史，並在呼叫函式庫前加入準備範圍檢查。本機修正版通過相關測試；邊界請求則允許回傳有效簽章或可供程式辨識的拒絕回應，不強求自動準備。

4. [8:20]
   準備服務必須辨識無法前進的狀態 Mohit 發現，底層函式抵達限制後會原樣回傳金鑰，但服務層測試使用總能前進的模擬物件，漏掉持續重試的情境

   他改用實際服務與小型測試金鑰，限制測試中的嘗試次數，並在服務中加入進度檢查，讓準備範圍未向前移動時回傳錯誤，而非無限重試。

5. [9:00]
   拒絕錯誤請求後仍須完成有效工作 Mohit 在 Hive 送入未啟用時槽及超出可表示範圍的時槽，每次拒絕後都再要求有效簽章並驗證

   在 LeanSpec 中，他也測試失敗的準備請求不改變儲存的金鑰、合適時槽仍可簽署，以及準備範圍仍能推進至可達的未來時槽。據他說，新增的八個測試案例均通過。