docs: message-passing groups current goals and status #13

elliedavidson · 2025-02-13T15:25:58Z

This PR adds a doc page formalizing the Message Passing Working Group goals and progress. It also adds the properties decided on in Denver.

…d status

docs/messaging-working-group.md

0xteddybear

I have nitpicks and questions mostly 😁

Should we start by defining the existing efforts and comparing them, similar to how we are doing for cross-chain addresses? would y'all consider that in scope for this PR

0xteddybear · 2025-02-14T23:25:22Z

docs/messaging-working-group.md

+* Should the interface be pull or push-based? 
+* Should the interface use Ethereum specific addresses?  
+* Should the interface defined specific message formats for specific use cases? 
+* Should the interface use 7786-style attributes


nit: missing question mark

0xteddybear · 2025-02-14T23:26:21Z

docs/messaging-working-group.md

+
+### Timeline: 
+* 2/17/2025: Core contibutors identified. 
+* 2/24/2025: Agreement on goals has been reached among core contributors, broader group feedback welcome. 


nit: consider using ISO-8601 dates

0xteddybear · 2025-02-14T23:43:10Z

docs/messaging-working-group.md

+3. Identifying core contributors to move this consensus forward quickly.  We will ask for feedback from the broader group periodically. 
+4. Establishing commitments and timelines from core projects to implement the interface once it is finalized. 
+
+### Timeline: 


just to see if I should be following something else to stay in the loop: are the deliverables on this deadline going to be contained in this document? only linked from here? or tracked somewhere else entirely

0xteddybear

I believe the next step to make this easier to follow would be to elaborate on a comparison of the current efforts, showing which parts we should pick&choose from the existing alternatives in docs/messaging-comparisos.md, wdyt?

0xteddybear · 2025-03-04T17:06:00Z

docs/messaging-working-group.md

+
+### Message Format
+
+Message {


include all of this in a code block

0xteddybear · 2025-03-04T17:08:53Z

docs/messaging-working-group.md

+
+
+Questions: 
+* Should we allow tx hash as unique id? 


as the unique id of what in particular? a message? a message in a particular (source/destination/intermediate?) chain?

0xteddybear · 2025-03-04T17:19:56Z

docs/messaging-working-group.md

+
+#### 1a. Developers should not need to use wrapper contracts to interact with the interface. 
+
+### 2. Interface should be VM-agnostic.  --> Agree


Given this, I imagine 'the interface' can't be an ABI specification, as that would be coupled to how a particular VM handles function calls, so how would it look like? at what part of the tech stack would this interface live?

cjcobb23 · 2025-03-07T01:36:18Z

docs/messaging-working-group.md

+packet_id - unique id, bytes
+
+// destination addr 
+fn send (payload, (destination address?), destination chain) -> packet id


I had a couple of thoughts about the packet id that i wanted to leave here.

In denver, we talked about returning a globally unique packet id from send, and we said it should be the hash of the entire message. There are a few issues with this.

Different VMs may not have the same hashing functions available, so using the hash doesn't get us much besides uniqueness in that case, since the destination chain may not be able to rehash and get the same id.

While we decided to use traditional push based message passing instead of arbitrary remote reads, the latter will exist eventually, and also requires some sort of id. I think the most natural id for that paradigm is using transaction hash + event index to identify an event on a remote chain. If we cannot use the transaction hash in our interface as the message id, it could lead to issues down the road.

While hashing the message, which contains a nonce, gives a globally unique identifier within the protocol, it is not necessarily a globally unique identifier for events across the whole blockchain. Another unrelated contract could emit an event with the same id as our packet id, for example maybe even a different interop protocol. Whereas using the transaction hash + event index is a truly globally unique identifier for the event across the entire blockchain.

So I think send should still just return a local id (the nonce). I don't think we lose anything by doing that, since the caller can still use it to pay gas. But the protocol can use whatever it likes as the globally unique packet id, which is passed to the receiving chain.

0xRaccoon · 2025-03-13T20:24:19Z

docs/messaging-working-group.md

+A user can bridge assets between any two Lns within 3 slots or less of the slower chain.
+
+Things required to achieve this goal: 
+* Message passing protocols to physically relay information from one chain to another. Different protocols have different tradeoffs and security properties, and different L2s may use different protocols. 


Suggested change

* Message passing protocols to physically relay information from one chain to another. Different protocols have different tradeoffs and security properties, and different L2s may use different protocols.

* Message passing protocols to physically relay information from one chain to another. Different protocols have different trade-offs and security properties, and different L2s may use different protocols.

0xRaccoon · 2025-03-13T20:25:21Z

docs/messaging-working-group.md

+
+Things required to achieve this goal: 
+* Message passing protocols to physically relay information from one chain to another. Different protocols have different tradeoffs and security properties, and different L2s may use different protocols. 
+* Common, abstracted interface for devs to interact with messaging protocols.  Devs should not have to worry about the underlying protocol to bridge between chains.  Cross-chain applications should be able to be built on top of any messaging protocol that supports the interface. See [ERC-7841's](https://github.com/elliedavidson/ERCs/blob/d7c16c21f0a012ef391783322ae9b6f0eb0b56bc/ERCS/erc-7841.md) *Motivation* section for details about this goal. 


Suggested change

* Common, abstracted interface for devs to interact with messaging protocols. Devs should not have to worry about the underlying protocol to bridge between chains. Cross-chain applications should be able to be built on top of any messaging protocol that supports the interface. See [ERC-7841's](https://github.com/elliedavidson/ERCs/blob/d7c16c21f0a012ef391783322ae9b6f0eb0b56bc/ERCS/erc-7841.md) *Motivation* section for details about this goal.

* Common, abstracted interface for devs to interact with messaging protocols. Devs should not have to worry about the underlying protocol to bridge between chains. Cross-chain applications should be able to be built on top of any messaging protocol that supports the interface. See [ERC-7841's](https://github.com/elliedavidson/ERCs/blob/d7c16c21f0a012ef391783322ae9b6f0eb0b56bc/ERCS/erc-7841.md) *Motivation* section for details about this goal.

0xRaccoon · 2025-03-13T20:27:11Z

docs/messaging-working-group.md

+
+1. Agreeing that such an interface is useful. 
+2. Agreeing whether goal 1 listed below is in scope for this working group. We will iterate through each goal below until we reach rough consensus among core contributors. 
+3. Identifying core contributors to move this consensus forward quickly.  We will ask for feedback from the broader group periodically. 


Suggested change

3. Identifying core contributors to move this consensus forward quickly. We will ask for feedback from the broader group periodically.

3. Identifying core contributors to move this consensus forward quickly. We will ask for feedback from the broader group periodically.

0xRaccoon · 2025-03-13T21:15:35Z

docs/messaging-working-group.md

+### 1. Interface supports only the most common use cases: bridging and cross-chain function calls. --> We'll start with 90% of uses cases, aiming to make those APIs simple, and then we can add more complex use cases from there. 
+
+Reasoning:  
+* Supporting all use cases results in a more complex interface.  This may lead developers to use wrapper contracts to simplify the interface or to not adopt the interface at all, defeating the purpose of the interface.  


Suggested change

* Supporting all use cases results in a more complex interface. This may lead developers to use wrapper contracts to simplify the interface or to not adopt the interface at all, defeating the purpose of the interface.

* Supporting all use cases results in a more complex interface. This may lead developers to use wrapper contracts to simplify the interface or to not adopt the interface at all, defeating the purpose of the interface.

0xRaccoon · 2025-03-13T21:16:25Z

docs/messaging-working-group.md

+### 3. Interface should be proof-agnostic. --> Agree
+
+Reasoning:  
+* Many proof systems will be used in the underlying messaging protocols.  This interface should be compatible with any of those protocols. Otherwise, the interface does not achieve its primary goal abstracting the underlying messaging protocol from developers. 


Suggested change

* Many proof systems will be used in the underlying messaging protocols. This interface should be compatible with any of those protocols. Otherwise, the interface does not achieve its primary goal abstracting the underlying messaging protocol from developers.

* Many proof systems will be used in the underlying messaging protocols. This interface should be compatible with any of those protocols. Otherwise, the interface does not achieve its primary goal abstracting the underlying messaging protocol from developers.

0xRaccoon · 2025-03-13T21:16:40Z

docs/messaging-working-group.md

+### 4. Interface should be protocol-agnostic. --> Agree
+
+Reasoning: 
+* Many messaging protocols will be used.  This interface should be compatible with any of those protocols. 


Suggested change

* Many messaging protocols will be used. This interface should be compatible with any of those protocols.

* Many messaging protocols will be used. This interface should be compatible with any of those protocols.

0xRaccoon · 2025-03-13T21:18:08Z

docs/messaging-working-group.md

+
+push + local pull
+push + execute 
+don't need to worry about broadcast (for now


Suggested change

don't need to worry about broadcast (for now

don't need to worry about broadcast (for now)

* docs: add atomic swaps with local verification * Add sequence diagram * Fix typo * add standartization section * Fix typo * Simplify * Rephrease the standartization section * Add node about settlement time * Fix formatting of time calculation * Add Security Considerations section * Add reference in intent types

* Create csa-user-stories.md * improve user stories and allow chain discovery * add DS1 * add us5 and feedback * split sharing address/name case and apply feedback

* add comparison table * add chain-specific addresses properties * add comparison as reference * separate user and machine errors * remove a should-have property "Support for both user-facing and programmatic formats" * move security properties into must-have * correct caip-10 format * update comparison table * update table Correct EVM support in ERC-7828 * update table Clarify readability feature * remove flexibility field * improve checksum field clarify ERC-3770 status * improve chain list field * add status field * improve properties * update comparison table * add ensip-9 and ensip-11 * add address layers * add ensip-9 and ensip-11 comparison * separation of concerns and feedback * correct title Cross-Chain Addressing -> Naming Co-authored-by: Francisco Giordano <[email protected]> * improve csa properties * feat: Interoperable address spec (#14) * docs: address types draft with trivial resolvers * fix: initial feedback by joxes * feat: ens resolver spec * fix: fixes from self-review * feat: checksum as a layer of defense on human-readable names * feat: interoperable addresses explainer doc (#28) * docs: address types draft with trivial resolvers * fix: initial feedback by joxes * feat: ens resolver spec * fix: fixes from self-review * feat: checksum as a layer of defense on human-readable names * docs: interoperable address explainer --------- Co-authored-by: Francisco Giordano <[email protected]> Co-authored-by: teddy <[email protected]>

Includes: - add new folders - update READMEs - update links

…es (#31)

* fix: general polish and fixes Signed-off-by: 0xRaccoon <[email protected]> * fix: update PROPERTIES.md Co-authored-by: Joxes <[email protected]> --------- Signed-off-by: 0xRaccoon <[email protected]> Co-authored-by: Joxes <[email protected]>

* feat: rewrite as binary address POC * fix: cant index compact format over words * feat: go for shortest representation * feat: Standard Long Format * fix: small clarifications * chore: fix links * feat: 0xC000 address version * fix: wording and definitions * chore: ordering * feat: changes proposed when preparing for show&tell * feat: motivation section by joxes * fix: suggestions by racu * trivial examples for Appendix B * feat: made up my mind on byte array encoding

0xRaccoon · 2025-04-04T15:37:18Z

PROPERTIES.md

+
+### Must-have
+
+1. Safety - Assuming the mode of message verification is honest, a message is delivered at the destination iff it was sent at the source chain. 


Suggested change

1. Safety - Assuming the mode of message verification is honest, a message is delivered at the destination iff it was sent at the source chain.

1. Safety – Assuming the mode of message verification is honest, a message is delivered at the destination only if it was sent from the source chain.

0xRaccoon · 2025-04-04T15:39:11Z

PROPERTIES.md

+
+1. Safety - Assuming the mode of message verification is honest, a message is delivered at the destination iff it was sent at the source chain. 
+
+2. Liveness - Assuming liveness and censorship-resistance of the source and destination chains, a sent message is eventually delivered at the destination chain. 


Suggested change

2. Liveness - Assuming liveness and censorship-resistance of the source and destination chains, a sent message is eventually delivered at the destination chain.

2. Liveness – Assuming the liveness and censorship resistance of both the source and destination chains, any message sent is eventually delivered to the destination chain.

0xRaccoon · 2025-04-04T15:47:20Z

PROPERTIES.md

+
+2. Liveness - Assuming liveness and censorship-resistance of the source and destination chains, a sent message is eventually delivered at the destination chain. 
+
+3. VM-Agnosticism - Assuming the VM allows arbitrary logic, the interface can be implemented on any VM.  The interface works between many different VM implementations. 


Suggested change

3. VM-Agnosticism - Assuming the VM allows arbitrary logic, the interface can be implemented on any VM. The interface works between many different VM implementations.

3. VM-Agnosticism – Assuming the virtual machine supports arbitrary logic, the interface can be implemented on any VM. It enables interoperability across different VM implementations.

0xRaccoon · 2025-04-04T15:50:20Z

PROPERTIES.md

+3. VM-Agnosticism - Assuming the VM allows arbitrary logic, the interface can be implemented on any VM.  The interface works between many different VM implementations. 
+* Balance this goal with goal 6; the interface shouldn't be overly complex in order to achieve VM-agnosticism. 
+
+4. Proof-Agnosticism - The interface makes no assumption about how messages are proved to be valid. Many unique proof systems will be used in the underlying messaging protocols, and the interface works the same across all of them. 


Suggested change

4. Proof-Agnosticism - The interface makes no assumption about how messages are proved to be valid. Many unique proof systems will be used in the underlying messaging protocols, and the interface works the same across all of them.

4. Proof-Agnosticism – The interface makes no assumptions about how messages are proven valid. Various proof systems can be used in the underlying messaging protocols, and the interface functions uniformly across all of them.

0xRaccoon · 2025-04-04T15:57:59Z

docs/message-passing/message-passing-working-group.md

+
+### Why will applications adopt this standard?
+
+Adoption is always difficult with efforts like this. \<Insert relevant XKCD\>  However, we still feel it is the best way forward to achieve long term interoperability. Furthermore, the group has prioritized creating adapter contracts for major message passing protocols to ease adoption.


should \<Insert relevant XKCD\> be replaced?

0xRaccoon · 2025-04-04T16:03:22Z

docs/message-passing/message-passing-working-group.md

+
+## Open Discussions
+
+1. Should we allow a tx hash as unique id of a message?  Current protocols today use this hash as an id, but it adds complexity to the interface since the tx hash is not known at runtime.


We could enforce that the sendMessage function defined in the standard returns a unique bytes32 message ID for message identification.

Joxess

Great work on properties!

There are a few considerations I have regarding other aspects that aren't yet addressed, and I think it's worth having a place to capture them:

Definition of Events: Having global events like MessageSent / MessageReceived is extremely useful for integrators. Should the standards provide a definition or guideline for them? I think this would be a should or nice-to-have.
Message Identifiers: Same as above.
Chain Identifier and Address Formats: I believe the standards should (or as a nice-to-have) either support any format or follow an existing convention (similar to how ERC-7786 uses CAIP).
Bundling and Hooks: As a nice-to-have, I think the protocol should not make bundling and hooks impossible or overly restrictive.

Joxess · 2025-04-07T14:43:30Z

PROPERTIES.md

+
+### Should-have
+
+1. Timely Delivery - Assuming liveness and censorship resistance of the source and destination chains, messages should arrive within a known, bounded time delay. 


I'm not sure how this could be translated into the set of MP standards. Is this a way of saying that the lifecycle between sending and receiving shouldn't be controlled by any central actor? Validation and relayers could potentially interfere with this if the underlying protocol is permissioned.

Joxess · 2025-04-07T14:48:49Z

PROPERTIES.md

+
+1. L1 <-> L1 messaging - The interface should work to interoperate across L1s in the same way it interoperates within the Ethereum ecosystem. (This property is implied by the other properties). 
+
+2. Gas abstraction - The interface should support the ability for users to pay gas on the destination chain from the source chain, since this is required in most use cases. 


Is this separate from relayer/protocol fees? We should make it clear what the case is.

docs: add page describing the message-passing groups current goals an…

a7cd428

…d status

elliedavidson requested review from skeletor-spaceman and jrudolf February 13, 2025 15:26

Joxess reviewed Feb 13, 2025

View reviewed changes

docs/messaging-working-group.md Outdated Show resolved Hide resolved

0xteddybear reviewed Feb 14, 2025

View reviewed changes

elliedavidson added 2 commits February 24, 2025 21:01

Update messaging-working-group.md

de23115

Update messaging-working-group.md

ea2fb3f

0xteddybear reviewed Mar 4, 2025

View reviewed changes

cjcobb23 reviewed Mar 7, 2025

View reviewed changes

0xRaccoon reviewed Mar 13, 2025

View reviewed changes

Joxess and others added 12 commits April 3, 2025 21:32

docs: add ERC-7683 mermaids (#12)

a05ea6a

docs: Introduce interop nomenclatures (#24)

926381d

Feat: Create chain-specific addresses user stories (#25)

842600e

* Create csa-user-stories.md * improve user stories and allow chain discovery * add DS1 * add us5 and feedback * split sharing address/name case and apply feedback

feat: folder restructuration (#29)

db4ec7a

Includes: - add new folders - update READMEs - update links

fix: add binary representation requirement and remove chain hierarchi…

751aac8

…es (#31)

fix: general polish and fixes (#33)

4be6719

* fix: general polish and fixes Signed-off-by: 0xRaccoon <[email protected]> * fix: update PROPERTIES.md Co-authored-by: Joxes <[email protected]> --------- Signed-off-by: 0xRaccoon <[email protected]> Co-authored-by: Joxes <[email protected]>

finally update this PR with all that's happened

8956268

Merge branch 'main' into feat/message-passing-working-group-status

edd2337

Remove old file

49eb2e9

0xRaccoon reviewed Apr 4, 2025

View reviewed changes

Joxess reviewed Apr 7, 2025

View reviewed changes

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

docs: message-passing groups current goals and status #13

docs: message-passing groups current goals and status #13

elliedavidson commented Feb 13, 2025 •

edited

Loading

0xteddybear left a comment

0xteddybear Feb 14, 2025

0xteddybear Feb 14, 2025

0xteddybear Feb 14, 2025

0xteddybear left a comment

0xteddybear Mar 4, 2025

0xteddybear Mar 4, 2025

0xteddybear Mar 4, 2025

cjcobb23 Mar 7, 2025 •

edited

Loading

0xRaccoon Mar 13, 2025

0xRaccoon Mar 13, 2025

0xRaccoon Mar 13, 2025

0xRaccoon Mar 13, 2025

0xRaccoon Mar 13, 2025

0xRaccoon Mar 13, 2025

0xRaccoon Mar 13, 2025

0xRaccoon Apr 4, 2025

0xRaccoon Apr 4, 2025

0xRaccoon Apr 4, 2025

0xRaccoon Apr 4, 2025

0xRaccoon Apr 4, 2025

0xRaccoon Apr 4, 2025

Joxess left a comment

Joxess Apr 7, 2025

Joxess Apr 7, 2025


		#### 1a. Developers should not need to use wrapper contracts to interact with the interface.

		### 2. Interface should be VM-agnostic. --> Agree

	* Message passing protocols to physically relay information from one chain to another. Different protocols have different tradeoffs and security properties, and different L2s may use different protocols.
	* Message passing protocols to physically relay information from one chain to another. Different protocols have different trade-offs and security properties, and different L2s may use different protocols.

	3. Identifying core contributors to move this consensus forward quickly. We will ask for feedback from the broader group periodically.
	3. Identifying core contributors to move this consensus forward quickly. We will ask for feedback from the broader group periodically.

	* Supporting all use cases results in a more complex interface. This may lead developers to use wrapper contracts to simplify the interface or to not adopt the interface at all, defeating the purpose of the interface.
	* Supporting all use cases results in a more complex interface. This may lead developers to use wrapper contracts to simplify the interface or to not adopt the interface at all, defeating the purpose of the interface.

	* Many proof systems will be used in the underlying messaging protocols. This interface should be compatible with any of those protocols. Otherwise, the interface does not achieve its primary goal abstracting the underlying messaging protocol from developers.
	* Many proof systems will be used in the underlying messaging protocols. This interface should be compatible with any of those protocols. Otherwise, the interface does not achieve its primary goal abstracting the underlying messaging protocol from developers.

	* Many messaging protocols will be used. This interface should be compatible with any of those protocols.
	* Many messaging protocols will be used. This interface should be compatible with any of those protocols.

	don't need to worry about broadcast (for now
	don't need to worry about broadcast (for now)


		### Must-have

		1. Safety - Assuming the mode of message verification is honest, a message is delivered at the destination iff it was sent at the source chain.

	1. Safety - Assuming the mode of message verification is honest, a message is delivered at the destination iff it was sent at the source chain.
	1. Safety – Assuming the mode of message verification is honest, a message is delivered at the destination only if it was sent from the source chain.


		1. Safety - Assuming the mode of message verification is honest, a message is delivered at the destination iff it was sent at the source chain.

		2. Liveness - Assuming liveness and censorship-resistance of the source and destination chains, a sent message is eventually delivered at the destination chain.

	2. Liveness - Assuming liveness and censorship-resistance of the source and destination chains, a sent message is eventually delivered at the destination chain.
	2. Liveness – Assuming the liveness and censorship resistance of both the source and destination chains, any message sent is eventually delivered to the destination chain.


		2. Liveness - Assuming liveness and censorship-resistance of the source and destination chains, a sent message is eventually delivered at the destination chain.

		3. VM-Agnosticism - Assuming the VM allows arbitrary logic, the interface can be implemented on any VM. The interface works between many different VM implementations.

	3. VM-Agnosticism - Assuming the VM allows arbitrary logic, the interface can be implemented on any VM. The interface works between many different VM implementations.
	3. VM-Agnosticism – Assuming the virtual machine supports arbitrary logic, the interface can be implemented on any VM. It enables interoperability across different VM implementations.

	4. Proof-Agnosticism - The interface makes no assumption about how messages are proved to be valid. Many unique proof systems will be used in the underlying messaging protocols, and the interface works the same across all of them.
	4. Proof-Agnosticism – The interface makes no assumptions about how messages are proven valid. Various proof systems can be used in the underlying messaging protocols, and the interface functions uniformly across all of them.


		### Why will applications adopt this standard?

		Adoption is always difficult with efforts like this. \<Insert relevant XKCD\> However, we still feel it is the best way forward to achieve long term interoperability. Furthermore, the group has prioritized creating adapter contracts for major message passing protocols to ease adoption.


		## Open Discussions

		1. Should we allow a tx hash as unique id of a message? Current protocols today use this hash as an id, but it adds complexity to the interface since the tx hash is not known at runtime.


		### Should-have

		1. Timely Delivery - Assuming liveness and censorship resistance of the source and destination chains, messages should arrive within a known, bounded time delay.


		1. L1 <-> L1 messaging - The interface should work to interoperate across L1s in the same way it interoperates within the Ethereum ecosystem. (This property is implied by the other properties).

		2. Gas abstraction - The interface should support the ability for users to pay gas on the destination chain from the source chain, since this is required in most use cases.

docs: message-passing groups current goals and status #13

Are you sure you want to change the base?

docs: message-passing groups current goals and status #13

Conversation

elliedavidson commented Feb 13, 2025 • edited Loading

0xteddybear left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

0xteddybear left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

cjcobb23 Mar 7, 2025 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Joxess left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

elliedavidson commented Feb 13, 2025 •

edited

Loading

cjcobb23 Mar 7, 2025 •

edited

Loading