ERC-7555: 用于账户发现的单点登录

发现不使用 secp256k1 曲线的签名密钥的账户。

摘要

本提案为应用程序建立了一个标准化的接口和功能，用于发现除现有 EOA 之外的用户账户。特别是发现可能已使用非标准 Ethereum secp256k1 曲线的签名密钥部署或配置的普通账户和智能账户。目标是确保跨应用程序和域的地址检索的统一性。

动机

账户抽象的最新进展显著提高了灵活性，从而实现了诸如多重签名交易、社交恢复、合约/账户白名单、会话密钥等用例。然而，随着灵活性的提高，复杂性也随之增加。复杂性增加的一个领域是账户碎片化——在 EOA 和智能账户层面——这是由于无法正确识别用户的所有现有地址所致。在本 EIP 中，我们提出了一个潜在的解决方案，旨在统一此类账户的发现和处理。

在 ERC-4337 之前，与智能合约账户交互的标准方法需要使用 secp256k1 的密钥对的有效签名。自从 ERC-4337 以来，替代签名选项变得流行起来，例如 passkey、yubikey 或 ios/android 安全 enclave，它们不符合 secp256k1 曲线，并且需要 paymaster 代表用户提交交易。由于提供商在密钥生成过程中实现了额外的逻辑（shamir、mpc、安全 enclave 等），因此替代签名者没有统一的方式让用户在不同的应用程序中生成相同的外部拥有账户地址或智能账户地址。

诸如本地 passkey 或 yubikey 之类的安全硬件设备为每个域生成唯一的密钥对。这意味着对于本地集成身份验证方法（例如那些身份验证方法）的应用程序开发人员来说，永远无法恢复统一的密钥对。实际上，如果我们有以下两种应用程序场景：移动应用程序（App A）和基于 Web 的应用程序（App B）。如果两者都实施了诸如 passkey 之类的解决方案，则 App A 和 App B 将恢复两个不同的密钥。这给用户带来了障碍，他们希望跨服务拥有相同的地址（就像他们使用硬件钱包或其他钱包一样）。

随着 4337 的引入，这个问题被放大了。希望其用户利用 4337（以抽象密钥并通常改善 onboarding 体验）的应用程序将无法检测用户是否已部署现有的智能账户。这将导致开发人员（或提供 onboarding 体验的第三方服务）代表用户在给定地址部署智能账户，该地址的作用域限定为应用程序的域。

无法正确识别用户拥有的现有账户将导致账户碎片化。如前所述，碎片化存在是因为应用程序会将他们识别为新用户，而不是可能已经拥有账户的用户。导致单个用户拥有许多不相关的账户，资产分散在这些账户中，并且无法统一它们。

本标准旨在实现：

1. 应用程序请求用户签名地址的标准方法。
2. 应用程序为替代签名方法提供单点登录 (SSO) 功能的标准方法。
3. 应用程序公开通过其自身服务创建的智能账户的标准方法。

本标准不旨在实现：

1. 用户如何在不同域中签署消息。
2. 提供商如何为用户生成密钥对。
3. 应用程序如何处理用户界面逻辑。

规范

本文档中的关键词“MUST”、“MUST NOT”、“REQUIRED”、“SHALL”、“SHALL NOT”、“SHOULD”、“SHOULD NOT”、“RECOMMENDED”、“NOT RECOMMENDED”、“MAY”和“OPTIONAL”应按照 RFC 2119 和 RFC 8174 中的描述进行解释。

定义

• 智能账户 - 符合 ERC-4337 且具有模块化架构的智能合约账户。
• 域 - 一段文本，用作服务器或网站的标识符（例如：ethereum.org 或 ABCDE12345.com.example.app）。
• EOA - 由单个私钥控制的账户。
• 提供商 - 能够验证用户身份并为用户生成密钥对的第三方服务提供商。

重定向

希望验证用户身份的应用程序必须根据 URI Request Syntax 将用户导航到给定提供商的 URI。应用程序必须实现有效的重定向 URI 以进行回调，以便接收有效的响应。

可用路由

• /auth/: 用于验证用户身份并请求凭据的路由。
• /sendTransaction/: 用于发送交易负载以供用户签名的路由。这是一种更便捷的方法，允许应用程序在一次重定向中同时执行身份验证和插件注册，而无需用户执行两次重定向。

模式

smart_account_address 应该以 CAIP-10 格式返回。

Auth Route

Request Schema

```= swagger parameters: - in: query name: redirect_uri schema: type: string description: 提供商应重定向回的 URI。

• in: query name: chain_id schema: type: string description: 给定网络的 chain_id。 ```

  Response Schema

  ```= swagger parameters:

• in: query name: smart_account_address schema: type: string description: 给定智能账户的链上地址，使用 CAIP-10 格式化 ```

Request Syntax

```= swagger https:///auth/? redirect_uri= &chain_id=

##### Response Syntax
```= swagger
https://<YOUR_REDIRECT_URI>/auth/?
    smart_account_address=<SMART_ACCOUNT_ADDRESS>

sendTransaction Route

Request Schema

```= swagger parameters: - in: query name: redirect_uri schema: type: string description: 提供商应重定向回的 URI。

• in: query name: chain_id schema: type: string description: 给定网络的 chain_id。
• in: query name: transaction schema: type: string description: 需要签名的 RLP 编码的交易 ```

  Response Schema

  ```= swagger parameters:

• in: query name: smart_account_address schema: type: string description: 给定智能账户的链上地址，使用 CAIP-10 格式化
• in: query name: tx_hash schema: type: string description: 交易的哈希值 ```

Request Syntax

```= swagger https:///sendTransaction/? redirect_uri= &chain_id= &transaction=

##### Response Syntax
```= swagger
https://<YOUR_REDIRECT_URI>/sendTransaction/?
    smart_account_address=<SMART_ACCOUNT_ADDRESS>
    &tx_hash=<TX_HASH>

理由

重定向

从当今 Web 中 SSO 的运作方式中汲取灵感。我们实现了类似的重定向模式，包括简单的请求/响应。

应用程序

初始请求

应用程序会将用户重定向到指定的提供商，仅传递回调 url 信息。这是为了确保提供商的网站可以保持无状态，而不依赖于 Web 请求。

来自提供商的响应

当用户被重定向到应用程序时，它可以解析响应以获取签名者地址和关联的智能账户地址。

提供商

当用户导航到提供商网站时，提供商将解析重定向 url 并验证用户身份。身份验证方法无关紧要，这样它就可以生成有效的公共地址，并恢复任何可能通过提供商部署的智能账户。

向后兼容性

未发现向后兼容性问题。

参考实现

使用 location.replace() 与 location.href 由应用程序决定他们希望如何处理体验。

示例 URI 请求

https://eth-sso.ethereum.org/auth?redirect_uri=http://myapp.com/eth-sso/callback/&chain_id=1

示例响应

http://myapp.com/callback/?smart_account_address=0xb...c

应用程序逻辑

// https://myapp.com
// 用户触发的身份验证函数
function auth() {
    window.location.replace("https://eth-sso.ethereum.org/auth?redirect_uri=myapp.com&chain_id=1/eth-sso/callback/");
};

// 应用程序级路由逻辑（通用路由器）
route("/eth-sso/callback/", function() {
    let params = (new URL(document.location)).searchParams;
    let smartAccountAddress = params.get("smart_account_address");
});

提供商逻辑

// eg: https://eth-sso.ethereum.org/auth
route("/eth-sso/callback/", function("/auth") {
    let params = (new URL(document.location)).searchParams;
    let redirectUrl = params.get("redirect_uri");
    // Authenticate the user (eg: with passkeys)
    // 验证用户身份（例如：使用 passkey）
    let address = "...";
    // Get smart account if available
    // 获取可用的智能账户
    let smartAccountAddress = getSmartAccount(address);
    window.location.replace(`http://${redirectUrl}/?smart_account_address=${smartAccountAddress}`);
});

安全注意事项

• 是否担心用户可以欺骗另一个人的地址，这可能是恶意的？例如，绕过提供商，并使用选择的地址手动调用 redirect_url。一种解决方法是让用户实际签署质询消息，可能利用 SIWE。

重定向 URI 中缺少通配符支持旨在保护用户免受嵌套的开放重定向漏洞的侵害。允许通配符可能会使攻击者能够将用户重定向到受支持通配符下的不同页面，从而造成开放重定向的漏洞。

版权

版权及相关权利通过 CC0 放弃。

Citation

Please cite this document as:

Alexander Müller (@alexmmueller), Gregory Markou (@GregTheGreek), Willem Olding (@Wollum), Belma Gutlic (@morrigan), Marin Petrunić (@mpetrunic), Pedro Gomes (@pedrouid), "ERC-7555: 用于账户发现的单点登录 [DRAFT]," Ethereum Improvement Proposals, no. 7555, November 2023. [Online serial]. Available: https://eips.ethereum.org/EIPS/eip-7555.