How Ethereum state tree is formed?

Question

As we know each block contains a state-root. Following image is taken from https://blog.ethereum.org/2015/11/15/merkling-in-ethereum/.

Ethereum Wiki:

Constant light client reference: light clients can at any point access all data related to an account by scanning down the state tree in a specific direction.

I am confused related to storage of the state-tree and its access. As I understand: there is only one state, transaction and receipt tree. Since there is one, the tree should be somehow updated at each epoch.

As I understand global state-tree is updated on each block and all clients have access to a single state-tree where latest key/value information is stored.

[Q1] If the state-trie is updated how can we know each accounts balances on previous blocks? What is the algorithm that updates the state-trie at each block.

On this Q's answer, it confirms that I can retrieve any account's balance based on any given block number. web3.eth.getBalance(address, 100).

[q2] If there is no transaction occur at a block how its state-root is updated on the next block? As I understand state-root is dependent on the key/value that is stores. If there is no update any of them, how state-root is able to change?

Thank you for your valuable time and help.

Answer 1

[Q1]

Records in the state trie can exist independently of the state root that references them. Each node is stored in what is essentially a flat hashmap, and nodes have references to allow them to look up their children in the hashmap.

In your example, block 175,223's state root has a reference to two child nodes. Block 175,224's state root has a reference to one of the same children as block 175,223 and one new child that wasn't referenced by any prior state root.

In general, once 175,224 is the latest block we don't care about any records in the state trie other than those referenced by block 175,224's state root, but that doesn't mean we remove the entries from the hashmap where we're storing all the nodes. If we go back to the state root from block 175,223 it still has references to the same entries in the hashmap, and those entries are still present in the hashmap, allowing us to look up values as they existed in the state trie for block 175,223.

It's worth noting that if you do a fast sync or prune your state trie, you might only have the state trie as it exists at block 175,224 and your hashmap might be missing records that are referenced by the state root of block 175,223. The Ethereum network protocol accounts for this and is able to request those missing records from your peers, so even if the only thing you have for a given block is the block header with the state root, when a peer sends you the missing values you asked for you can verify that they are the correct values given the state root. Obviously having the data on your local copy of the trie is faster, but even if you're using a pruned trie you can get the data you need from the network and verify it against the state roots.

[Q2]

Even if a block is mined with 0 transactions, the miner gets a block reward which modifies the state trie, and thus modifies the state root. If that weren't the case, it might be plausible for two consecutive blocks to have identicial state roots, but I don't think that would actually be a problem.