“finality” is usually used in the context of trustlessness, so option (a) offers no finality. We can’t really formally distinguish between “L2 finality degrees”, because it is eventually completely up to the operator. I will try to respond with respect to the current implementation of our (centralized) sequencer:
- When a block appears as pending, it will be proved on L1 (up to L1 reorgs).
- Transactions that appear as part of the next block (block hash “pending”) will be part of the next block (up to L1 reorgs and internal errors in our batcher).
The above holds for a sequencer that executes our particular code. In the decentralized phase, where many sequencers operate simultaneously, the above makes no sense and the notion of L2 blocks loses meaning (to see why, consider the naive mechanism which allows the first sequencer that generates a proof to submit a block, then only one L2 block among all the operating sequencers will eventually be part of the canonical chain, so no notion of finality whatsoever).
In the long run, work towards intermediate degrees of finality (with the motivation of reducing latency) is twofold. First, direct work towards decreasing latency by optimizing proof time. Second, designing a protocol whose participants are the different sequencers where the goal is to reach a consensus over the next checkpoint. The latter checkpoint’s finality degree depends on the concrete design. One example would be to publish the checkpoint on L1 and have the StarkNet contract only allow updates that match the latest checkpoint (note that this must involve some checkpoint revert mechanism, and an additional mechanism of choosing the next checkpoint, otherwise the system is completely open to dos attacks).