草案 ERC：錢包隱私代付者功能

Ethereum Magicians·大約 4 小時前

本提案為 EIP-5792 引入了 privacyPaymaster 功能，讓應用程式能請求由錢包完全控制且具備隱私保護的 Gas 費用支付方式，以防止身分資訊洩露。

ERC PR : 待定

DEMO : 連結

摘要

透過 EIP-5792，應用程式可以透過「能力」（capabilities）向錢包傳達進階的執行偏好。本提案引入了 privacyPaymaster 能力，使應用程式能夠請求相容的錢包使用用戶控制且具備隱私保護功能的付款人（paymaster）來支付 Gas 費用。

應用程式表達意圖；錢包執行隱私保護。

所有 Gas 支付邏輯——包括付款人選擇、Gas 支付準備以及 Gas 支付授權——均在錢包內執行，不會向應用程式洩露用戶身份、內部狀態或付款人的詳細資訊。

動機

在今天，Gas 支付是一種隱含的身份洩漏。

即使當用戶使用隱私保護機制進行價值轉移時，支付 Gas 的地址在各次互動中仍然是公開可見且可關聯的。這建立了一個持久的身份層，而現有的隱私工具尚未完全解決這個問題。

現有的解決方案（如 ERC-7677 的 paymasterService）依賴於應用程式指定的外部服務。這些服務引入了能夠關聯活動、進行審查和產生存續性依賴的受信任第三方，並會洩漏用戶意圖和元數據。

在錢包中配置了隱私保護付款人的用戶，目前沒有標準化的方式向應用程式發出此能力的信號，無法確保錢包自動使用隱私保護的 Gas 支付，也無法防止回退到與身份關聯的 Gas 支付方式。

本提案定義了一種將控制權交還給用戶的能力。錢包決定如何支付 Gas，應用程式僅聲明意圖。正確性不需要外部服務，也不會暴露用戶狀態。與由應用程式選擇 Gas 贊助者的 paymasterService 不同，privacyPaymaster 確保用戶（透過其錢包）是決定如何資助 Gas 的唯一權威。

規範

本文件中的關鍵詞「必須」（MUST）、「不得」（MUST NOT）、「應」（SHOULD）以及「可以」（MAY）應按照 RFC 2119 中的描述進行解釋。

概述

privacyPaymaster 能力完全由錢包實現。錢包維護一個或多個用戶配置的隱私付款人提供者。底層機制——無論是零知識證明、隱身資助（stealth funding）還是任何其他構造——都是實現細節，不會暴露給應用程式。

當 wallet_sendCalls 請求包含 privacyPaymaster 能力時，錢包：

驗證能力物件。
從內部配置中選擇合適的提供者。
在內部進行 Gas 估算。
組裝最終交易並確定所有欄位。
完全在客戶端使用所選提供者準備 Gas 支付。
將產生的 Gas 支付授權納入交易中。
將最終交易呈現給用戶以供批准。
提交執行。

實作者須知： 本規範與底層的帳戶抽象（AA）執行模型無關。以下說明上述抽象術語如何映射到具體模型：

ERC-4337： 交易物件是 UserOperation，Gas 支付授權是 paymasterAndData，提交對象是 Bundler。

EIP-7702： 交易物件是類型為 0x04 的 set-code 交易。當與 ERC-4337 基礎設施一起使用時，適用 paymasterAndData 模型。若不使用，則 Gas 支付授權由委託合約的付款人模組處理，並提交至標準內存池（mempool）。

EIP-8141（草案 — 目標為 Hegotá）： 交易物件是 Frame 交易（類型 0x06）。Gas 支付授權在 VERIFY 幀的 APPROVE 調用中表達。提交直接至內存池，無需 Bundler。

錢包「必須」應用適合其執行模型的構造。上述規範性要求無論使用哪種模型均適用。

應用程式不參與提供者選擇、Gas 估算、Gas 支付準備或付款人配置。

privacyPaymaster 能力

為了符合本規範，支持 privacyPaymaster 能力的錢包：

必須在每個配置了隱私付款人的鏈上，透過 wallet_getCapabilities 發出支持信號。
必須在內部維護用戶配置的提供者。提供者選擇、合約地址和實現細節是錢包內部的事務，不得暴露給 Dapp。
不得在任何能力欄位或響應中向 Dapp 暴露提供者配置、餘額或任何內部用戶狀態。
必須確保 Gas 支付準備過程不會洩漏用戶身份、交易意圖，或 Gas 資助與使用之間的關聯。
必須在提交前將最終交易呈現給用戶批准。
必須拒絕 privacyPaymaster 能力物件為空（即缺少選填欄位）的 wallet_sendCalls 請求，並回傳錯誤代碼 5700。
如果 optional 為 false 且能力無法滿足（例如：未配置提供者、餘額不足、準備失敗），必須拒絕 wallet_sendCalls 請求。
如果 optional 為 false，不得靜默回退到替代的 Gas 支付方式。
當 optional 為 true 且能力無法滿足時，錢包「可以」繼續執行預設的 Gas 支付行為。
當 privacyPaymaster 可以滿足時，必須優先於同一請求中存在的任何 paymasterService 能力。
必須確保 Gas 支付授權不能跨交易重複使用，並防止重放攻擊。
應允許用戶在錢包設置中指定預設提供者，以便在配置了多個提供者時使用。

wallet_getCapabilities 響應規範

能力響應刻意保持極簡。錢包僅指示其是否在各個鏈上支持隱私付款人。所有提供者詳情和實現細節均保留在錢包內部。

type PrivacyPaymasterCapability = {
  supported: boolean;
};

wallet_getCapabilities 響應範例

{
  "0x2105": {
    "privacyPaymaster": {
      "supported": true
    }
  },
  "0xa": {
    "privacyPaymaster": {
      "supported": true
    }
  }
}

響應中缺失的鏈，或 supported: false 的鏈，表示該鏈未配置隱私付款人。

wallet_sendCalls 能力規範

應用程式在 wallet_sendCalls 中包含 privacyPaymaster 能力，以請求隱私保護的 Gas 支付。

type PrivacyPaymasterSendCapability = {
  optional: boolean;
};

應用程式「必須」明確將 optional 設置為 true 或 false。空的能力物件（即缺少 optional 欄位）是無效的，錢包「必須」以錯誤代碼 5700 拒絕，這與 EIP-5792 的錯誤處理一致。

wallet_sendCalls 參數範例

強制執行 — 錢包必須使用隱私付款人否則拒絕：

{
  "version": "2.0.0",
  "chainId": "0x2105",
  "calls": [
    {
      "to": "0xd46e8dd67c5d32be8058bb8eb970870f07244567",
      "data": "0xd09de08a"
    }
  ],
  "capabilities": {
    "privacyPaymaster": {
      "optional": false
    }
  }
}

盡力而為 — 錢包若可用則使用隱私付款人，否則正常進行：

{
  "version": "2.0.0",
  "chainId": "0x2105",
  "calls": [
    {
      "to": "0xd46e8dd67c5d32be8058bb8eb970870f07244567",
      "data": "0xd09de08a"
    }
  ],
  "capabilities": {
    "privacyPaymaster": {
      "optional": true
    }
  }
}

無效 — 空物件，錢包「必須」以錯誤 5700 拒絕：

{
  "version": "2.0.0",
  "chainId": "0x2105",
  "calls": [...],
  "capabilities": {
    "privacyPaymaster": {}
  }
}

原理說明

責任分離

Dapp 聲明意圖。錢包強制執行。提供者實現機制。這種分層最小化了信任假設，並防止了各個層級的身份洩漏。這與 EIP-5792 中推動 wallet_ 命名空間 RPC 的原則相同——將執行權限推向錢包而非應用程式。

為何使用新能力而非擴展 paymasterService

paymasterService 能力（ERC-7677）本質上是由服務器驅動的：Dapp 提供 URL，錢包向外部服務發起 RPC 調用。privacyPaymaster 能力則完全相反——錢包是唯一的行動者。不需要 URL、不需要外部 RPC，也不需要服務器參與即可確保正確性。這些是架構上不相容的模型，因此需要獨立的能力鍵。

為何 Dapp 不指定提供者詳情

暴露提供者配置將允許 Dapp 端進行指紋識別、洩漏實現細節並增加攻擊面。所有此類數據均保留在錢包內部。Dapp 的唯一角色是聲明意圖：強制或選擇性請求隱私保護的 Gas 支付。

為何空的能力物件是無效的

與需要 url 欄位的 paymasterService 不同，privacyPaymaster 不需要來自 Dapp 的任何配置。然而，optional 決定了根本不同的錢包行為——強制拒絕與優雅回退。允許空物件會導致 Dapp 意圖不明確，並存在靜默、未察覺的隱私失效風險。要求明確的 optional 確保 Dapp 對其隱私要求是深思熟慮的，這符合 EIP-5792 能力設計的精神。

為何能力欄位排除內部用戶狀態

錢包內部狀態（如餘額或支出歷史）不得暴露給 Dapp。暴露這些資訊將允許 Dapp 識別用戶指紋、追蹤活動，並可能將鏈上事件與特定用戶關聯——這直接破壞了該能力旨在提供的隱私保證。

為何 optional: false 強制拒絕而非靜默回退

從隱私 Gas 靜默回退到身份關聯 Gas 是一種用戶無法察覺的隱私失效模式。當 optional 為 false 時使拒絕明確化，可確保用戶和應用程式有一個清晰、可審計的信號，表明隱私保證是否得到維護。

為何 privacyPaymaster 優先於 paymasterService

如果 wallet_sendCalls 請求中同時存在這兩種能力，privacyPaymaster 反映了用戶對隱私保護 Gas 的明確配置。允許 paymasterService 覆蓋它將違反用戶意圖，並重新引入用戶配置旨在避免的身份關聯。

安全考量

客戶端準備的完整性

所有 Gas 支付準備「必須」在錢包隔離的執行環境中的客戶端進行。提供者特定的秘密材料「不得」被內容腳本（content scripts）、注入的頁面腳本或 Dapp 控制的執行環境訪問。

防止靜默回退

當 optional 為 false 時，錢包「不得」靜默降級為身份關聯的 Gas 支付。Gas 支付準備階段的任何失敗「必須」作為明確錯誤呈現給 Dapp 和用戶。

提交層考量

提交層在交易納入區塊前會觀察到交易，並可能嘗試關聯它們。錢包「應」考慮提交端點的信任模型，以及在該層進行時間或元數據關聯的可能性。

重放與雙花保護

錢包和付款人提供者「必須」確保 Gas 支付授權不能跨交易重複使用，並防止重放攻擊。

paymasterService 衝突

Dapp 可能在同一個請求中包含 paymasterService 和 privacyPaymaster。錢包在已配置且可滿足的情況下「必須」優先考慮 privacyPaymaster，在這種情況下完全忽略 paymasterService 欄位。

非目標

本提案不涉及：

標準化提供者使用的隱私機制（例如：ZK 證明系統、隱身地址方案）。
定義付款人合約介面或鏈上協議要求。
保證特定的匿名集大小或隱私等級。
規定提交層行為或提交層隱私屬性。
取代或修改用於應用程式贊助 Gas 場景的 paymasterService (ERC-7677)。

向後相容性

此 ERC 引入了一個新的能力鍵 privacyPaymaster。未實現此能力的錢包將不會在 wallet_getCapabilities 響應中包含它。應用程式「應」在 wallet_sendCalls 請求中包含 privacyPaymaster 之前檢查能力支持，或者「應」將其標記為 optional: true 以在不支持的錢包上優雅降級。

在不支持該能力的錢包上包含 optional: false 的 privacyPaymaster 的應用程式，將收到標準的 EIP-5792 不支持能力錯誤 (5700)，這與現有的 EIP-5792 錯誤處理一致。

wallet_getCallsStatus 響應不受此能力影響。Dapp 使用標準的 EIP-5792 wallet_getCallsStatus 流程來追蹤交易狀態。Gas 是透過隱私付款人還是其他機制支付的，不會反映在狀態響應中，這符合 Gas 支付細節屬於錢包內部的原則。

版權

透過 CC0 放棄版權及相關權利。

        1 則貼文 - 1 位參與者

        [閱讀完整主題](https://ethereum-magicians.org/t/draft-erc-wallet-privacy-paymaster-capability/28255)

https://ethereum-magicians.org/t/draft-erc-wallet-privacy-paymaster-capability/28255

你的個人知識庫