Spiko 提出事件封存介面，為區塊鏈退場保留可查詢歷史

值得記下的 5 件事

1. [1:40]
   退場計畫須分別處理餘額與歷史 講者將遷移拆成兩部分：使用者餘額，以及鑄造、轉帳、銷毀等事件紀錄

   在 Spiko 的業務情境中，他說明可在鏈仍運作時橋接代幣，或在停運後重新鑄造；歷史紀錄則須另外保存，以支援日後稽核。

2. [3:20]
   封存提案統一事件格式，寫入權限另行設計 EventArchived 事件記錄來源鏈識別碼、交易雜湊（識別交易的數位指紋）、來源地址、事件紀錄索引與原始內容，供後續追溯及解析

   講者將其定位為 ERC 介面提案，而非已確立的標準；寫入流程與權限由各實作決定。

3. [5:00]
   重新收集事件並在目標鏈封存，尚無停鏈遷移實績 講者描述先用索引工具收集來源鏈事件，再送至 Archiver 封存智慧合約，在目標鏈重新發出紀錄，供後續查詢

   他表示尚未替已停運的鏈執行此流程，並建議平時逐步封存，避免一次處理多年紀錄。

4. [7:40]
   以遞增版本修正封存，查詢時須核對版本 講者說明，版本號由合約管理，不由呼叫封存合約的一方指定

   同一事件再次封存時，會增加版本號並發出新事件；讀取紀錄時，再彙整封存事件並依版本號核對，處理重複紀錄。

5. [6:40]
   成本仍須依目標網路與封存規模評估 面對費用與效能提問，講者表示，在第一層網路（L1）封存比第二層網路（L2）昂貴，因此建議使用較便宜的第二層網路

   他認為發出事件的成本較低，但也承認取決於規模；現場未提供具體測試數字。