昨天 passkey 讓使用者用臉或指紋簽下一筆交易,secp256r1 預編譯讓鏈上便宜地驗證那個簽章。但「一次簽一筆」在遊戲、交易機器人、訂閱扣款這類高頻場景裡仍然是災難:玩家每揮一劍都要彈出生物辨識,沒人玩得下去。今天的主角是 session keys(會話金鑰),它把「授權」與「簽名」拆開——使用者用主金鑰簽一次,授出一把受限的臨時金鑰,接下來一段時間內由臨時金鑰代簽,不再打擾使用者。
📖 學
session key 的核心是「範圍受限的委派」:主帳戶不是把全部權力交出去,而是簽發一張帶條件的授權書,授權書裡寫明「這把臨時金鑰只能呼叫哪個合約、只能花多少錢、有效到什麼時候」。臨時金鑰通常是一把普通的 secp256k1 金鑰對,存在 dApp 前端或後端,它自己毫無權力,權力全來自那張授權書。
在標準層面,這件事被拆成兩份規格協作。ERC-7715(wallet_grantPermissions)是 dApp 對錢包喊話的 JSON-RPC 介面:dApp 送出一個 permission 請求物件,說明它要的權限型別(例如 native-token-stream 每秒可花多少、或限定呼叫某合約)、到期時間與 signer,錢包彈一次視窗讓使用者確認,回傳一份可被贖回(redeem)的權限憑證。ERC-7710 則是底層的鏈上委派介面:它定義 Delegation Manager 與 Delegator 的最小介面,規範「一個合約帳戶如何把它有權做的動作,委派給另一個地址去執行」,並要求委派方實作 ERC-1271 以驗證簽章。7715 是「要權限的握手協定」,7710 是「權限如何在鏈上被強制執行」,兩者常一起出現。
流程串起來是這樣的。使用者第一次進 dApp,dApp 呼叫 wallet_grantPermissions,帶上它想要的 session key 公鑰與限制條件;錢包顯示「此 App 想在 2 小時內,代你呼叫遊戲合約、最多花 0.05 ETH」,使用者用 passkey 或主金鑰簽核一次;錢包回傳一個 context(通常是一份簽好的委派)。之後 dApp 每要送一筆交易,就用 session key 對這筆呼叫簽名,連同那份委派一起,透過 Delegation Manager 贖回:管理合約先驗證委派真的來自主帳戶、再檢查這筆動作沒有超出限制(對不對合約、超不超額、過不過期),通過才真正執行。整段期間使用者不再被打擾。
值得注意的是它和帳戶模型的關係。session key 需要一個「能理解並強制執行授權書」的帳戶——這正是 08-21 講的帳戶抽象。若使用者用的是 ERC-4337 智慧帳戶,委派邏輯寫在帳戶合約與 Delegation Manager 裡;若是傳統 EOA,則靠 EIP-7702 在交易期間把智慧合約邏輯「暫時貼」到 EOA 上,讓它也能執行同一套委派檢查。這也解釋了為什麼 session key 天生和批次交易是同一批工具:一旦帳戶會執行任意呼叫,「一次做多件事」與「授權別人限額做事」只是同一個執行引擎的兩種用法。實務上 MetaMask 的 Delegation Toolkit、Coinbase Smart Wallet、Rhinestone、Biconomy 都已有生產級實作。
風險面要清醒:session key 是「把一部分權力放在較不安全的地方」,所以限制條件就是安全邊界。到期時間要短、金額上限要緊、目標合約要白名單化,並且必須能隨時撤銷(revoke)——授權書一旦簽出,唯一的煞車就是這些條件與撤銷機制。
🧠 記
- session key = 受限的臨時金鑰:主金鑰簽一次授權,臨時金鑰在「範圍(呼叫哪個合約)+ 額度 + 期限」內代簽,不再打擾使用者。
- ERC-7715 是 dApp 向錢包要權限的握手介面(
wallet_grantPermissions);ERC-7710 是鏈上委派如何被驗證與強制執行(Delegation Manager + Delegator + ERC-1271)。 - session key 需要會執行授權書的帳戶:ERC-4337 智慧帳戶原生支援,EOA 靠 EIP-7702 暫時獲得同款能力。
- 安全靠限制條件撐住:短期限、緊額度、白名單目標、可撤銷,四者缺一不可。
✍️ 實踐
今天做得完的具體動作:讀 ERC-7715 規格 的 wallet_grantPermissions 一節,把它的請求物件欄位抄下來——chainId、signer、permission(型別與參數)、expiry——弄清楚一個 permission 請求到底長什麼樣。接著用紙筆或白板畫一張「session key 生命週期」流程圖:使用者授權一次 → 錢包回傳委派 context → dApp 用 session key 簽每筆呼叫 → Delegation Manager 驗證委派 + 檢查限制 → 執行或拒絕 → 到期/撤銷。畫完後對自己講一遍:如果 session key 外洩,攻擊者最多能造成多大損失?答案應該完全由你設定的限制條件決定——這就是你今天要培養的直覺。
🔗 延伸學習
- ERC-7715: Request Permissions from Wallets(官方規格)
- ERC-7710: Smart Contract Delegation(官方規格)
- Session Keys & Delegation — ERC-4337 官方文件
- MetaMask:Introducing Advanced Permissions(7715 生產級實作)
💬 問 AI
我在學 session keys(會話金鑰)與錢包權限委派。請用一個具體場景幫我把流程走一遍:
一個鏈上遊戲想讓玩家授權「2 小時內、只能呼叫遊戲合約、最多花 0.05 ETH」的 session key。
請依序說明:
1. dApp 用 ERC-7715 的 wallet_grantPermissions 送出的請求物件,大致有哪些欄位、各代表什麼?
2. 錢包回傳的委派 context 裡包含什麼?為什麼需要 ERC-7710 的 Delegation Manager?
3. 之後每一筆交易,session key 如何簽名、Delegation Manager 如何驗證與檢查限制?
4. 如果這把 session key 外洩,攻擊者最多能做什麼、做不到什麼?
5. ERC-4337 智慧帳戶與 EIP-7702 的 EOA,在支援 session key 上有何差異?
請盡量對應真實規格用語,並指出我理解上常見的誤區。