背景
交易签名一直以来都是安全的兵家必争之地，从直接签名转账，到签名授权，再到签名 permit2 内容，以及 ERC-3009 的 authorization 内容，钓鱼黑客总能够在不同的签名场景中寻找到薄弱之处让用户签下那笔"不明不白"的交易。而这个"防御"的任务，通常是依赖于钱包的签名解析功能，将用户签名的十六进制内容根据合约的函数参数进行复原，告诉用户你签的内容到底是什么。
但是这也会存在一个问题的呀：合约的实现层出不穷，灵活多变，验签的内容和方法也在不断更新，依赖钱包解析被动地去覆盖各种签名场景，这本身就存在一定的滞后性（这还是在钱包团队积极跟进的前提下）。
所以，为了解决这个签名难的问题，让用户签得明白、签得安全，ERC-7730 应运而生。
概括性介绍
ERC-7730 的目标是通过引入一套标准化的 JSON 描述符格式，解决以太坊生态中长期存在的"盲签"问题：用户在签署智能合约交易或结构化消息时，面对钱包中显示的十六进制数据或晦涩的函数调用无法理解真实交易意图，从而极易遭受钓鱼攻击和资产损失。
而 ERC-7730 的实现依赖于合约项目方或社区贡献者提供能够真实反映签名意图的 JSON 描述文件，这样钱包就将函数签名和参数映射为人类可读的字段标签、格式化数值以及意图描述，实现签名内容与用户预期一致的目标。
详细介绍
下面以最熟知的 ERC20 transfer 函数作为例子，下面是它对应的 JSON 解析规则内容。
json
{
"$schema": "https://eips.ethereum.org/assets/eip-7730/erc7730-v2.schema.json",
"context": {
"$id": "Example ERC-20",
"contract" : {
"deployments": [
{
"chainId": 1,
"address": "0xdAC17F958D2ee523a2206206994597C13D831ec7"
},
{
"chainId": 137,
"address": "0xc2132D05D31c914a87C6611C10748AEb04B58e8F"
},
{
"chainId": 42161,
"address": "0xFd086bC7CD5C481DCC9C85ebE478A1C0b69FCbb9"
}
]
}
},
"metadata": {
"owner": "Example",
"contractName": "Example Token",
"info": {
"url": "https://example.io/",
"deploymentDate": "2017-11-28T12:41:21Z"
}
},
"display": {
"formats": {
"transfer(address to,uint256 value)": {
"intent": "Send",
"interpolatedIntent": "Send {value} to {to}",
"fields": [
{
"path": "value",
"label": "Amount",
"format": "tokenAmount",
"params": {
"tokenPath": "@.to"
}
},
{
"path": "to",
"label": "To",
"format": "addressName"
}
]
}
}
}
}主体内容
其中 $schema 对应的是引用的解析规则版本号。
剩余部分为内容主体，包括 context，metadata 和 display 三种类型。
| 章节 | 作用 |
|---|---|
context |
绑定约束 ：定义该解析文件适用的合约范围： 1. 合约交易：通过 chainId + address 定位适用的合约； 2. EIP-712 消息：通过 domain 或 deployments 绑定。钱包在根据解析文件对签名内容进行解析之前，必须先验证约束是否满足。 |
metadata |
元信息 ：定义合约/项目方名称、官网、部署日期等展示信息。这部分的内容可以被 display 章节引用。 |
display |
格式化指令 ：核心解析逻辑： 1. definitions：可复用的字段格式定义 2. formats：针对每个函数或 EIP-712 消息类型的具体解析规则 |
引用符号
为了准确地定义每个字段的数据属性与来源，ERC-7730 还定义了三种引用符号
-
$：文件内容引用该符号用来引用 ERC-7730 文件中的值，比如案例中的
$schema，除此以外，还可以用来引用metadata、definitions等内容。使用案例：
jsx$.metadata.enums.interestRateMode $.display.definitions.minReceiveAmount -
@：交易参数引用该符号用来引用交易或消息的参数。
使用案例：
jsx@.to @.value @.chainId -
#：结构化参数引用该符号用来引用数据结构中的内容，范围包括函数参数中的结构化数据，以及 EIP-712 字段中的内容。
使用案例：
jsx#.params.amountIn #.data.path.[0].path.[-1].to
案例展示
之前已经通过 ERC20 transfer 函数作为案例介绍了解析文件的设计与构成，接下来提供一些在不同场景的案例作为参考。
-
代币转账
json{ "intent": "Send", "interpolatedIntent": "Send {value} to {to}", "fields": [ {"path": "to", "format": "addressName"}, {"path": "value", "format": "tokenAmount", "params": {"tokenPath": "@.to"}} ] }输出内容："Send 100 USDT to cyberdrk.eth"
to字段没有params，是因为addressName格式的参数全部是可选的 。而value字段使用tokenAmount，它必须 知道代币合约地址才能正确格式化（获取小数位decimals和代币符号ticker）。如果不提供tokenPath或token，钱包无法知道这是哪种代币，只能回退到显示原始数值并警告 "Unknown token"。 -
代币兑换
json{ "intent": "Swap", "interpolatedIntent": "Swap {amountIn} for at least {amountOutMinimum}", "fields": [ {"path": "amountIn", "format": "tokenAmount", "params": {"tokenPath": "tokenIn"}}, {"path": "amountOutMinimum", "format": "tokenAmount", "params": {"tokenPath": "tokenOut"}} ] }输出内容："Swap 1000 USDC for at least 0.25 WETH"
同样地，
amountIn和amountOutMinimum的参数格式需要借助代币来进行格式化。 -
Token 加密传输
json{ "intent": "Send", "interpolatedIntent": "Send {value} to {to}", "fields": [ {"path": "to", "format": "addressName"}, {"path": "value", "format": "tokenAmount", "params": {"tokenPath": "@.to"}, "encryption": { "scheme": "fhevm", "plaintextType": "uint64", "fallbackLabel": "[Encrypted Amount]" }} ] }- 解密可用时："Send 100 USDT to cyberdrk.eth"
- 解密不可用时："Send [Encrypted Amount] to cyberdrk.eth"
在隐私代币或保密转账场景中（如基于 FHE 的代币标准），只有持有解密密钥的钱包/用户，才能知道真实的转账金额。
scheme代表加密方案，plaintextType代表解密后的原始数据类型，而fallbackLabel则是当钱包无法解密时显示给用户的占位文本。
后记
除了上述提到的基本概念，ERC-7730 提案中还对解析文件中的概念进行了非常详尽的定义与解读。本篇文章主要对这个提案进行较为初步的介绍，对这方面感兴趣想要深入研究的读者可以直接研究他们的提案：https://eips.ethereum.org/EIPS/eip-7730