> The clients can monitor the ledger via consistency proots and it is highly beneficial as that prevents any chances of split being undetected view without requiring to trust other parties in the process. Clients submiting the record to the chain they can get inclusion proofs, but they can also at random times can query that the previous chain root commitment is consistent with existing one in the process keeping consistency proof chain.

The design you're describing doesn't have those security properties.

A malicious or compromised Log conducts a split-view attack by showing different views of the Log to different parties. This is done by providing different parties with different inclusion proofs and consistency proofs. Thus the Log remains consistent from the respective network vantage points of the target(s). They all see an append-only log.

A Client or Monitor shouldn't merely be concerned with whether the Log is consistent from their vantage point. It should be concerned with whether the Log is globally consistent, i.e. whether all views of the Log are consistent with each other. Historically this has led to designs where the Clients gossip consistency information to each other, the introduction of Log Auditors and witness cosigning. I prefer witness cosigning, although to be fair Clients gossiping can work in some designs. Apple's transparency log design is one example, if I remember correctly. It's been a while since I thought about transparency logs.