Multiple block creators publish block-approval-blocks for their own created blocks. While they are sent to all the nodes, block-approval-blocks are not stored themselves in the chain, their contents are.

Conflicting block approval is detected by looking at all block-approval-blocks published on the network in the same slots. It is the next block creator's responsibility to check for these conflicts and not use contents of a block-approval-block that contains such a conflict. In addition, the approvers for the next block will also check for these conflicts and would not approve blocks that contains a conflicting approval from the previous slot.

The punishment for a conflicting-approver is that they do not earn approval award since their approvals do not go in the chain.

Once there is >50% stake approval on a successor block, there can only be one and only one predecessor block under the honest majority stake assumption even with network outage. If in case a block cannot receive >50% approval, then no new blocks will get published. Those slots will go empty until a >50% approval is achieved.

The protocol achieves finality after 1 block - not instant finality. PBFT and related protocols that build consensus on transaction level and publish a single block per slot have the real instant finality.

This near instant finality helps with Bribe attack but not with History (aka Costless Simulation) attack. It is because the "finality" is in the short timespans where the stakes of the parties have not changed dramatically. History attack, on the other hand, is powered by dramatic stake changes which can only occur in the longer timespans.