我的知識庫

區塊鏈 · 2026-08-23

閱讀時間約 7 分鐘

昨天談 Paymaster 把 gas 從使用者身上移開,今天把另一半體驗補上:讓使用者根本不必再管私鑰助記詞,改用手機生物辨識的 passkey 直接簽章。這條路的技術樞紐是 secp256r1(P-256)這條曲線,以及它在鏈上驗章的成本,而 2026 年最關鍵的變化,就是這件事終於要上以太坊主網。

📖 學

以太坊帳戶原生用的是 secp256k1 曲線,而 Apple Secure Enclave、Android Keystore、FIDO2/WebAuthn 這些裝置端安全硬體用的是 secp256r1(業界俗稱 P-256)。這條鴻溝以前很麻煩:passkey 產生的簽章是 P-256,但以太坊虛擬機沒有內建 P-256 驗證能力,只能用純 Solidity 寫的驗章合約去硬算橢圓曲線運算,一次驗證動輒要燒掉約 30 萬 gas。對一個希望「按個指紋就送出交易」的智慧帳戶錢包來說,這個成本高到近乎不切實際。

RIP-7212 就是為了填這道鴻溝而生。它在固定位址 0x100 放一個 secp256r1 的預編譯合約(precompile),把 P-256 驗章從約 30 萬 gas 壓到大約 3,450 gas,幾乎兩個數量級的降幅。這個提案先在多條 Layer 2 落地(Polygon、以及採用相同呼叫格式的各家 rollup),讓「passkey 錢包」在 L2 上先跑了起來。也因為 L2 先行,Safe、Coinbase Smart Wallet 這類智慧帳戶,才有底氣把 passkey 當成預設簽章方式。

真正的里程碑在主網。原本編號 EIP-7212 的提案,以 EIP-7951 的身分被排進 Fusaka(Fulu-Osaka)升級,把同一顆 P-256 驗章預編譯正式帶上以太坊 L1,順手修掉早期實作的一些邊界案例。主網版本的定價落在約 6,900 gas,相對於純 Solidity 實作等於約五十倍的成本削減。這代表 passkey 簽章不再是「L2 專屬的省錢招」,而是整條以太坊生態都能用的原生能力,錢包終於能直接接上手機的安全隔離區、硬體安全模組(HSM)與 FIDO2 裝置。

在應用層,智慧帳戶怎麼「認得」這顆 P-256 簽章,靠的是 ERC-1271。以 Safe 的 passkey 模組為例:SafeWebAuthnSignerSingleton 實作 ERC-1271 介面負責驗章,SafeWebAuthnSignerFactory 則用使用者的公鑰座標與 verifier 資訊,部署出一個 SafeWebAuthnSignerProxy 當作簽章人。值得注意的設計細節是,這些合約刻意把所有設定寫進合約 code 而不是帳戶 storage,驗章過程完全不讀取 storage,這樣才符合 ERC-4337 對 UserOperation 驗證階段的儲存存取限制。

還有一層務實的相容性安排:這些 passkey 合約在有預編譯的鏈上直接呼叫 0x100,在還沒有預編譯的鏈上則退回(fallback)用 Solidity 驗章合約,例如 Daimo 的 p256-verifier 或 Fresh Crypto Lib(FCL)的 P-256 實作。同一套合約碼跨鏈都能跑,只是成本隨底層有沒有預編譯而不同。對開發者而言,這意味著你今天就能寫 passkey 錢包,不必等每條鏈都升級到位;等預編譯上線,成本自動降下來。

🧠 記

  • secp256r1(P-256)是裝置端安全硬體與 WebAuthn/passkey 用的曲線,和以太坊原生的 secp256k1 不同,這是「用指紋簽以太坊交易」的核心障礙。
  • RIP-7212 在 L2 提供 P-256 驗章預編譯(位址 0x100),把成本從約 30 萬 gas 降到約 3,450 gas。
  • EIP-7951(前身 EIP-7212)把同一顆預編譯排進 Fusaka 升級帶上主網 L1,定價約 6,900 gas,約五十倍成本削減。
  • 智慧帳戶透過 ERC-1271 的 isValidSignature 介面來驗證 passkey 的 P-256 簽章。
  • Safe 的 passkey 模組把設定寫進合約 code、驗章不讀 storage,以符合 ERC-4337 的儲存限制。
  • 沒有預編譯的鏈可退回 Daimo p256-verifier 或 FCL 的純 Solidity 實作,同一套合約跨鏈相容。

✍️ 實踐

打開 Safe 的 passkeys 文件(下方連結),對照 SafeWebAuthnSignerSingleton 與 SafeWebAuthnSignerFactory 的關係畫一張三格小圖:使用者的 passkey 公鑰座標 → Factory 部署 Proxy → Proxy 透過 ERC-1271 驗章。接著在瀏覽器 devtools 的 Console 執行一次 navigator.credentials.create({ publicKey: { ... } }) 的最小範例(可先用 MDN 的 WebAuthn 範本),觀察回傳物件裡的 clientDataJSON 與 authenticatorData 欄位,理解 passkey 簽章不是單純簽 hash,而是簽「authenticatorData + clientDataJSON 的雜湊」——這正是鏈上驗章合約必須重組的資料。全程約 15 分鐘,重點是把「裝置產生的簽章格式」和「合約要驗的內容」對起來。

🔗 延伸學習

💬 問 AI

我想用 passkey(WebAuthn / secp256r1)當作 ERC-4337 智慧帳戶的簽章方式。請幫我:
1. 解釋 P-256 簽章從瀏覽器 WebAuthn API 產生後,鏈上合約要如何重組 authenticatorData 與 clientDataJSON 才能驗章;
2. 比較「有 RIP-7212 / EIP-7951 預編譯」與「用 Daimo p256-verifier fallback」在 gas 成本與相容性上的差異;
3. 說明為什麼驗章合約要避免讀取 storage 才符合 ERC-4337 的驗證階段限制,並給一個 ERC-1271 isValidSignature 的最小實作骨架。

反向連結