For new transactions to be validated, nodes gotta do a few things:
1. track down where each input is coming from (like block:txid:vout),
2. find that output in the blockchain,
3. check every input in every transaction in all the blocks that come after to ensure it hasn’t been spent already.
3a. If it has been spent, just skip the signature check and toss the new transaction without spreading it.
3b. If it hasn't been spent, then verify the signature.
3b1. If the signature fails, drop the new transaction without spreading it.
3b2. If the signature checks out, then go ahead and propagate it.
Once a transaction is confirmed in a block, there’s no need to check signatures again, even for new nodes, so they don’t need to be stored.
Blocks just need to keep the output data and the path of the output being spent for each input.
You can’t just swap the input paths with hashes because if collisions happen, it could mess up valid outputs.
You can do that now in your own node. Merkle tree is constructed in a way, where you can discard transaction data, and keep only transaction IDs, if you want to.
Also, if you want to keep track of the UTXO set, then you can keep just "txid:vout", to uniquely identify each unspent coin.
The Merkle tree permits pruning, but doesn't improve TPS. It requires you to download full transaction data before pruning which is a waste of bandwidth. And VOUT is just an index value. OGH is a checksum.
If you want to improve TPS, then you have to combine N transactions into a single one, which would be smaller, and which would do the same thing, as uncompressed version would do. Some example: https://bitcointalk.org/index.php?topic=281848.0
That's why many scaling solutions are focused on pushing off-chain things, which are currently on-chain. If you have sidechains, you download only the end result, not all sidechain-related transactions during Initial Blockchain Download. The same with Lightning Network. And the same with cut-through.
If you want to change the format of things on-chain instead, then of course you can, but then, only nodes running your code will enforce such changes. For example: you can have a node, which will keep only transaction IDs, and nothing else. It will work, and it will be compatible with the rest of the network, because then you will build all merkle trees in the same way, as other nodes. Also, you can attach "output group hash" or whatever, but only your nodes will be aware of it, and only your nodes will validate it, the rest of the network will just never hear that kind of traffic at all.
Well, you can try to skip storing VOUT, but in many models, it is easier to keep it. But yes, if data behind OGH will contain it, then you can keep only transaction IDs, and check indexes later. However, in that case, you probably wouldn't need transaction IDs, if all data behind OGH will have everything you need.
Is it right to assume full node still need to store whole TX data or partial TX data (ones that contain UTXO) in order to verify all newer TX and block?
No. You can check less things, than existing nodes, and stay compatible with the rest of the network. For example: if some client would handle only P2PK, and would mark everything else as valid, then it would successfully synchronize the whole chain. The same is true for a client, which would check the correctness of the merkle tree construction, without checking any underlying transaction data.
Also, you don't need the full UTXO set to check, if new blocks are valid or not. Instead, clients could require ZK-proofs for each transaction input, and never store the history, but only the proof, that it is correct. Which means, that the full chain is required only in the current full node implementation, and it can be changed in the future.
The same is true about data compression: if you have weak public key, which is reused hundreds of times, then you don't have to send it over and over again. The protocol does not require anyone to do anything like that. The whole historical chain can for example be passed in much more compressed form than today, and such nodes can stay compatible with existing ones.
An extreme example is header-only client: you can trace only block headers, and not much more than that. Then, everything else you can handle through ZK-proofs or other kind of proofs, and still check, if new blocks are valid or not. Maybe even going further is possible, but each proof comes with some cryptographic assumptions, so storing all headers is highly recommended, as long as we don't have many billions of blocks.
So, to sum up: things can be simplified in future versions, without affecting existing implementations. Then, current node runners can still process and store hundreds of gigabytes, while new, more lightweight nodes can be set up successfully, and be more resistant to spam, or allow processing more transactions per second, while being compatible with the rest of the network.
No, because then, miners could steal it.
Imagine you have two groups of nodes: one, which confirmed Alice->Bob transaction in their chain, and another, which confirmed Alice->Charlie transaction in their chain. You have no access to any signatures, because they are discarded immediately. How do you know, which transaction is the real one? If you trust, that miners will never steal anything, and that signatures are not needed, then you don't have to use public key cryptography at all.
For example: you can lock your outputs on "OP_SIZE 32 OP_EQUALVERIFY OP_RIPEMD160 <yourHash> OP_EQUAL". Then, your private key is just a single 32-byte data push. No user will be able to move it upfront, because nobody would know the hash. And if you have existing public keys, then you can easily reuse them, by applying SHA-256 on them, and using that result as your private key.
So, you can already deploy your system on top of Bitcoin, or some test network, and see, how many coins will be stolen. Because nobody forces you to use OP_CHECKSIG, you can use any scripts without it, and that would also work.
What you are describing can be dome but that contradicts the trustless principle of Bitcoin.
In Bitcoin the idea is that a full node only trusts itself so it verifies everything, that includes signature verification. If you just trust the other nodes and PoW, then you can no longer call your client a full [verifying] node and you might as well run a SPV client (eg. Electrum) which is so much easier to sync and consumes less bandwidth and disk space.
I'm not saying we stop checking signatures. Only that they not be include in blocks, to save space. Signatures are big and excluding them would save a lot of space. The next block is only valid if it respects original transaction data, which nodes still have in their mempools, so I don't see how miners can steal anything. New nodes, or nodes that have been offline for a while, would only need to trust that the tip of the blockchain is as good without signatures as it is now, which it would be because the confirmation process isn't changed.
From the perspective of legacy node, Segwit doesn't exist. Which means, that you can strip all signatures from your own node, and stay on the same chain, but then, nobody would be able to sync his node through your connection (except also those, who will decide to trust you, and never check any signatures).
And it will require trusting, that all historical nodes processed the history correctly.
Because if you use legacy node, then it can potentially accept a block, which would spend Segwit inputs unconditionally. And the same is true for a node, which would strip signatures: it would accept a chain with Proof of Work, which would contain transactions without any signatures, moving coins, which never should be allowed to move from particular inputs.
And that assumption is quite big. Because then, why strip only signatures? You can strip much more. You can have transactions like that:
Because if you don't care about signatures, then why should you care about addresses and amounts? You can strip them too!
And then, address types, coin amounts, and many other things, can be put in a separate space, called "commitment space" or whatever, so your node could drop it instantly after checking.
There is an argument to be made that stripping signatures would make the transactions themselves impossible to verify, and would force software applications to collect entire blocks and verify those.
Storing the signatures ensures that nobody can find a vulnerability to manipulate the monetary supply in a way that other people cannot detect.