feat: l2tol2cdm RelayedMessage return value #227
Conversation
hamdiallam
changed the title
|
This is missing the resource usage section. How will this impact the happy path (no returndata) vs worst case (returndata bomb) in gas costs and database size? |
| - Bridge Funds | ||
| - Invoke calldata on via a remotely controlled proxy account | ||
|
|
||
| Read-based cross chain messages are less common but will increasingly become so in an asynchronous world. Solidity has a `view` modifier specifically targeted for reading -- it would be natural to also want to also query this state onchain very quickly. |
There was a problem hiding this comment.
For some usecases, its not safe to read remote data without knowing the timestamp of the read. You could be tricked into reading stale data. Is there an easy way to see the timestamp of the read?
There was a problem hiding this comment.
Identifier of the remote log plays in nicely here. The consumer on the source chain can choose to reject at whatever latency, the RelayedMessage event if the timestamp of the event is stale
Nothing needs to change on the destination.
|
I recommend adding the table to the header that was recently added to the template: https://github.com/ethereum-optimism/design-docs/blob/main/assets/design-doc-template.md#project-name-design-doc |
ah good catch, let me add this |
|
|
||
| ### Single Point of Failure and Multi Client Considerations | ||
|
|
||
| N/A as this is a smart contract change. |
There was a problem hiding this comment.
Our smart contracts are a single point of failure. Sometimes it just isn't possible to get away from a single point of failure, but we should generally strive to be aware of the single points of failure and architect away as many as possible. It would still be good to consider this section. One consideration could be the tradeoff between adding a ton of stuff into the messenger vs not and keeping it simple. It is permissionless to build a cross domain messenger with arbitrary features that isn't part of the predeploys. This is just the one that we maintain. So backwards compatibility with any change is a big consideration with this change. The event identifier changes, so it will break backwards compatibility with the existing relayers. Which is ok, could be good to note down
| } | ||
| ``` | ||
|
|
||
| The `messageHash` known ahead of time can be correlated with the corresponding `RelayedMessage`. Thus the return value of any read function or return value of a write call becomes immediately actionable for the sender, without requiring special integration. |
There was a problem hiding this comment.
In order to read/validate the RelayedMessage, the identifier of the RelayedMessage is a requirement.
Wouldn't an integration be required for constructing the identifier of the RelayedMessage since you cannot calculate the identifier ahead of time?
There was a problem hiding this comment.
by ahead of time here, I meant with the return value of sendMessage, the message hash. You can directly chain the continuation since the caller just needs to assert the msg hash matches with the RelayedMessage event.
I'll make this a bit more clear
There was a problem hiding this comment.
I was referring to the message identifier not being able to be calculated ahead of time and not the message hash. The identifier is needed in order to trigger the continuation, right?
There was a problem hiding this comment.
yea after relay is when the continuation would be invoked. you need the return value
the identifier isnt computed ahead of time. It can just be consumed right away after emission
There was a problem hiding this comment.
Yeah and so that identifier and message will need to be fetched or indexed offchain. Do you see this requiring some additional offchain infra to find and “relay” these events back to the source chain? Relay in quotes because it’s not a relay using relayMessage, but you need to have some service that fetches that event and then triggers the continuation on the source chain.
There was a problem hiding this comment.
yep, we'll definitely need indexing of pending promises that relayers will have to handle separately. Especially now that the data is hashed.
This plays in nicely for protocols that have to propagate the return data backwards, which incurs extra gas cost
|
We generally have consensus on this approach, but will add the hash of the returndata to the event rather than the full returndata itself. The returndata can be unwrapped on the originating chain. The reason that the hash is used is to make the costs more constant, reducing risk for paying a relayer on the local chain for their execution on the remote chain. There is a concern that extra data needs to be posted to the calldata, which puts pressure on DA. This is a valid concern, if its abi encoded returndata, then it likely compresses pretty well, but ultimately depends on the returndata itself |
Description
Increase leverage of the L2ToL2CDM by including the return value in the RelayedMessage event