ERC-7856: 链特定的支付请求
用于链特定的支付请求的 URI 方案。
| Authors | Jack Chuma (@jackchuma) |
|---|---|
| Created | 2025-01-01 |
| Discussion Link | https://ethereum-magicians.org/t/add-erc-chain-specific-payment-requests/22379 |
摘要
本 EIP 提出了一种标准化的 URI 方案，用于链特定的支付请求，使用户能够以“在链 Z 上发送我 X 个 Y 类型的 tokens”的形式指定交易。URI 格式包括必要的组件，例如收款人的区块链账户、tokens 的数量、token 合约地址以及可选的成功和错误回调 URL。该标准旨在消除多链支付请求中的歧义，确保不同区块链网络中点对点交易以及供应商或 dApp 请求的清晰度和准确性。
动机
Ethereum 网络不断扩展到多链生态系统，这给支付请求的执行带来了复杂性。用户和开发者目前面临着支付请求应该在哪个链上完成的不明确性，尤其是在多个链上存在类似资产时。这种模糊性使点对点交易以及供应商或 dApp 请求复杂化，导致效率低下和更高的出错可能性。该标准将确保支付请求被清晰理解并正确执行，无论在哪个链上，从而显著增强多链环境中的用户体验。
规范
本文件中关键词 “MUST”（必须），”MUST NOT”（禁止），”REQUIRED”（需要），”SHALL”（应该），”SHALL NOT”（不应该），”SHOULD”（应当），”SHOULD NOT”（不应当），”RECOMMENDED”（推荐），”NOT RECOMMENDED”（不推荐），”MAY”（可以）和 “OPTIONAL”（可选）按照 RFC 2119 和 RFC 8174 中的描述进行解释。
支付请求 URI 的格式为：
cspr://<recipient>/<amount>/<token-address>?on-success=<success-callback-url>&on-error=<error-callback-url>
cspr://- [REQUIRED] “Chain-Specific Payment Request”（链特定支付请求）的缩写。表示基于区块链的支付请求。<recipient>- [REQUIRED] 请求付款的区块链账户（表示为 CAIP-10 账户标识符）。<amount>- [REQUIRED] 要发送的 token 数量，指定为整数或小数。<token-address>- [REQUIRED] 要发送的 ERC-20 token 的合约地址（表示为 base64 编码的字符串）。特殊值native可用于请求指定链的本地货币（如果该链支持本地货币）。<success-callback-url>- [OPTIONAL] 交易确认后将用户重定向到的 URL。<error-callback-url>- [OPTIONAL] 交易失败后将用户重定向到的 URL。
示例
在 Base Mainnet 上向地址 0x1111111111111111111111111111111111111111 请求 1 个 eth，并指定成功回调 URL：
cspr://eip155:8453:0x1111111111111111111111111111111111111111/1/native?on-success=https://example.com
在 Bitcoin mainnet 上请求 0.5 个 BTC：
cspr://bip122:000000000019d6689c085ae165831e93:128Lkh3S7CkDTBZ8W7BbpsN3YYizJMp8p6/0.5/native
在 Ethereum Mainnet 上请求 100 个 USDC：
cspr://eip155:1:0xab16a96D359eC26a11e2C2b3d8f8B8942d5Bfcdb/100/0xA0b86991c6218b36c1d19D4a2e9Eb0cE3606eB48
错误处理
解析这些 URI 的钱包或应用程序必须验证收款人账户的格式。如果 URI 的任何组件不符合指定的请求或格式，则应向用户显示错误。
理由
这种基于区块链的支付请求的 URI 标准设计，解决了在多个 Ethereum 链（包括主网和各种 Layer 2 网络）上发起交易时，需要一种清晰且明确的方法的需求。URI 结构的每个组件的基本原理如下：
cspr://前缀： 此前缀明确地将 URI 标识为基于区块链的支付请求，确保系统识别并正确处理这些 URI。它遵循其他特定协议的 URI 方案的先例，例如电子邮件的mailto://和网络链接的http://。- 收款人： 收款人使用 CAIP-10 账户标识符指定，CAIP-10 是一种表示区块链地址的标准化格式。使用 CAIP-10，您可以轻松识别收款人的区块链网络和相应的地址，而无需考虑底层的地址约定。
- 数额规范： 在 URI 中指定数额可以明确交易的意图，允许用户在发送之前验证数额。这有助于防止错误和欺诈。数额被指定为整数或小数，以保证清晰、精确和易于验证。
- Token 地址： 需要 token 地址可确保 URI 指定要发送的确切 token，从而消除歧义。它支持 ERC-20 tokens 和链的本地货币（如果支持）。
- 回调 URL： 包含回调 URL 允许在确认或失败交易后重定向到指定的 URL，通过提供无缝返回应用程序或网站来增强用户体验。
此 URI 标准中的 token 地址表示为 base64 编码的字符串，以同时支持 EVM 和非 EVM 链，因为所有当前的地址方案都是 base64 的子集。
考虑的替代设计：
- 包含交易参数：考虑过添加额外的交易参数（例如，gas 限制，gas 价格），但建议由用户的钱包应用程序处理，以使 URI 方案专注于支付请求，并避免用户被技术细节淹没。
- Token 参数可选性：最初，token 参数被认为是可选的，省略它意味着指定链的本地货币。但是，并非所有链都支持本地货币，因此需要显式 token 规范可以提高清晰度并减少潜在的错误。
ethereum://前缀：最初被提议作为 Ethereum 生态系统的标准化 URI 方案，ethereum://前缀旨在提供一致的标识符。但是，为了适应非 EVM 链，使用不限于 Ethereum 的更通用的标识符更为实际。- ENS 支持：我们最初考虑添加可选的 ENS 支持，但确定这是不必要的。由于 URI 方案不是面向用户的，因此包含 ENS 会增加不必要的复杂性，而不会提供实际的好处。此外，类似于地址的 ENS 名称会带来潜在的安全风险。相反，遵守 CAIP-10 标准以获取链特定的帐户标识符是更实际的选择。
相关工作
ERC-681 是一个相关标准，它为指定 Ethereum 中的 token 转移定义了一个类似的 URI 方案。但是，ERC-681 包含用于指定交易详细信息的其他参数，这些参数被认为对于本标准范围而言是不必要的。此 EIP 的重点是支付请求规范的简单性和清晰性，并期望交易详细信息由用户的钱包应用程序处理。
ERC-831 是另一个相关标准，它指定了 Ethereum 的 URI 格式。此 EIP 旨在与所有区块链兼容，而不是专门关注 Ethereum 及其 rollups。主要区别在于 URI 标识符的选择。
向后兼容性
由于 URI 前缀的独特选择，此 EIP 与 ERC-681 或 ERC-831 不向后兼容。
安全考虑
由于与 ERC-681 有许多相似之处，因此所有相同的安全考虑因素均适用，并且已在下面进行了总结。
URL的安全性及可信度非常重要，尤其是因为它们可以触发不可逆的交易。更改接收者的地址或交易金额可能会为攻击者带来巨大的经济利益。因此，用户应仅信任来自经过验证的安全来源的URL。
为了确保交易金额与用户的意图一致，应由用户清晰且易于验证，包括其大小。对于 ERC-20 token 交易，如果付款方的客户端可以访问区块链或另一个可靠的 token 合约详细信息来源，则该界面应以 token 的指定单位显示该金额。否则，它应显示 URL 中声明的金额，并可能警告用户该单位的不确定性。建议使用带有与 token 的标称单位（例如，以太币为 18）匹配的指数的科学计数法，以帮助用户验证。
严格验证回调 URL，以防止重定向到钓鱼网站。钱包开发人员应遵循浏览器安全最佳实践进行 URL 验证。
钱包应用程序必须识别缺少本机货币支持的链，并且应阻止在这些链上进行的本机货币支付请求。
版权
版权和相关权利已通过 CC0 放弃。
Citation
Please cite this document as:
Jack Chuma (@jackchuma), "ERC-7856: 链特定的支付请求 [DRAFT]," Ethereum Improvement Proposals, no. 7856, January 2025. [Online serial]. Available: https://eips.ethereum.org/EIPS/eip-7856.