ERC-4430: 描述性交易

一种让合约提供交易副作用的人类可读描述的技术。

摘要

使用合约方法提供虚拟函数，可以在生成机器可读字节码的同时生成人类可读的描述，允许用户在 UI 中同意人类可读的组件，而机器可以在接受后执行字节码。

动机

当使用以太坊钱包（例如 MetaMask、Clef、硬件钱包）时，用户必须先接受交易才能提交（或者用户可以拒绝）。

由于以太坊交易的复杂性，钱包在提供对用户正在批准的交易的影响的洞察力方面非常有限；除了对常见交易（例如 ERC20 转账）的特殊情况支持外，这通常相当于要求用户签署一个不透明的二进制数据 blob。

本 EIP 提出了一种方法，供 dapp 开发者通过为钱包提供一种生成关于合约声称将要发生的更好的描述的方式，从而实现更舒适的用户体验。

它不解决希望撒谎的恶意合约，它只解决想要改善用户生活的诚实合约。我们认为这是一个合理的安全模型，因为交易描述可以与合约代码同时进行审计，允许审计员和代码审查员检查交易描述是否准确，作为其审查的一部分。

规范

description（一个字符串）和匹配的 execcode（字节码）通过在一个合约上评估该方法同时生成：

function eipXXXDescribe(bytes inputs, bytes32 reserved) view returns (string description, bytes execcode)

人类可读的 description 可以在任何支持用户交互以进行批准的客户端中显示，而 execcode 应该是包含在与合约的交易中以执行该操作的数据。

该方法必须在静态上下文中可执行，（即任何副作用，例如 logX、sstore 等），包括通过间接调用可能会被忽略。

在评估期间，ADDRESS（即 to）、CALLER（即 from）、VALUE 和 GASPRICE 必须与被描述交易的值相同，以便生成描述的代码可以依赖于它们。

当执行字节码时，应尽最大努力确保 BLOCKHASH、NUMBER、TIMESTAMP 和 DIFFICULTY 与 "latest" 区块匹配。COINBASE 应该是零地址。

该方法可能会 revert，在这种情况下，必须中止签名。

理由

元描述

已经有很多尝试解决这个问题，其中许多尝试直接检查编码的交易数据或消息数据。

在许多情况下，有意义的描述所需的信息不存在于最终编码的交易数据或消息数据中。

相反，此 EIP 使用数据的间接描述。

例如，ENS 的 commit(bytes32) 方法将承诺哈希放在链上。哈希包含盲化的名称和地址；由于名称是盲化的，编码的数据（即哈希）不再包含原始值，并且不足以访问包含在描述中的必要值。

通过间接描述承诺（使用完整的原始信息：NAME、ADDRESS 和 SECRET），可以计算出有意义的描述（例如“为 ADDRESS (with SECRET) 提交到 NAME”），并且可以计算出匹配的数据（即 commit(hash(name, owner, secret))）。

这种盲化数据的技术将在 L2 解决方案中变得更加流行，L2 解决方案使用盲化不一定是为了隐私，而是为了压缩。

纠缠合约地址

为了防止签名数据跨合约使用，合约地址通过 to 字段隐式地纠缠到交易中。

替代方案

• NatSpec 及其公司是一类更复杂的语言，试图直接描述编码的数据。由于语言的复杂性，它们通常最终变得非常大，需要整个运行时环境，具有充足的处理能力和内存，以及额外的沙箱来降低安全风险。其中一个目标是将复杂性降低到可以在硬件钱包和其他简单钱包上执行的东西。这些也直接描述数据，这在许多情况下（例如盲化数据）根本无法充分描述数据

• 自定义语言；由于以太坊交易的复杂性，任何使用的语言都需要大量的表达能力和重新发明轮子。EVM 已经存在（它可能不是理想的），但它就在那里，可以处理所有必要的事情。

• 格式字符串（例如，Trustless Signing UI Protocol；格式字符串只能在规则语言类上运行，在许多情况下，这不足以描述以太坊交易。这在早期尝试解决此问题时经常出现问题。

• signTypedData EIP-712 与此 EIP 旨在解决的问题有很多相似之处

向后兼容性

这不会影响向后兼容性。

参考实现

我将通过地址和链 ID 添加已部署的示例。

安全考虑

转义文本

钱包在显示合约提供的文本时必须小心，并且必须采取适当的措施来清理它，例如，请务必考虑：

• 可以嵌入 HTML 以尝试欺骗基于 Web 的钱包使用 script 标签执行代码（可能将任何私钥上传到服务器）
• 一般来说，在渲染 HTML 时必须格外小心；考虑 ENS 名称 <span style="display:none">not-</span>ricmoo.eth 或  ricmoo.eth，如果渲染时不小心，它会显示为 ricmoo.eth，但事实并非如此
• 可能包含需要转义的其他标记，例如引号 (")、格式 (\n (换行符)、\f (换页符)、\t (制表符)、任何许多非标准空格)、反斜杠 (\)
• UTF-8 过去存在错误，可能允许任意代码执行和崩溃渲染器；考虑对常见平面之外或平面内常见子集的代码点使用 UTF-8 替换字符（或某些东西）
• 同形字攻击
• 从右到左的标记可能会影响渲染
• 许多其他事情，取决于您的环境

版权

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

Citation

Please cite this document as:

Richard Moore (@ricmoo), Nick Johnson (@arachnid), "ERC-4430: 描述性交易 [DRAFT]," Ethereum Improvement Proposals, no. 4430, November 2021. [Online serial]. Available: https://eips.ethereum.org/EIPS/eip-4430.