Firstly, these diagrams are sensational.
Q1:
The diagram suggests a Public L2 Function cannot ‘write’ to the ‘L2 Message Box’. It’ll be useful for an Public L2 Function to be able to ‘call’ a Private L2 Function via some L2 message box. Further, it’d be useful if that message box can be written-to immediately, so that a tx within the same rollup (with an incremented user nonce to ensure the correct tx ordering) can execute the subsequent private tx which reads the message.
Q2:
When an L1 function makes an L1->L2 call, it’ll write to the L2 message box. This requires ‘work’ from the Sequencer of the next rollup (to actually write the message), so the Sequencer will need to be paid for this. How will the Sequencer be paid?
Suggestion: at the time of making the L1->L2 call, leave some L1 tokens in escrow for the Sequencer to collect if they successfully add the message. However, this might require an L1->L2 message tuple to include additional data field(s) which convey the fee being paid via L1.
Q3:
Related to Q2, when an L1->L2 call is made, and a message request is made (to ‘write’ a message to the L2 Message Box), will the Sequencer be forced to add the message in the next rollup, OR will the Sequencer have a choice over which messages to add, based on the fees being paid to them?
Q4:
Does the ordering of how messages are added to the L2 Message Box need to exactly match the ordering in which the original L1->L2 ‘message requests’ took place (FIFO), or will economics dictate the ordering? (And the same question for the other direction; L2->L1)
Q4.5:
Related to Q3&4, possible DoS attack. In a FIFO model, the L1->L2 message box only has so much capacity each rollup, because the Sequencer must execute a circuit which can only add so many new leaves to the message tree. DoS attack: if it’s cheap enough to send messages to the L1->L2 message box, someone could spam it, and no one else would be able to get their messages added. Basically, message box space is scarce, so might need to be bidded-for.
Q5 (not really a question)
Paying for L2->L1 messages. Clearly, an L2 tx which writes lots of L1 messages should pay more in L1 storage costs than a tx which doesn’t write any L1 messages. The cost of writing messages is denominated in ETH. So we still have the problem that when a user is estimating the fee they’ll need to pay to the Sequencer, the fee will need to consider variable ETH costs. No question really, just something to be aware of when estimating gas. We’ll already have the problem of needing to consider variable ETH costs for an L2->L1 call, since the number of nonzero commitments/nullifiers in ETH calldata will vary by user, and the ETH calldata costs of contract deployment will vary by contract.