Rationale

Messaging in zkSync uses two contracts: one deployed on L2 (implementing the IL2Messenger interface) and one deployed on L1 (implementing the IMailbox interface).

Messages coming in the direction L1 -> L2 are being payed for upon calling the Mailbox contract on L1. Validators take care that this message has been propagated and executed on L2.

Messages coming in the direction L2 -> L1 are only being included in a block and executing them is completely left on us. Their contracts only allow us to prove that a message, by checking against the keccak hash of the message bytes & merkle proof, was really sent from L2 to L1.

Before reading on, please take a look at the documentation of the Mailbox contract here https://era.zksync.io/docs/dev/developer-guides/system-contracts.html#mailboxfacet

Now, lets take a look at all the contracts/functionality we will need.

L1 Messenger Contract

This contract takes care of incoming messages from other rollups. It needs to communicate with the Mailbox contract of zkSync (on L1) in order to bridge a message from L1 to L2 (zkSync).

Here you can find the function (requestL2Transaction) that needs to be called on their Mailbox interface: https://github.com/matter-labs/era-contracts/blob/main/ethereum/contracts/zksync/interfaces/IMailbox.sol#L119-L127

Make sure you go through this documentation in order to understand how to prepare the values that you need to provide to the requestL2Transaction function call inside our contract.

This contract will need to pay for the L1 -> L2 message so make sure you implement a deposit/withdraw mechanism (check our ArbitrumL1Messenger).

L1 Prove & Execute contract

Since their L2 -> L1 messaging system doesn't execute the messages nor does it provide an interface for automatically proving & executing a message coming from L2, we need to take of this on our end.
We will need one more contract that acts as a message executor on L1 (https://era.zksync.io/docs/dev/developer-guides/bridging/l2-l1.html#example). This contract will be called by the relayer when an L1 resolution has been triggered.

L2 Messenger Contract

This contract takes care of messages coming from our FillManager on zkSync to L1. It needs to interact with a contract that implements their IL1Messenger interface. More specifically, it needs to call the sendToL1 function.

msg.sender Aliasing

Provided is an interface for aliasing addresses in both directions (L1 -> L2 & L2 -> L1).
It might be necessary to use this in our contracts in order to ensure the existence of our trusted call chain. Check our other messenger contracts and how they implement our RestrictedCalls interface to understand why this is important.