失敗的以太坊 ICO 九年後奇蹟解鎖：1,003 ETH 的驚人救援故事

九年前的 ICO 為何會「卡死」？

2016 年 8 月，一個名為 HongCoin 的去中心化風險基金在以太坊上發啟 ICO，期待募資失敗後能夠把參與者的 ETH 退還。沒想到，這個看起來單純的退還機制其實藏了一顆長達九年的「炸彈」——合約裡的 refundMyIcoInvestment() 函式在檢查投資人餘額時，只要餘額超過當時已經被減少的 tokensCreated 全域計數，就會直接判定失敗，把本該拿回的 ETH 卡死在合約裡。

大戶投資人的尷尬：錢被卡住卻無法提取

隨著早期的退還陸續發生，tokensCreated 這個全域變數不斷縮水。於是，持有較大 token 餘額的投資者（相當於當年的「 whale」）突然發現自己的餘額變得太「龐大」，反而無法透過退款檢查，這簡直是把「有錢也拿不出來」這句調侃變成了事實。那段時間，很多人只能眼巴巴看著自己在 ICO 時投下的 ETH 在鏈上靜靜躺著，卻束手無策。

一把「老鑰匙」——管理員函式的逆向用法

時間來到 2024 年，一位代號 0xFlorent 的白帽研究人員發現了另一條被遺忘的舊程式碼：mgmtIssueBountyToken() — 這是專為專案管理層設計的管理功能，允許向任意地址發放「賞金代幣」並同步增加 bountyTokensCreated。關鍵在於，這段程式碼在 2016 年的編譯環境下採用了「溢位自動迴繞」的行為（類似 Solidity <=0.7.x），也就是當運算結果超過 uint256 上限時會直接繞回而非拋錯。

用「舊bug」開啟「舊鎖」的操作細節

0xFlorent 利用這個管理函式先把大戶的餘額人為地調低至適合 refundMyIcoInvestment() 透過的水準，然後再利用同一把多重簽名（multisig）管理金鑰簽署 41 筆交易，讓這些「調整過」的帳戶可以成功呼叫退款。較小的七位投資者則不必經歷這道彎路，直接透過正常的 refundMyIcoInvestment() 取回款項。這整個過程可說是「合約考古」——在不改變原始程式碼的情況下，找出過去的許可權路徑將錯誤逆轉。

背後的關鍵：原始管理金鑰與多方協作

或許你會問：「難道不能直接用新合約把這些漏洞修補嗎？」答案是「不行」，因為這是一段「已部署且不可篡改」的程式碼，任何外部改動都會破壞區塊鏈的「不變性」。因此，這次的救援完全依賴於原始的多重簽名管理位址仍保持活性，且願意配合 0xFlorent 的協調。可以說，這是一場「程式碼+ 金鑰」的雙重搶救。

從此案例看以太坊的「長久記憶」

HongCoin 的故事 並非例外。近年來，以太坊社群的考古行動屢見不鮮：

• The DAO 事件（2016）— 12 百萬 ETH 被硬分叉找回。
• Parity 多重簽名庫（2017）— 513,774 ETH 因自毀被鎖住，至今仍有部分無法動用。
• 根據 2025 年分析師 Conor Grogan 的估計，因錯誤而「永久失去」的 ETH 超過 913,111 枚，這還只是保守下限。

這些案例顯示以太坊的底層邏輯不僅保障了資產的安全，也同時儲存了早期的技術假設和漏洞。只要許可權仍在、程式碼仍在執行，某天就可能被人「喚醒」。

給專案方與投資人的警示

1. 保留管理金鑰的生命週期： 如果你的專案曾使用多重簽名或是管理員許可權，千萬別在專案結束後就直接把金鑰丟掉。多年後或許會有意想不到的回收需求。

2. 避免使用過舊的 Solidity 版本： 0.8.0 以後的語法預設會在溢位時 revert，這可以杜絕類似的「自動迴繞」漏洞。升級合約時請做好完整的測試與驗證。

3. 智慧合約的可升級性： 若業務需要長期保留資產，最好支援可升級代理（proxy）或模組化設計，這樣未來才能在不破壞原來狀態的前提下修正缺陷。

4. 白帽合作與公開披露： 如發現類似「被困」的情形，請第一時間聯絡專業的安全團隊或研究者，並遵守負責任的披露流程，避免被惡意利用。

結語：一場「區塊鏈考古」的奇蹟

HongCoin 讓 1,003 ETH（約 199 萬美元）在沉寂九年後奇蹟般回到投資人手中。這不僅是一次成功的「合約救援」，更是對以太坊長期記憶特性的深刻提醒：區塊鏈會記住錯誤，也會記住那些曾被遺忘的救贖之門。 或許未來還會有更多類似的「老合約」等著被重新發現，而在這個過程中，程式碼的安全性、管理金鑰的可獲取性、以及社群的協作精神，將是我們能否把「失落的財富」重新找回的關鍵。

如果你也是曾在 2016 年參與過 ICO 的投資者，或者是正在開發新一代 DeFi 方案的工程師，或許現在正是時候回去檢視一下你在鏈上留下的「老金鑰」——它們可能比你想像的更有價值。