但是这也会存在一个问题的呀合约的实现层出不穷灵活多变验签的内容和方法也在不断更新依赖钱包解析被动地去覆盖各种签名场景这本身就存在一定的滞后性这还是在钱包团队积极跟进的前提下。所以为了解决这个签名难的问题让用户签得明白、签得安全ERC-7730 应运而生。概括性介绍ERC-7730 的目标是通过引入一套标准化的 JSON 描述符格式解决以太坊生态中长期存在的盲签问题用户在签署智能合约交易或结构化消息时面对钱包中显示的十六进制数据或晦涩的函数调用无法理解真实交易意图从而极易遭受钓鱼攻击和资产损失。而 ERC-7730 的实现依赖于合约项目方或社区贡献者提供能够真实反映签名意图的 JSON 描述文件这样钱包就将函数签名和参数映射为人类可读的字段标签、格式化数值以及意图描述实现签名内容与用户预期一致的目标。详细介绍下面以最熟知的 ERC20 transfer 函数作为例子下面是它对应的 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对应的是引用的解析规则版本号。剩余部分为内容主体包括contextmetadata和display三种类型。章节作用context绑定约束定义该解析文件适用的合约范围 1. 合约交易通过chainIdaddress定位适用的合约 2. EIP-712 消息通过domain或deployments绑定。钱包在根据解析文件对签名内容进行解析之前必须先验证约束是否满足。metadata元信息定义合约/项目方名称、官网、部署日期等展示信息。这部分的内容可以被display章节引用。display格式化指令核心解析逻辑 1.definitions可复用的字段格式定义 2.formats针对每个函数或 EIP-712 消息类型的具体解析规则引用符号为了准确地定义每个字段的数据属性与来源ERC-7730 还定义了三种引用符号$文件内容引用该符号用来引用 ERC-7730 文件中的值比如案例中的$schema除此以外还可以用来引用metadata、definitions等内容。使用案例$.metadata.enums.interestRateMode $.display.definitions.minReceiveAmount交易参数引用该符号用来引用交易或消息的参数。使用案例.to .value .chainId#结构化参数引用该符号用来引用数据结构中的内容范围包括函数参数中的结构化数据以及 EIP-712 字段中的内容。使用案例#.params.amountIn #.data.path.[0].path.[-1].to案例展示之前已经通过 ERC20 transfer 函数作为案例介绍了解析文件的设计与构成接下来提供一些在不同场景的案例作为参考。代币转账{ 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。代币兑换{ 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 加密传输{ 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则是当钱包无法解密时显示给用户的占位文本。