EIP-7713: EIP-712 消息的 Box 类型
EIP-712 消息包含任意类型参数的机制
Authors | Francisco Giordano (@frangio) |
---|---|
Created | 2024-05-23 |
Discussion Link | https://ethereum-magicians.org/t/eip-7713-box-types-for-eip-712-messages/20092 |
Requires | EIP-712 |
Table of Contents
摘要
本 EIP 定义了一个新的类型 box
,用于 EIP-712 消息中。一个 box
值是一个任意结构体类型的值,其底层类型被封装并对外部结构体隐藏,但对钱包来说是透明的并且可以进行类型检查,因此用户可以在签名之前完全检查它。验证合约可以与 box
值的底层类型无关,但此类型不会被擦除,并且如果需要,可以在链上进行验证。
动机
EIP-712 签名已成为用户在链下表达和授权意图的广泛使用的原语。广泛的应用程序能够定义参数化的消息,供用户通过通用接口在其钱包中签名,该接口清楚地显示授权的类型、参数和域。这对硬件钱包作为最后一道防线至关重要。
EIP-712 的通用性是其成功的关键,但此外,钱包能够为特定类型的消息开发专用接口和功能,因为它们变得越来越广泛使用。例如,ERC-2612 Permits 是一种众所周知的 EIP-712 消息,钱包以特殊方式向用户显示该消息,清楚地显示了签名的已知含义和风险。
专用接口提高了用户的可用性和安全性,但依赖于标准化的消息类型,例如 Permits。本 EIP 关注于标准化消息的能力,这些消息包含任意类型的参数。
最近的一个例子可以在 ERC-7683 中找到,它定义了一个具有以下成员的结构体:
/// @dev 任意特定于实现的数据
/// 可用于定义 tokens、金额、目标链、费用、结算参数
/// 或任何其他 order-type 特定的信息
bytes orderData;
使用 bytes
类型定义此参数使消息能够包含任意类型的数据,并且足以将签名绑定到特定于实现的数据,但这相当于类型擦除。因此,用户将在钱包的签名界面中看到一个十六进制格式的不透明字节串。这否定了使用 EIP-712 签名的好处,因为参数的真实内容对于钱包的通用接口是不可见的。
另一个例子可以在最近为使 ERC-1271 签名安全地防止重放的努力中找到。在不使消息内容对签名者不透明的情况下实现此目的,需要将应用程序的 EIP-712 消息嵌入到外部消息中,该消息将其绑定到特定帐户。外部消息的类型取决于内部消息的类型,并且为了使智能合约帐户在链上进行验证时可以重现该类型,需要一种效率低下的方案来将内部消息的字符串编码类型作为签名的一部分进行通信。
这两种用例都将受益于定义任意类型的 EIP-712 结构体参数的能力,这样验证合约可以与消息中参数值的类型无关,同时钱包保留向用户透明地显示它以供检查的能力。
规范
本文档中的关键词“必须”,“不得”,“必需”,“应”,“不应”,“应该”,“不应该”,“推荐”,“不推荐”,“可以”和“可选”应按照 RFC 2119 和 RFC 8174 中的描述进行解释。
EIP-712 扩展如下:
类型化的结构化数据
一个结构体类型可以通过声明为 box
类型来包含一个 boxed member。例如:
struct Envelope {
address account;
box contents;
}
一个 boxed member 有一个底层的 unboxed type,它是一个任意结构体类型,并且在每个消息中可能不同。
encodeType
一个 boxed member 被编码为 "box " || name
。例如,上面的 Envelope
结构体被编码为 Envelope(address account,box contents)
。
encodeData
一个 boxed value 被编码为它的底层 unboxed value,即 hashStruct(value) = keccak256(typeHash, encodeData(value))
其中 typeHash
对应于 unboxed type 并且 encodeData
正在对该类型的值进行操作。
signTypedData
schema
一个涉及 boxed member 的 EIP-712 消息的签名请求应包括 unboxed type 作为消息对象的一部分。一个 boxed value 必须是一个具有属性 value
、primaryType
和 types
的对象。value
应根据 primaryType
和 types
进行类型检查和编码,类似于 EIP-712 消息(但没有 \x19
前缀)。在 boxed value 之外的消息中定义的 types
不应在 boxed value 的编码范围内。
例如,上面 Envelope
类型的消息可以表示为:
{
domain: ...,
primaryType: 'Envelope',
types: {
Envelope: [
{ name: 'account', type: 'address' },
{ name: 'contents', type: 'box' }
]
},
message: {
account: '0x...',
contents: {
primaryType: 'Mail',
types: {
Mail: [
{ name: 'greeting', type: 'string' }
],
},
value: {
greeting: 'Hello world'
}
},
}
}
boxed value 的 JSON Schema
{
type: 'object',
properties: {
value: {type: 'object'},
primaryType: {type: 'string'},
types: {
type: 'object',
additionalProperties: {
type: 'array',
items: {
type: 'object',
properties: {
name: {type: 'string'},
type: {type: 'string'}
},
required: ['name', 'type']
}
}
}
},
required: ['value', 'primaryType', 'types']
}
理由
待定
安全考虑
需要讨论。
版权
通过 CC0 放弃版权和相关权利。
Citation
Please cite this document as:
Francisco Giordano (@frangio), "EIP-7713: EIP-712 消息的 Box 类型 [DRAFT]," Ethereum Improvement Proposals, no. 7713, May 2024. [Online serial]. Available: https://eips.ethereum.org/EIPS/eip-7713.