In a rollup, by default, you have neither tez account nor tickets.
A rollup is a child chain that can process what one will code in its kernel. L1/L2 communication via inbox/outbox is only bytes.
The kernel can be design for one specific app (app chain model) or can be a smart contract VM: there is currently teams working on EVM Rollup & Michelson Rollup
Tickets are a way to manage assets promoted because it represents a right on an assets with strong invariants provided by Tezos. So developping a kernel with a ticket ledger avoid some complications of classical two-way bridges.
One could even develop an account model in its kernel. This is not mandatory and a rollup developer decides its asset model. Rollups kernels are unopiniated.
For writing in inbox or outbox, one pays for XTZ fees in L1.
There is nothing implemented for L2 fees, the rollup creator decides and develops its fees model, if any.
It is important to understand that Smart Rollup (aka SORU) is a solution to design permissionless & censorship resistant rollup. It is not a specific implementation of a rollup (unlike TORU or competitor rollups)
If I run for example 1000 rollups that run 1000 TPS - the rollups are sending TXN´s between each others.
There is currently no L2-L2 communication. 1MTPS assumes there is no dependencies between the transactions on different rollups (parallel computing) or that they are aggregated in L1 (map/reduce computing)