thank you for replying.

i was talking about logical compression, for example there are too much repeating data on the blockchain. many things are pointed to each-other by hash (eg. txid), but you dont have to store all of the hash, you can give internal ids to things which are shorter. and while indexing by hash you dont need the full hash, you just need the shortest unique prefix of it. and since while searching by hash you give the full hash, you can re-validate it. so you dont have to store the full hash, and repeat it inside outputs. also you can give scriptPubKey(s) internal ids as well, so you dont repeat them if they are repeating on the blockchain.

also there are many compression methods that are designed to be fast. not to mention you can cache data for block ranges being accessed frequently. i can only compress the older blocks. and since compression is done on older blocks only, i dont have to worry about handling blockchain fork while giving internal ids. and many other compression techniques i cant think of atm.

if you don't add pruning, and have indexing enabled always, it takes less space than its being optional and enabled. since you don't have to repeat the data on the blockchain and the index separately in many cases.

also, im talking about a node designed for the end user, used by them only. so i can sacrifice some cpu time for, disk space. i think disk space is the biggest issue while running a full node as a normal person. occupied disk space is permanent. and bothers people more.

idk maybe im wrong, i will see when i try to run it with everything else i didnt mention here. worse case i learn stuff. but i will try to push for smaller blockchain as much as i can.