docs: New CrossChain Message model

[LHerskind]

Based on gas computations for the current message model, it was decided that it is too expensive for the improvement in Devex that it brought.

Namely, the fraction of the cost that had to be incurred during the validation phase put a limiter on the size of individual blocks since the cost was dependent on the number of messages.

The new proposal is at a high level, adding more trees, and then only moving a root across as part of the block validation itself. This means that the gas costs incurred in validation is constant. This gives us the benefits of:

• Removing some constraints on the block sizes
• Remove a fee market for incoming messages
• Improving censorship resistance for cross-chain messages
  Those don't come entirely for free though, as:
• The circuits need to perform additional hashing
• Consumption of messages (L2 -> L1 messages) need to provide a membership proof. This membership proof require that user is reading events/DA and rebuilds the tree or a frontend does so. This tree have no private information so can be built by anyone.

The benefits outweigh the negatives.

Implementation wise, the inbox becomes a series of frontier-merkle trees (storage-optimized merkle tree). While the outbox is pretty standard merkle inclusion and nullifier tracking.

[iAmMichaelConnor]

It still makes me uneasy (in the new model) that when a user sends an L1->L2 message, they are not paying for the costs associated with inserting that message into the L1->L2 mesage tree on L2. Instead, the transactors in the next rollup block are effectively covering this cost. I don't have a feel for the concrete marginal costs that each additional L1->L2 message imposes on the next sequencer.

It feels like how our generation is paying the pensions of the older generation. And that isn't going well.

[LHerskind]

they are not paying for the costs associated with inserting that message into the L1->L2 mesage tree on L2.

The fee market would be such a pain. Especially as the act or paying the fee on L1, would likely be more expensive than the actual fee.

The remedy is worse than the disease.

I don't have a feel for the concrete marginal costs that each additional L1->L2 message imposes on the next sequencer.

From some of the napkin math Joe and I did ~7 sha hashes per base -> 1 second in proving time. And then 1 extra in the merges etc.

[iAmMichaelConnor]

hashes per base

I'd still like to compare two approaches:

• Doing these l1_to_l2_message leaf insertions in the base rollup circuits; vs
• Doing these l1_to_l2_message leaf insertions in a standalone circuit which feeds into the root_rollup circuit. It's possible to do this and still make all of the l1_to_l2_messages available to all txs in the block.

I prefer the latter approach. It's a better separation of concerns. The base rollup circuit should only be concerned with logic relating to the one tx being added to the rollup. The number of l1_to_l2_messages is unrelated to the number of txs in a block. So there will either be redundant hashing if # messages < # txs (and I know we'll be parallelising base rollups, but it's still redundant hashing). Or if # messages > # txs, then there won't be enough base rollup instances to insert all messages.

With a standalone circuit, it can specialise in just doing merkle tree insertions. Deciding who generates that proof and who gets paid is an out-of-protocol concern, just like deciding who generates the proof for the root_rollup circuit.