Prysm 輕客戶端歷史資料回補：供應端已完成，接收端仍待驗證

值得記下的 5 件事

1. [9:40]
   回補要處理輕客戶端更新所需的歷史資料缺口 講者指出，產生輕客戶端更新需要區塊處理後的狀態，而一般節點缺少這些歷史狀態

   因此，專案希望從檢查點回補更新，作為改善資料可用性的一環，而非完整解決方案。

2. [16:20]
   驗證設計透過區塊根雜湊串起信任鏈 流程從受信任的根雜湊取得時期資料，重建區塊根雜湊，並與下一個區塊標頭記錄的父區塊根雜湊比對

   接收端還需選出各週期的最佳更新；這些是設計中的驗證工作，不能視為已完成的成果。

3. [14:20]
   不同分叉需要調整資料型別與驗證證明 講者表示，實作須處理不同協定升級版本的資料型別

   他以 Gloas 的漸進式容器為例，說明其欄位與雜湊樹結構不同，因此也需要調整用來驗證資料的證明建構方式。

4. [18:20]
   供應端從歷史檔案擷取資料，避免重複儲存委員會資訊 講者下載 era 歷史檔案，在記憶體中重播狀態，以取得同步委員會等欄位，再存入 Prysm 資料庫

   他將時期資料與同步委員會分開儲存，因為同一同步委員會週期內，不必為每個時期重複存放相同資訊。

5. [13:20]
   供應端已做介面測試，完整流程仍待驗證 講者表示已完成供應端，並使用 curl 指令測試 REST 介面

   接收端雖有本機嘗試，但尚未運作；他也坦言，資料擷取在空時槽、時期邊界與分叉邊界等情況下，尚未充分檢查正確性。