Block Production Timing and Dependency?

Quick question about block production and inter-node dependancy.

Imagine two block producing nodes A and B.

The time is currently slot 10 (let’s assume no block was produced and all nodes are sync’d)
A is scheduled to produce a block at slot 11
B is scheduled to produce a block at slot 12

If it takes longer than slot-time for A to produce a block, is B still able to produce a valid block?

Put another way: Does B depend on seeing A’s block to be able to produce B’s block?

Guess: I have to assume there’s some dependency here as B might try to include transactions in B’s block that have already been included in A’s block without B’s knowledge.

If this dependency exists, I’m not sure what the delay parameter allows. (how late you can receive a block) – since there seems to be an ordering requirement for the block producers.

B does not depend on A’s block at all. If B sees it, B can build its block on top of A. If it doesn’t, B will build off whatever its current best tip is- the block on slot 10. When B builds it block at time 12, it will consult its current transaction pool to figure out what to include. It won’t include transactions that aren’t valid when applied to its best tip. When the pools are synced generally you won’t have transactions in blocks that you don’t expect, although it’s certainly possible for someone else to make a block using transactions you never heard about.

We currently start proposing at the beginning of a slot, so if A takes too long this leads to a short fork. Without empty slots where the proposer isn’t running, these short forks can become quite long. There’s a sort of “ladder” that builds the two forks if you plot out the transition frontier over time…

If A is able to determine that it cannot emit a block within the given slot time, should it instead void the local block and not transmit it at all? Do we do this? (maybe also accounting for gossip overhead?)

We don’t do this. We possibly could. I am not sure there is any difference in consensus for that block to never be produced vs be consistently produced after all the other proposers have started.

My thought was that it’s a condition which could create a short term fork.

Node C hears about block A before block B conflicts with block A.

It seems it would be better to NOT spread potentially bad information.

It will lead to a short fork. If A’s block is proposed late, it might become the best tip only to be supplanted as soon as the current slot leaders produce their block. Nobody will build on top of A’s block (except maybe A), so the fork should naturally die, wasting A’s effort.