3 億美元被永久鎖死：可升級合約的代理模式，為什麼「方便升級」跟「安全」互相矛盾

既然代理模式風險這麼多，為什麼業界不乾脆放棄可升級設計，全部改用不可變合約？

因為不可變合約有它自己的代價，只是這個代價換了一種形式呈現。如果一個協議管理著數億美元資產，程式碼卻完全無法修改，一旦後續發現任何邏輯漏洞（即使是很小的），唯一的補救方式就是部署一個全新合約、要求所有使用者手動遷移資產——這個過程本身既緩慢又充滿摩擦，使用者可能因為疏忽或不信任新合約而滯留在有漏洞的舊版本裡，實際承受的風險未必比代理模式更低。

這也是為什麼業界至今沒有形成「可升級 vs. 不可變，哪個絕對比較好」的共識，而是傾向把選擇框架成「這個協議需要多快的反應速度來修 bug，跟這個協議願意為了升級彈性犧牲多少去中心化程度」的權衡問題。像 Uniswap 這類核心合約選擇不可變，是因為協議邏輯相對穩定、且社群高度重視「合約規則一旦部署就不會被單方面更動」這個承諾；而許多仍在快速迭代的新協議，則傾向選擇代理模式，用集中化的升級能力換取應對突發漏洞的反應速度。

Parity 事件裡「函式庫合約沒被初始化」是什麼意思？為什麼沒初始化會導致這麼嚴重的後果？

在可升級合約的架構裡，實作合約（或函式庫合約）本身的建構子（constructor）通常不會被直接使用，因為代理合約是透過 DELEGATECALL 借用實作合約的程式碼、卻使用自己的儲存空間——這代表實作合約自己的儲存狀態理論上應該保持空白，真正的初始化動作要透過另一個叫做 initialize() 的函式，在部署後手動呼叫才能完成。問題就出在這裡：如果開發者忘記呼叫這個初始化函式，或者這個函式沒有做好「只能被呼叫一次」的保護，任何人都可能搶先呼叫它，把自己設成該合約的擁有者。

Parity 事件裡，正是因為這個函式庫合約的初始化函式從未被正確鎖定，一名使用者（很可能只是出於好奇或誤操作）呼叫了初始化函式，把自己設成擁有者，接著又觸發了該合約內建的 selfdestruct 功能，把整個函式庫的程式碼從鏈上抹除。因為所有依賴這個函式庫的代理錢包，本質上只是把呼叫轉發過去、自己完全不儲存邏輯，函式庫一旦消失，這些錢包就變成一個個指向空氣的空殼，裡面的資產再也沒有任何程式碼能夠讀取或轉移。

一般使用者除了在 Etherscan 上查「Read as Proxy」，還有沒有其他方式判斷一個代理合約的升級權限有沒有被妥善管理？

除了確認升級控制地址是不是多簽錢包，還可以進一步查這組多簽的簽署門檻設定——例如「5 個簽署人裡需要 3 個同意」跟「2 個簽署人裡需要 1 個同意」代表的安全水準差異很大，門檻設得太低，多簽的保護效果就跟單一密鑰差不了多少。這個資訊通常能在多簽錢包（例如 Gnosis Safe）的官方介面查到，會列出目前的簽署人清單與所需門檻。

另一個值得查的線索是「是否有時間鎖（timelock）機制」——時間鎖代表即使升級指令已經被送出，也必須等待一段公開的延遲期（例如 48 小時）才會真正生效，這段期間內，社群或使用者理論上可以觀察到即將發生的升級內容，如果發現不對勁，還有機會提前把資產撤出。如果一個協議的升級是「送出交易後立刻生效」，代表使用者完全沒有反應時間，這跟有時間鎖保護的協議，實際承擔的風險等級是不同量級的。這些資訊通常需要交叉查閱合約程式碼、官方文件與治理論壇，沒有單一頁面會直接總結給你看，但值得在存入大額資產前花時間確認。

如果我發現一個我持有資產的協議是可升級合約、升級權限也不是多簽，我應該立刻撤出資產嗎？

不一定需要立刻恐慌性撤出，但這確實是一個值得認真評估的風險訊號，而不是可以忽略的技術細節。可升級合約本身不等於危險——許多信譽良好、長期運作穩定的協議也採用代理模式，關鍵差異在於「升級權限的治理品質」，而不是「有沒有採用可升級設計」這個二元判斷。如果升級權限雖然不是多簽，但控制地址本身是知名機構的錢包、且有公開透明的治理紀錄可查，風險評估會跟一個完全匿名、無從查證背景的控制地址截然不同。

比較務實的做法，是把「升級權限治理品質」納入你原本已經在做的盡職調查清單裡——跟審計報告、TVL 規模、團隊背景放在同一個檢查層級，而不是單獨拿出來做非黑即白的判斷。如果評估下來覺得風險超出自己能接受的範圍，逐步減少曝險部位，會比因為單一風險因素就立刻清倉更務實；但如果同時發現升級權限集中、又缺乏時間鎖、團隊背景也難以查證，這種多重風險因素疊加的情況，確實應該提高警覺、認真考慮降低部位。