Add ERC: Gateway Attributes for Message Control #1114
Conversation
|
✅ All reviewers have approved. |
ernestognw
changed the title
ernestognw
changed the title
ERCS/erc-xxxx.md
Outdated
|
|
||
| Specifies message dependencies that must be executed before this message. This attribute uses selector `0xa9fed7b9`, derived from the first 4 bytes of `keccak256("dependsOn(bytes32[])")`. | ||
|
|
||
| The value is encoded as an ABI-encoded array of message identifiers. Gateways MUST NOT execute a message until all messages specified in the `dependsOn` array have been successfully executed. When not specified or empty, the message has no dependencies. This ensures correct ordering and prevents out-of-order delivery issues. |
There was a problem hiding this comment.
Should the way the status of the messages is tracked also be standardized?
The gateway must be able to verify if the message was executed for this attribute to work, but there are also a couple of different places where it could be useful/is required for attributes to be able to work correctly with each other.
For example, we have cancellation, which assumably can also just modify the status of the message, so the gateway knows that it shouldn't be executed/etc after cancellation.
Same argument as before goes for messages which were failed. If the message had revertBehavior attribute, and was processed by gateway but failed, I assume it should be executed/cancelled/etc after failing.
There was a problem hiding this comment.
Right, I suspect ERC-7786 already covers the properties you're describing about messages. So I was thinking to reuse the definition of "delivery" from ERC-7786 rather than defining new status tracking mechanisms. ERC-7786 already establishes a clear message lifecycle: messages are sent (via MessageSent event) and then delivered (via successful receiveMessage call).
I've updated the specification to make this relationship clear; all references to "execution" have been changed to "delivery" to align with ERC-7786's terminology. I also renamed timeout/earliestExecTime to deliverBefore/deliverAfter for consistency.
eip-review-bot
changed the title
|
The commit a213526 (as a parent of 6af3e36) contains errors. |
| --- | ||
| eip: 7985 | ||
| title: Gateway Attributes for Message Control | ||
| description: Gateway attributes for cancellation, timeout, retry, dependencies, and delivery control in cross-chain messaging. |
There was a problem hiding this comment.
I don't know what a "gateway attribute" is, and I'm probably representative of the average ERC reader. This is an extremely tiny nit, but if you could choose a different wording in your description that might make it more obvious, I think it would make better use of the limited character space.
| #### `deliverBefore(uint256)` | ||
|
|
||
| Specifies a timestamp after which the message cannot be delivered. This attribute uses selector `0x3e97d7ee`, derived from the first 4 bytes of `keccak256("deliverBefore(uint256)")`. |
There was a problem hiding this comment.
deliverBefore sounds like it implies now < value, where the description of this method implies now <= value. Is that intentional?
eip-review-bot
left a comment
eip-review-bot
left a comment
There was a problem hiding this comment.
All Reviewers Have Approved; Performing Automatic Merge...
6 participants
Introduces standard attributes for ERC-7786 cross-chain messaging gateways, enabling consistent message lifecycle control across implementations.
Adds 7 standard attributes:
cancellable(bool)- Message cancellationtimeout(uint256)- Automatic expirationearliestExecTime(uint256)- Delayed executionretryPolicy(bytes)- Retry mechanismsrevertBehavior(uint8)- Failure handlingdependsOn(bytes32[])- Message dependenciesminGasLimit(uint256)- Gas requirementsBenefits: Ecosystem consistency, predictable APIs, advanced workflows, and reliable error handling. Extends ERC-7786 without breaking changes. Emerged from discussions with Matter Labs' InteropCenter team addressing real-world cross-chain messaging requirements.