Binance 63 億美元巨額資產遭竊背後：一個錢包，為什麼能突然開始「執行程式碼」？

從 Binance 63 億美元資產遭竊事件切入，理解一個普通 Ethereum 錢包為什麼能突然開始執行程式碼，以及 EIP-7702 如何改變錢包的使用方式與安全邊界。

Binance 63 億美元資產事件與 EIP-7702 封面

Binance 14 事件

2026 年 10 月 30 日凌晨，鏈上開始出現一串很不尋常的資金移動。

幾個和 Binance 有關的錢包，突然開始把大量資產往外轉。Bitcoin、Ethereum、Tron、Solana 等多條鏈陸續出現異常流出，金額大到很難把它當成一般的資金調度。光是後來 Ethereum 上那筆主要資產轉出，就包含約 167,464 ETH、約 16.15 億 USDT，另外還有數十種 ERC-20 代幣。很快，市場開始追地址、看交易、比對資金去向，Binance 也公開表示正在調查安全事件，並暫停部分存提款相關服務。

但在 Ethereum 這一側，有一個細節特別奇怪。

大家熟悉的 Binance 14 熱錢包，在巨額資產被轉走之前，並不是立刻出現一筆「把錢搬走」的交易。

真正先發生的，是另一件看起來沒那麼醒目的事。

這個地址先出現了一次和 EIP-7702 有關的帳戶授權變化。

幾分鐘後，才是大家真正注意到的畫面：巨額 ETH、USDT 和其他代幣開始被轉出。

也就是說，如果你只盯著最後那幾筆巨額轉帳，你看到的是結果；真正值得追的變化，其實更早就發生了。

這也是這件事最吸引我的地方。

過去我們看到一個普通的 Ethereum 錢包地址，通常直覺會認為它就是「一把私鑰控制資產」。但在這次事件裡，Binance 14 在資產被搬走前，先經歷了一次和 EIP-7702 有關的帳戶能力變化。

這讓一個原本很像協議文件裡才會出現的 EIP，突然變成一個很現實的問題：

如果一個普通錢包開始可以把自己的執行能力交給程式碼，那我們還能用以前的方式理解它嗎？

這件事很快讓 EIP-7702 從一個原本偏協議層、很多人沒特別注意的 Ethereum 功能，變成安全圈開始討論的焦點。

需要先說清楚的是：**EIP-7702 本身不是漏洞，也不是這次事件的「攻擊程式」。**它本來是 Ethereum 用來改善帳戶體驗的一項重要升級。只是這次事件剛好讓大家看到，當一個普通錢包開始具備「把執行能力交給程式碼」的能力後，簽名與授權的安全邊界也跟著改變了。

所以這篇我不打算追完整個 Binance 事件，而是想借這個例子，把 EIP-7702 到底改變了什麼講清楚。

先從最基本的問題開始：一般錢包原本是怎麼運作的？

以太坊帳戶大致可以先粗分成兩種：

EOA（Externally Owned Account）
Contract Account

我們平常用 MetaMask、硬體錢包或私鑰控制的地址，大多是 EOA，也就是由私鑰直接控制的帳戶。

傳統 EOA 的模型非常簡單：

Private Key
    ↓
Sign Transaction
    ↓
EOA 發送交易

它本身沒有程式碼。

所以很多比較進階的功能，例如：

一次執行多個操作
讓第三方代付 Gas
設定每日轉帳上限
建立 session key
增加 recovery 機制
對不同操作給不同權限

通常都需要 Smart Contract Wallet 或 Account Abstraction。

EIP-7702 想解決的問題，就是讓既有的 EOA 不必換地址，也可以逐步擁有 Smart Account 的能力。

它隨 Ethereum Pectra upgrade 在 2025 年 5 月 7 日正式進入主網。

EIP-7702 到底做了什麼？

最精簡的說法是：

EIP-7702 允許一個 EOA 指定：「之後請用某個已部署合約的程式碼來處理我的執行邏輯。」

EIP-7702 新增了一種 Type 4 transaction。

交易裡可以帶一組 authorization_list，其中每一份 authorization 包含：

[chain_id, address, nonce, y_parity, r, s]

其中 address 是要委託的已部署程式碼地址，而 nonce 用來限制這份授權只能在特定帳戶 nonce 下生效。y_parity / r / s 則是 authority 對這份 authorization 的簽名。

驗證成功後，以太坊會在這個 EOA 上寫入一個 delegation indicator，指向指定的合約地址。

概念上可以想成：

你的 EOA
0xABC...

原本：
沒有 code

EIP-7702 delegation 之後：

0xABC...
   ↓
delegate to
   ↓
0x123... 的 contract code

重點是：

地址沒有換。私鑰也還是原本那把。資產也還是在原本的 EOA。

改變的是這個帳戶在被呼叫時，可以開始執行另一份合約程式碼；delegation 會持續存在，直到被新的 authorization 替換或清除。

這就讓一個原本很單純的 EOA，開始具備 programmable account 的能力。

為什麼這件事有用？

因為很多以前做不到、或必須換成 Smart Contract Wallet 才做得到的 UX，可以直接出現在既有地址上。

例如一個 DEX 操作，過去可能是：

Approve USDC
↓
等待確認
↓
Swap USDC → ETH

EIP-7702 可以讓錢包把多個操作 batch 在一起。

使用者看到的可能只剩：

Swap USDC → ETH

底下其實一次完成 approve + swap。

另一個重要用途是 Gas Sponsorship。

理論上可以讓：

使用者沒有 ETH
↓
App / Relayer 幫忙付 Gas
↓
使用者仍然完成鏈上操作

再往前走，還可以做權限下降（privilege de-escalation）。

例如你可以設計一套 delegate contract：

主私鑰
├── 可以做任何事情
│
└── Session Key
    ├── 每天最多花 100 USDC
    ├── 只能操作某個 DEX
    └── 24 小時後失效

對錢包 UX、遊戲、Agent、支付系統來說，這些能力都非常有價值。

所以 EIP-7702 本身不是「危險功能」，它真正解決的是使用體驗問題。

它解決的是一個存在很久的 Ethereum 問題：

我們已經有大量使用者活在 EOA 世界裡，要怎麼讓這些既有帳戶逐步獲得 Smart Account 的能力？

但安全模型也因此改變了

但風險也正好來自同一個地方。

以前大家對錢包安全最直覺的理解是：

不要洩漏 Seed Phrase
不要洩漏 Private Key
不要亂簽 Transfer / Approve

到了 EIP-7702，還要再加一條：

不要把自己的帳戶 delegation 給你不理解的程式碼

因為 EIP-7702 的 delegation 並不是普通的 ERC-20 approve。

ERC-20 approve 通常是在說：

我允許某個 spender 動用最多多少枚這個 token。

但 EIP-7702 delegation 更接近：

我允許這份程式碼成為我的帳戶執行邏輯。

這個權限的層級完全不同。

EIP-7702 官方規格甚至直接提醒：如果 delegate contract 寫得不好，惡意者可能取得對 signer EOA 接近完整的控制權。

這不是 EIP-7702 的 bug，而是 programmable account 能力本身的另一面。

能力越大，簽署時需要理解的東西也越多。

EIP-7702 不是把私鑰交給合約

這裡有一個很容易誤解的地方。

Delegation 不是：

把 Private Key 給 Contract

私鑰本身仍然只屬於 EOA 的控制者。

更準確的模型是：

Private Key
   ↓
簽一份 authorization
   ↓
允許 EOA 使用指定 contract code

而且 EOA 的私鑰仍然保有最終控制權，也可以透過新的 authorization 更換 delegation，或把 delegation 清掉。

所以 EIP-7702 並沒有讓 EOA 變成一個傳統意義上的部署合約。

它比較像是：

在既有 EOA 上增加一個可以指向 implementation code 的執行入口。

對一般使用者來說，真正需要改變的是「簽名觀念」

這可能才是 EIP-7702 對一般使用者最值得關注的地方。

Web3 過去已經花了很多年教育使用者：

Sign Message 不等於 Send Transaction。

但現在又多了一種 authorization。

它表面上可能沒有直接顯示：

Transfer 1000 ETH

可是它的實際效果可能比單筆 Transfer 更大。

因此未來錢包不能只顯示：

Sign EIP-7702 Authorization?

Contract:
0x63e8...

然後給使用者一個 Confirm。

真正合理的錢包介面應該要回答：

你正在把帳戶 delegation 給誰？
這份 code 是否已驗證？
是否經過 audit？
它可以執行哪些操作？
是否可以移動 ETH？
是否可以移動 ERC-20？
是否有額外簽名驗證？
是否有限額？
delegation 會持續多久？
如何 revoke？

EIP-7702 官方文件甚至明確建議 wallet 對第三方 delegation 保持高度謹慎。規格本身的措辭其實很重：authorization 指向的 code 對帳戶具有 unrestricted access。

換句話說，錢包不能只是讓使用者貼上一個地址、按下簽名，就把這件事當成普通授權處理。

原因很簡單：

一般使用者沒有能力靠一個 contract address 判斷這份程式碼到底安全不安全。

對我來說，EIP-7702 真正重要的是這個轉變

過去我們常常把 Ethereum account 想成：

EOA = 私鑰控制的簡單帳戶
Contract = 可以執行程式碼的帳戶

EIP-7702 之後，這條界線開始模糊。

一個地址可以同時保留：

原本的 EOA 私鑰
原本的地址
原本的資產
原本的 nonce

但又可以得到：

programmable execution
batch
sponsorship
session key
custom permissions
recovery logic

這其實是 Ethereum 往 Account Abstraction 前進的一個很重要的過渡設計。Pectra 在 2025 年 5 月 7 日啟用後，這不再只是研究提案，而是已經存在於 Ethereum 主網帳戶模型裡的能力。

它讓「智慧帳戶」不一定需要從建立新地址開始。

但另一面也代表：

我們不能再看到一個 EOA address，就假設它只是單純由私鑰直接控制的帳戶。

以後在做鏈上分析、安全監控、交易模擬甚至風控時，都要多問一個問題：

這個 EOA 現在有沒有 EIP-7702 delegation？它 delegate 到哪一份 code？

這很可能會慢慢變成新的基本檢查項目。

結語

我覺得 EIP-7702 最有意思的地方，就是它同時展示了 Ethereum UX 和安全模型的下一步。

它讓既有 EOA 可以開始擁有 Smart Account 的能力，降低使用門檻，也讓 batching、gas sponsorship、session key 這些功能更容易普及。

但它也讓「我到底簽了什麼」變得比以前更重要。

以前一次危險簽名，大家比較容易把風險理解成一筆 approve 或一筆 transfer。

現在一次危險的 delegation，可能是在改變這個帳戶接下來「怎麼執行程式碼」。

所以如果之後你在錢包裡看到 EIP-7702 Authorization，不要只把它當成另一種 Sign Message。

你真正應該問的是：

我現在是不是正在把自己的帳戶執行權，交給另一份程式碼？

這大概會是 EIP-7702 時代最重要的新安全直覺之一。

參考資料

EIP-7702: Set Code for EOAs
https://eips.ethereum.org/EIPS/eip-7702
Ethereum.org — Pectra / EIP-7702
https://ethereum.org/roadmap/pectra/7702/
Ethereum Pectra upgrade
https://ethereum.org/roadmap/pectra/
本文提到的 EIP-7702 authorization transaction
https://etherscan.io/tx/0xad99264d5532ae0dd04b2004eebda05f25657e70dacb764f7ac8d4ccd051298b