Transient storage, a transient trend? | Valerian Callens (Quantstamp)

Transient Storage 的故事始於六年前的 EIP-1153 提案，直到今年的 Dencun 升級才正式並入 EVM。它的核心特性只有兩點：便宜，以及交易結束即清零。開發者可以在 Solidity 與 Viper 中透過 `transient` 關鍵字直接使用，也可透過底層操作碼 `TLOAD`/`TSTORE` 操作，每個槽以 32-bit 標識符定址。EIP 最初預設了六種應用場景，從重入保護到代幣授權均有涵蓋，為這項技術描繪了一張相當完整的用途地圖。

在實際採用上，透過 GitHub 搜尋可以發現，早期結果多為客戶端與開發工具在跟進 Dencun 支援，但真正具代表性的生產用例已經出現：Uniswap V4 與 Balancer V3 以 T 存儲實作 Flash Accounting（閃存記帳），利用交易結束自動清零的特性省去了手動重置的成本。多數項目的採用路徑相似——先以最簡單的瞬態重入保護切入，再視需求升級為「Transient Context」模式，即將一組相關的瞬態變量統一管理，並搭配專用庫（如 Transient Slot Doo 庫）處理槽的分配與清理。少數項目的採用被推遲，原因通常是代碼庫其餘部分尚未準備好升級至 Solidity 0.8.24。

安全方面，講者歸納出四個值得關注的風險點。首先，重入檢查邏輯不能只看持久存儲，必須同時考慮 T 存儲的狀態。其次，面向多條 EVM 相容鏈部署時，需用 EVM diff 工具確認各鏈對 T 存儲的實作是否一致。第三，混合使用 `staticcall`（靜態調用）與 `delegatecall` 時，不同槽之間可能發生衝突或偏移。第四，也是最需要設計層面應對的：若同一個槽可被多個用例或多個 Actor 並發存取，Account Abstraction 與批次交易工具有可能觸發意外行為甚至 DoS 攻擊。

針對這些風險，講者提出三個設計模式。「Transient Read-Return 保護」用來防止只讀區域被濫用，透過為 view 函數指定 ID（如 42）並以修飾符在暴露區域前後鎖定/解鎖來實作。「Transient Context 生命週期管理」是其中最重要的模式：核心原則是單用途槽（一槽一用途），以及避免多個 Actor 並行操作同一槽，具體流程為「確認未鎖定 → 鎖定 → 清理 → 初始化 → 使用 → 清除 → 解鎖」。「交易級計數器」則允許對函數在單一交易內的調用次數設限，優點是比持久存儲便宜且能阻止重複重入，缺點是可能限制協議的可組合性。