Okay thanks. This seems like something that could be easily optimised no? Instead of having a tonne of duplicated data that is both in the utxo db and blocks db. You could have each block, and each tx that tries to spend utxo's (instead of referencing a previous tx hash), references a block number and position in the block of the tx he is trying to spend. then the client finds the tx and position of the utxo inside the tx and checks the lockscript/unlockscript.
I might be wrong, but IMO Core dev chose
chainstate approach because :
1. Less information stored on transaction (which leads to slightly less transaction size)
2. Accessing
chainstate is faster than access block DB
This case is one of "time/space complexity" problem where you can't achieve both and Core dev chose better access time.