Add ERC: Proof-based Broadcast in ERC-7786 Gateways #1072
Conversation
|
✅ All reviewers have approved. |
eip-review-bot
changed the title
ERCS/erc-xxxx.md
Outdated
| 1. Parse the `route` and `storageProof` attributes from the message, and optionally `targetBlock` if provided | ||
| 2. Validate all required attributes are present and well-formed | ||
| 3. For each route step, verify block hash transition using the paired proof and validate version requirements if specified (non-zero) | ||
| 4. Use the `storageProof` to verify that message data exists in the source chain's state at the target block obtained from the route verification |
There was a problem hiding this comment.
In here the verification process should clarify that the storage proof must correspond to the source chain identified by the completed route verification, what I mean by this is it should use the storageProof to verify that message data exists in the source chain's state at the target block. The source chain MUST correspond to the final validated step in the route verification process.
There was a problem hiding this comment.
Hi! Thanks for your feedback! I've updated to clarify that "The source chain SHOULD correspond to the final validated step in the route verification process."
I'm using SHOULD rather than MUST since I'm unsure about its enforceability. Perhaps there's a use case in sending through a different chain for better prices so I don't want to be too constraining here.
eip-review-bot
changed the title
ernestognw
changed the title
eip-review-bot
changed the title
|
|
||
| ### Verification Process | ||
|
|
||
| Message verification follows these steps: |
There was a problem hiding this comment.
My understanding is that this verification logic happens on the receiving end (destination chain). It described how to verify something actually happened on the source chain.
What I don't understand is:
-
what is the relationship between the "data" part of the ERC-7786 message and these attributes. It it the 7786 receiver the one that must match the data and the attributes it receives, and interpret the data in the context of these attributes which have been verified by the destination gateway ?
-
how are these atributes set on the sending side. If the sender expected to build them before doing the
sendcall on the source chain? If so, that means they have to correspond to data that was in place (part of the state) at least 1 block before the "send" is mined. The fact that setting the data in place, and sending the crosschain message must be done in separate block feels like a big downside.
There was a problem hiding this comment.
I addressed the first point a bit better in cebfce8.
For the second point, I know each protocol has a different way of generating the proof for the same block they're proposing. For example, Taiko's SignalService uses anchor transactions at the beginning of each L2 block to establish verifiable state commitments, eliminating the need for separate block commitments. I'm not sure if this standard should determine how that's done
|
Blocked on #1050 |
|
The commit 5331578 (as a parent of a01f995) contains errors. |
Extends ERC-7786 cross-chain messaging with cryptographic proof-based verification and granular broadcasting semantics. It enables trustless message verification using blockchain consensus mechanisms rather than external validators or multisigs.
The specification defines three ERC-7786 attributes:
route()for multi-hop verification paths,inclusionProof()for cryptographic evidence of message commitment, and optionaltargetBlock()for finality validation.Broadcasting leverages ERC-7930 addresses to enable targeted message distribution: empty address components broadcast to all addresses on specific chains, empty chain references broadcast to all chains of a type, and fully zeroed addresses enable universal broadcasting.