you mention bedrock-style rollups and it looks like you can just query for the latest L1 blockhash in the L1Block contract linked here: Differences between Ethereum and Optimism | Optimism Docs
instead of needing to include an on-chain light client (and moreover prove/verify a SNARK of the transition), you can just prove whatever source rollup state this way blockhash->state root->source rollup contract->source rollup storage key(s)
it seems like if you go this route you don’t even need any relay actor…
the downside here is that you have to wait for the next L1 block and we may want to message cross-rollup regardless of the L1 activity – here we could explore having on-chain light clients where the source rollup and destination rollup are light clients of each other
this is basically the IBC construction from cosmos but again if you are just trusting an honest majority of a committee, we have a relatively weak trust model as corruption of that committee means authorization of arbitrary messages that seem to be coming from the source rollup – to get around this, we need some kind of fault proving scheme, e.g. optimistic or validity proofs run inside the rollup