blockchainblocksreceiptstransactions
Reading through the Yellow paper, I can see that each block header includes the Keccak 256 hash of the root of the trie for transactions and transaction receipts. I am struggling to understand how and where they are created.
How are the Transactions Trie and the Transaction Receipts Trie related for a given block?
Is it the case that, as the world state is updated by going through the transactions, the transactions and transaction receipts are stored in their respective tries?
No, they are not the same thing. The Bloom filter in the transaction (R_b) contains only the logs from this transaction while the Bloom filter in the block header (H_b) contains the logs from all transactions in this block.
So yes, the information is stored twice, but with the benefit of being able to check quickly if a certain log is present in a block without having access to all transactions. This enables light clients (which only know block headers) to watch for events.
Firstly, you'll want to take a look at this picture from a previous question for reference.
Q1 - Where does geth stores these tries - I reckon within the block themselves, i.e. chaindata folder, within the ldb files? Or am I entirely off-base?
The chain data isn't actually part of the block proper - it's stored separately in a leveldb database. On your machine this is what's inside the chaindata folder. The block itself stores the hashes of the roots of the various tries, the state data (i.e. chain data) being one of these.
See:
Q2 - (I am assuming the state trie is indeed kept in each block) Does the state trie of block N references the state trie of block N-1 (if no changes to an account's state is found, i.e. only log accounts with differences), or is the state trie duplicated across blocks?
Your first assumption isn't correct, as per Q1, but yes, the state trie references backwards to prevent duplication. This picture from this previous answer helps visualise this:
Q3 - While state tree pruning, I reckon that the states are pruned off since if we have the stateRoot, this effectively verifies that the state trie nodes are OK, hence safe to discard the state trie themselves - Would this understanding be correct from high level perspective?
I'm not entirely sure, but this previous official blog post might help: https://blog.ethereum.org/2015/06/26/state-tree-pruning/
Q4 - What would the .\ethereum\nodes folder be for?
It's a database of nodes your node knows about. It's blobified in RLP format, so it's not readily readable. For further details, see Format of LevelDB files in nodes directory? Trouble pulling contents with python leveldb API
Best Answer
Transaction Tries and Transaction Receipt Tries are indeed independent data structures with distinct roots stored on the blockchain header and differ in both purpose and content.
Purpose:
Transaction Tries: records transaction request vectors
Transaction Receipt Tries: records the transaction outcome
Content:
Parameters used in composing a Transaction Trie [details in section 4.3 of the yellow paper]:
Parameters used in composing a Transaction Receipt Trie [details in section 4.4.1 of the yellow paper]: