ERC-7786 提案规范：跨链消息传递网关

erc7786
发布于 2025-03-05 19:51
阅读 31

本文介绍了一种跨链消息传递接口的提案，旨在通过提供标准化的接口和工作流程，使智能合约能够在不同区块链之间发送和接收消息，从而提高协议的可组合性和互操作性。提案强调了设计的模块化特性，以便用户能够利用特定桥的功能，同时确保通用访问。还详细定义了消息字段编码、发送和接收程序等规范。

ERC-7786 一个供合约发送和接收跨链消息的接口。

## 摘要

本提案描述了一个接口，以及相应的工作流程，用于智能合约通过跨链消息协议发送任意数据。该提案的最终目标是使所有这些消息协议通过这个接口（本地或使用“适配器”）可访问，以改善它们的组合性和互操作性。这将允许一种新类型的跨链原生智能合约出现，同时减少供应商锁定。本提案是模块化设计，使用户能够通过属性利用桥的特定功能，同时提供简单的“通用”访问，只需“通过简单消息进行传递”。

## 动机

跨链消息协议（或桥接）允许在不同区块链上部署的智能合约之间进行通信。这些协议具有高度的多样性，具有多个去中心化程度、不同的架构，实施不同的接口，并提供不同的用户保障。

由于几乎每个协议都使用特定接口实现不同的工作流程，因此目前桥接之间的可移植性基本上是不可能的。这也阻止了依赖于跨链通信的通用合约的开发。

ERC的目标是为合约之间进行跨链通信提供标准接口和相应的工作流程。现有的未本地实施此接口的跨链通信协议应能够通过适配器网关合约来采用它。

与该领域以前的ERC相比，该ERC提供了与以太坊/EVM生态系统以外的链的兼容性，并且可扩展以支持各种协议的不同功能集，同时提供共享核心的标准功能。

## 规范

本文档中的关键字“MUST”、“MUST NOT”、“REQUIRED”、“SHALL”、“SHALL NOT”、“SHOULD”、“SHOULD NOT”、“RECOMMENDED”、“NOT RECOMMENDED”、“MAY”和“OPTIONAL”应按RFC 2119和RFC 8174中的描述进行解释。

### 消息字段编码

跨链消息由发送者、接收者、有效载荷和属性列表组成。

#### 发送者与接收者

- 发送者帐户（在源链中）和接收者帐户（在目标链中）MUST使用CAIP-10帐户标识符表示。注意这些是ASCII编码的字符串。

- CAIP-10帐户标识符嵌入了CAIP-2链标识符和一个地址。在接口的某些部分，地址和链部分将分别提供，而不是作为单个字符串，或者链部分将是隐式的。

#### 有效载荷

- 有效载荷是一个不透明的`bytes`值。

#### 属性

- 属性是结构化的消息数据和/或元数据，每个属性是一个键值对，其中键确定值的类型和编码，以及其含义和行为。

- 一些属性是必须发送给接收者的消息数据，尽管它们可以进行变换，只要其含义得以保留。其他属性是元数据，将由中介网关使用，并可能在消息到达接收者之前被移除。

- 属性集是可扩展的。建议通过将其发布为ERC来标准化属性及其特征。

- 网关可以支持任何属性集。一个空属性列表MUST始终被网关接受。

- 每个属性键MUST具有Solidity函数签名的格式，即名后跟圆括号内的类型列表。例如，`minGasLimit(uint256)`。

- 在本规范中，属性编码为`bytes`数组（即`bytes[]`）。数组的每个元素MUST以Solidity函数调用的形式编码属性，即键哈希的头4个字节后跟ABI编码的值。

### 发送程序

源网关是一个数量合约，提供协议以向另一个链上的接收者发送消息。它MUST实现`IERC7786GatewaySource`。

```vocs_Code

Copyinterface IERC7786GatewaySource {
    event MessagePosted(bytes32 indexed outboxId, string sender, string receiver, bytes payload, uint256 value, bytes[] attributes);

error UnsupportedAttribute(bytes4 selector);

function supportsAttribute(bytes4 selector) external view returns (bool);

function sendMessage(
        string calldata destinationChain, // CAIP-2链标识符
        string calldata receiver, // CAIP-10帐户地址
        bytes calldata payload,
        bytes[] calldata attributes
    ) external payable returns (bytes32 outboxId);
}
```

#### `supportsAttribute`

返回一个布尔值，指示网关是否支持由属性签名计算得出的选择器标识的属性。

网关MAY可以通过扩大支持其他属性。一旦存在，属性的支持SHOULD不被移除，以保持与网关用户的向后兼容性。

#### `sendMessage`

启动消息发送。

网关MAY需要进一步的操作以使消息发送有效，例如支付Gas费用。详见后处理。

如果包括不支持的属性键，MUST回滚`UnsupportedAttribute`。如果属性的值不是预期类型的有效编码，MAY回滚。

MAY接受与消息一起发送的调用值（原生代币）。如果调用值被包含但不是网关支持的功能，MUST回滚。关于此值在目标的表示方式没有规定。

MAY生成并返回一个唯一的非零**出箱标识符**，否则返回零。此标识符可用来跟踪消息在事件中的生命周期以及后处理。

MUST发出`MessagePosted`事件，包括通过该函数返回的可选出箱标识符。

#### `MessagePosted`

此事件表示潜在的发送者已请求发送一条消息。

如果`outboxId`存在，则可能需要后处理以通过跨链通道发送消息。

#### 后处理

在发送者调用`sendMessage`之后，网关可能需要进一步的操作以使消息有效。这被称为**后处理**。例如，通常需要一些支付以覆盖在目的地执行消息的Gas费用。

任何此类操作的确切接口超出了本ERC的范围。如果支持并且存在`postProcessingOwner`属性，则此类操作MUST限制为指定帐户，否则MUST可以由任何方执行，并且该方式MUST不会妨碍消息的最终接收。

### 接收程序

目标网关是实现协议以验证在其他链上发送的消息的合约。目标网关的接口及其如何调用超出了本ERC的范围。

该协议MUST确保使用`IERC7786Receiver`接口（下面指定），将发送的消息传递给其**接收者**，接收者MUST实现该接口。

一旦消息可以安全地传递（见*属性*），网关MUST调用`executeMessage`并传递消息内容。

网关MUST验证`executeMessage`返回正确的值，否则MUST回滚。

```vocs_Code

Copyinterface IERC7786Receiver {
    function executeMessage(
        string calldata sourceChain, // CAIP-2链标识符
        string calldata sender, // CAIP-10帐户地址
        bytes calldata payload,
        bytes[] calldata attributes
    ) external payable returns (bytes4);
}
```

#### `executeMessage`

接收在其他链上发送的消息。

接收者MUST验证调用此函数的方是**已知的网关**，即其受信任的底层跨链消息协议。

MUST返回`IERC7786Receiver.executeMessage.selector`（`0x675b049b`）。

#### 交互图

![](https://www.erc7786.org/assets/eip-7786/send-execute.svg)

### 属性

一对网关的协议预计要保证一系列属性。有关详细定义和讨论，请参考XChain Research的*"跨链互操作性报告"*。

- 该协议MUST保证安全性：消息在目的地送达当且仅当它在源地被发送。传递过程必须确保消息仅在发送交易最终确定后交付，并且不超过一次地交付。注意，可能存在多个具有相同参数的消息必须分别交付。
- 该协议MUST保证活力：一条已发送的消息最终将在目的地交付，前提是源和目的地链的活力和抵制审查。
- 该协议SHOULD保证及时性：已发送的消息在界定的交付时间内交付给目的地，这一点应有相关文档记录。
- 上述属性SHOULD不依赖于某些中心化参与者的信任。例如，安全性应通过无信任机制来保证，例如轻客户端证明或开放的去中心化验证者集的证明。中继应去中心化或无权限，以确保活力；中心化的中继者可以失败，从而停止协议。

### 待讨论事项

- `sendMessage`的目的地和接收者输入应保持为两个分开的字符串，还是合并为一个带有`:`分隔符的单一CAIP-10字符串？这影响到某些情况下可能存储的calldata长度。
- 我们是否希望网关能够通知用户新版本的地址，类似于`AccessManager`可以更新的被`AccessManaged`信任的权限？如果一个网关最终被弃用以换取新版本，这可能非常有用。
- 数据和元数据属性是否应分为两类？数据属性用于什么？我们需要它们吗？
- 传递完整有效载荷还是有效载荷哈希（如Axelar所做）？属性同样的问题，根据属性的可变性，答案可能不同。

## 理由

属性的设计使得网关可以公开桥接所提供的任何特定功能，而不必使用特定端点。通过属性具有唯一端点和模块化的能力SHOULD允许合约在继续以相同方式表达消息的同时更改其使用的网关。这种可移植性提供了许多优点：

- 依赖于特定网关发送消息的合约易受网关暂停、弃用或损坏的影响。如果合约与网关之间的通信是标准化的，合约的管理员可以更新网关的地址（在存储中）。特别是，当可用新版本时，发送者可更新到新网关。
- 桥接分层SHOULD是可能的。特别是，这个接口应该允许新类型的桥将消息通过多个独立的桥进行路由。消息的交付可能需要依赖于这些独立桥中的一个或多个，具体取决于改进活力或安全性的需求。

由于一些跨链通信协议需要超出目的地和有效载荷的额外参数，并且因为我们希望在不了解这些额外参数的情况下通过这些桥发送消息，因此可能需要对消息进行后处理（在调用`sendMessage`之后，在消息传递之前）。额外参数MAY通过属性支持，这将消除对后处理步骤的需求。如果这些额外参数未通过属性提供，则需要对网关执行额外调用以发送该消息。如果可能，网关SHOULD设计成这样，任何对消息交付有激励的人都可以介入。提供无效参数的恶意行为者MUST不应妨碍其他人成功中继消息。

一些协议网关支持对接收者进行任意直接调用。在这种情况下，接收者必须检测他们是被网关调用，以正确识别跨链消息。网关上可以获取来自哪个跨链消息的信息（源链和发送者地址）。这种方法的缺点是，它允许任何人从网关向任何合约触发任何调用。如果网关持有任何资产[ERC-20](https://eips.ethereum.org/EIPS/eip-20)或类似内容，这将很危险。接收者上使用专门的`executeMessage`函数保护任何由网关持有的资产或权限免受这种攻击。如果想要执行直接调用，可以在任何实现此ERC的网关上实现一个包装器。

### 适配器

未来

## 向后兼容性

现有的跨链消息协议实现专有接口。我们建议协议本地实现此处定义的标准接口，并建议为那些未实现该接口的协议开发标准适配器。

## 安全考虑

不幸的是，CAIP-2和CAIP-10名称并不唯一。使用非规范字符串可能导致未定义行为，包括消息传递失败和资产锁定。虽然源网关在确保用户输入有效方面发挥作用，但我们还认为应更加努力标准化并记录每个CAIP-2命名空间的规范格式。这一工作超出了本ERC的范围。

需要讨论。

## 版权

通过[CC0](https://learnblockchain.cn/article/14117)放弃版权及相关权利。

>- 原文链接： [erc7786.org/erc...](https://www.erc7786.org/erc)
>- 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～

ERC-7786 一个供合约发送和接收跨链消息的接口。

摘要

动机

ERC的目标是为合约之间进行跨链通信提供标准接口和相应的工作流程。现有的未本地实施此接口的跨链通信协议应能够通过适配器网关合约来采用它。

规范

消息字段编码

跨链消息由发送者、接收者、有效载荷和属性列表组成。

发送者与接收者

发送者帐户（在源链中）和接收者帐户（在目标链中）MUST使用CAIP-10帐户标识符表示。注意这些是ASCII编码的字符串。
CAIP-10帐户标识符嵌入了CAIP-2链标识符和一个地址。在接口的某些部分，地址和链部分将分别提供，而不是作为单个字符串，或者链部分将是隐式的。

有效载荷

有效载荷是一个不透明的bytes值。

属性

属性是结构化的消息数据和/或元数据，每个属性是一个键值对，其中键确定值的类型和编码，以及其含义和行为。
一些属性是必须发送给接收者的消息数据，尽管它们可以进行变换，只要其含义得以保留。其他属性是元数据，将由中介网关使用，并可能在消息到达接收者之前被移除。
属性集是可扩展的。建议通过将其发布为ERC来标准化属性及其特征。
网关可以支持任何属性集。一个空属性列表MUST始终被网关接受。
每个属性键MUST具有Solidity函数签名的格式，即名后跟圆括号内的类型列表。例如，minGasLimit(uint256)。
在本规范中，属性编码为bytes数组（即bytes[]）。数组的每个元素MUST以Solidity函数调用的形式编码属性，即键哈希的头4个字节后跟ABI编码的值。

发送程序

源网关是一个数量合约，提供协议以向另一个链上的接收者发送消息。它MUST实现IERC7786GatewaySource。


Copyinterface IERC7786GatewaySource {
    event MessagePosted(bytes32 indexed outboxId, string sender, string receiver, bytes payload, uint256 value, bytes[] attributes);

    error UnsupportedAttribute(bytes4 selector);

    function supportsAttribute(bytes4 selector) external view returns (bool);

    function sendMessage(
        string calldata destinationChain, // CAIP-2链标识符
        string calldata receiver, // CAIP-10帐户地址
        bytes calldata payload,
        bytes[] calldata attributes
    ) external payable returns (bytes32 outboxId);
}

`supportsAttribute`

返回一个布尔值，指示网关是否支持由属性签名计算得出的选择器标识的属性。

网关MAY可以通过扩大支持其他属性。一旦存在，属性的支持SHOULD不被移除，以保持与网关用户的向后兼容性。

`sendMessage`

启动消息发送。

网关MAY需要进一步的操作以使消息发送有效，例如支付Gas费用。详见后处理。

如果包括不支持的属性键，MUST回滚UnsupportedAttribute。如果属性的值不是预期类型的有效编码，MAY回滚。

MAY接受与消息一起发送的调用值（原生代币）。如果调用值被包含但不是网关支持的功能，MUST回滚。关于此值在目标的表示方式没有规定。

MAY生成并返回一个唯一的非零出箱标识符，否则返回零。此标识符可用来跟踪消息在事件中的生命周期以及后处理。

MUST发出MessagePosted事件，包括通过该函数返回的可选出箱标识符。

`MessagePosted`

此事件表示潜在的发送者已请求发送一条消息。

如果outboxId存在，则可能需要后处理以通过跨链通道发送消息。

后处理

在发送者调用sendMessage之后，网关可能需要进一步的操作以使消息有效。这被称为后处理。例如，通常需要一些支付以覆盖在目的地执行消息的Gas费用。

任何此类操作的确切接口超出了本ERC的范围。如果支持并且存在postProcessingOwner属性，则此类操作MUST限制为指定帐户，否则MUST可以由任何方执行，并且该方式MUST不会妨碍消息的最终接收。

接收程序

目标网关是实现协议以验证在其他链上发送的消息的合约。目标网关的接口及其如何调用超出了本ERC的范围。

该协议MUST确保使用IERC7786Receiver接口（下面指定），将发送的消息传递给其接收者，接收者MUST实现该接口。

一旦消息可以安全地传递（见属性），网关MUST调用executeMessage并传递消息内容。

网关MUST验证executeMessage返回正确的值，否则MUST回滚。


Copyinterface IERC7786Receiver {
    function executeMessage(
        string calldata sourceChain, // CAIP-2链标识符
        string calldata sender, // CAIP-10帐户地址
        bytes calldata payload,
        bytes[] calldata attributes
    ) external payable returns (bytes4);
}

`executeMessage`

接收在其他链上发送的消息。

接收者MUST验证调用此函数的方是已知的网关，即其受信任的底层跨链消息协议。

MUST返回IERC7786Receiver.executeMessage.selector（0x675b049b）。

交互图

属性

一对网关的协议预计要保证一系列属性。有关详细定义和讨论，请参考XChain Research的"跨链互操作性报告"。

该协议MUST保证安全性：消息在目的地送达当且仅当它在源地被发送。传递过程必须确保消息仅在发送交易最终确定后交付，并且不超过一次地交付。注意，可能存在多个具有相同参数的消息必须分别交付。
该协议MUST保证活力：一条已发送的消息最终将在目的地交付，前提是源和目的地链的活力和抵制审查。
该协议SHOULD保证及时性：已发送的消息在界定的交付时间内交付给目的地，这一点应有相关文档记录。
上述属性SHOULD不依赖于某些中心化参与者的信任。例如，安全性应通过无信任机制来保证，例如轻客户端证明或开放的去中心化验证者集的证明。中继应去中心化或无权限，以确保活力；中心化的中继者可以失败，从而停止协议。

待讨论事项

sendMessage的目的地和接收者输入应保持为两个分开的字符串，还是合并为一个带有:分隔符的单一CAIP-10字符串？这影响到某些情况下可能存储的calldata长度。
我们是否希望网关能够通知用户新版本的地址，类似于AccessManager可以更新的被AccessManaged信任的权限？如果一个网关最终被弃用以换取新版本，这可能非常有用。
数据和元数据属性是否应分为两类？数据属性用于什么？我们需要它们吗？
传递完整有效载荷还是有效载荷哈希（如Axelar所做）？属性同样的问题，根据属性的可变性，答案可能不同。

理由

依赖于特定网关发送消息的合约易受网关暂停、弃用或损坏的影响。如果合约与网关之间的通信是标准化的，合约的管理员可以更新网关的地址（在存储中）。特别是，当可用新版本时，发送者可更新到新网关。
桥接分层SHOULD是可能的。特别是，这个接口应该允许新类型的桥将消息通过多个独立的桥进行路由。消息的交付可能需要依赖于这些独立桥中的一个或多个，具体取决于改进活力或安全性的需求。

由于一些跨链通信协议需要超出目的地和有效载荷的额外参数，并且因为我们希望在不了解这些额外参数的情况下通过这些桥发送消息，因此可能需要对消息进行后处理（在调用sendMessage之后，在消息传递之前）。额外参数MAY通过属性支持，这将消除对后处理步骤的需求。如果这些额外参数未通过属性提供，则需要对网关执行额外调用以发送该消息。如果可能，网关SHOULD设计成这样，任何对消息交付有激励的人都可以介入。提供无效参数的恶意行为者MUST不应妨碍其他人成功中继消息。

一些协议网关支持对接收者进行任意直接调用。在这种情况下，接收者必须检测他们是被网关调用，以正确识别跨链消息。网关上可以获取来自哪个跨链消息的信息（源链和发送者地址）。这种方法的缺点是，它允许任何人从网关向任何合约触发任何调用。如果网关持有任何资产ERC-20或类似内容，这将很危险。接收者上使用专门的executeMessage函数保护任何由网关持有的资产或权限免受这种攻击。如果想要执行直接调用，可以在任何实现此ERC的网关上实现一个包装器。

适配器

未来

向后兼容性