This PR aims to update the message rollback implementation in the L2ToL2CrossDomainMessenger to match new practices.
Additional Questions
There's a necessity to have a way for relayExpire to know that the message not only originated from L2ToL2CrossDomainMessenger, but that it also originated within sendExpire. This is to avoid someone from expiring arbitrary hashes by calling sendMessage in the L2ToL2CrossDomainMessenger and then relaying the message to relayExpire. A way to do this is by setting the senderin sendExpire to an impossible account. I chose the L2ToL2CrossDomainMessenger address itself.
I was wondering whether a random account would be better, like 0xdead. My worry comes because this allows the path where the message created in sendExpire is not sent to relayExpire but to relayMessage, which would set the sender to the L2ToL2CrossDomainMessenger, and perhaps this could mess with contracts integrating with it.
Description
This PR aims to update the message rollback implementation in the
L2ToL2CrossDomainMessengerto match new practices.Additional Questions
There's a necessity to have a way for
relayExpireto know that the message not only originated fromL2ToL2CrossDomainMessenger, but that it also originated withinsendExpire. This is to avoid someone from expiring arbitrary hashes by callingsendMessagein theL2ToL2CrossDomainMessengerand then relaying the message torelayExpire. A way to do this is by setting thesenderinsendExpireto an impossible account. I chose theL2ToL2CrossDomainMessengeraddress itself.I was wondering whether a random account would be better, like
0xdead. My worry comes because this allows the path where the message created insendExpireis not sent torelayExpirebut torelayMessage, which would set thesenderto theL2ToL2CrossDomainMessenger, and perhaps this could mess with contracts integrating with it.