Nethereum中EIP-712复杂类型编码问题的分析与解决

问题背景

在使用Nethereum进行EIP-712类型数据签名时，开发者遇到了一个关于复杂类型编码的问题。具体表现为当结构体类型中包含嵌套的相同类型时，编码结果会出现重复的类型定义，导致签名验证失败。

问题现象

开发者定义了一个复杂的SessionSpec结构体，其中包含多个嵌套结构体：

• CallSpec（包含UsageLimit和Constraint数组）
• TransferSpec（包含UsageLimit）
• Constraint（又包含UsageLimit）

当使用Eip712TypedDataEncoder进行类型编码时，生成的类型字符串中UsageLimit类型出现了三次重复定义，而根据EIP-712规范，每种类型应该只出现一次。

技术分析

EIP-712规范明确规定：

1. 结构体类型编码格式为：类型名(成员1类型 成员1名,成员2类型 成员2名,...)
2. 如果结构体引用了其他结构体类型，需要收集所有被引用的结构体类型
3. 这些被引用的结构体类型需要按名称排序后附加到编码中
4. 每种类型应该只出现一次

Nethereum原有的实现中，在递归处理嵌套类型时，虽然对当前层级的类型进行了去重，但没有对最终返回的所有类型进行全局去重，导致当多个结构体引用同一类型时，该类型会被多次添加到结果中。

解决方案

核心修复方案是在递归处理完成后，对最终返回的所有类型进行一次全局去重。具体实现要点：

1. 保持原有的递归处理逻辑不变
2. 在返回结果前添加.Distinct()操作
3. 确保去重是基于类型名称进行的

修复后的代码确保了：

• 每种类型只会在最终编码中出现一次
• 仍然保持了所有必要的类型依赖关系
• 符合EIP-712规范的要求

影响与验证

该修复：

1. 解决了签名验证失败的问题
2. 保持了与主流区块链SDK（如viem、ethers等）的兼容性
3. 不影响原有简单用例的正常工作
4. 正确处理了复杂嵌套结构体的编码需求

最佳实践建议

在使用Nethereum处理EIP-712复杂类型签名时：

1. 确保所有嵌套结构体都正确定义了StructAttribute
2. 检查生成的类型编码是否符合预期
3. 对于复杂的嵌套结构，建议先单独测试类型编码部分
4. 保持Nethereum库的及时更新，以获取最新的修复和改进

该问题的解决展示了Nethereum团队对规范细节的严谨态度和对开发者问题的积极响应，为分布式应用开发提供了更可靠的签名功能支持。