I had some questions while writing up the above hackmd.
When the design talks about sequencers adding “System Transactions”, what happens if the sequencer lies and adds a System transaction that doesn’t exist. Or refuses to add a System transaction that should exist?
And similarly in the based rollup case: how do we ensure that the rollup full nodes are adding these inputs at the same rollup height? If different nodes add these deposit transactions at different heights, they will arrive at different app hashes.
I’m assuming that the deposit transactions are happening at the Celestia app layer, and they need to somehow be added into the rollup blockchain which is in the namespaced blob layer.
I ask because the design for IBC clients in the document makes use of these “System Transactions” to send authenticated IBC packet messages from Celestia to the rollup without the use of an independent relayer or even a light client of Celestia on the rollup. However, verifying the correctness of this approach requires more understanding of how these transactions get included into the rollup blockchain.
The proposal itself is described in the L1 to L2 state change description of the hackmd if you want to read and verify that I’m using the mechanism correctly.
Effectively, I’m replacing the “Deposit Tx” described here with IBC transactions sent from L1 → L2, which should hopefully make sense given their analogous function