Add interop framework#26
Conversation
0xteddybear
left a comment
0xteddybear
left a comment
There was a problem hiding this comment.
looking good! I believe pointing to specific instances of the various interop types could help making this document even easier to follow (e.g, OP interop, where you can reference any event in a chain in your dependency set, being mentioned as a broad protocol)
I'm also ambivalent on wether we should make this part of NOMENCLATURE.md, wdyt?
Good point, I think we could leave this document separate as a verbose explainer of interoperability/message-passing, those comparisons and characterization are really useful. I would suggest some simple graphs/more examples |
Co-authored-by: 0xRaccoon <112493530+0xRaccoon@users.noreply.github.com>
| - **Targetted vs Broadcast** | ||
| - A targetted message inherently specifies a receiver on a destination chain. | ||
| - Some protocols allow atomic bundles of messages, each specifying a different receiver. | ||
| - A broadcast message doesn't specify a receiver. It may specify a destination chain. |
There was a problem hiding this comment.
In practice, broadcast messages are still received on-chain, just by whoever chooses to process them rather than pre-specified recipients. ERC-7786 can represent this as address(0). I would say the following should be clearer:
| - A broadcast message doesn't specify a receiver. It may specify a destination chain. | |
| - A broadcast message doesn't specify a receiver, making it available for any contract or user to process on the destination chain. Semantically, this can be represented as sending to `address(0)` or a similar convention. |
5 participants
Documenting some of the design choices that have come up, and giving them names so we can discuss and decide.