4

I assume, given the recent state clearing, that the Ethereum clients must only store the current state of each account as opposed to all historic state. (Otherwise, if it stored a record of all past states for each account, wouldn't it still be storing the 20,000,000 empty accounts?)

But, if the clients only store the current state, how do they efficiently report on past balances as they do under this RPC call (https://github.com/ethereum/wiki/blob/master/JSON-RPC.md#eth_getbalance) which takes an optional block height?

Do the clients spin through the list of all transactions to build past balances or do the clients actually store past balances? If they store past balances, do they store any other history per account?

Thomas Jay Rush
  • 9,943
  • 4
  • 31
  • 72
  • Related: http://ethereum.stackexchange.com/questions/1229/difference-between-a-pruned-and-unpruned-blockchain – eth Dec 07 '16 at 07:19
  • Very good. That explains some of it, but it doesn't answer the question. Interestingly, there is a comment of the bottom of the referenced post asking basically the identical question. How does eth_getBalance pick up historical balances if the client doesn't store historical state. I was surprised by that follow on question at the end of the referenced post. It's mine from a couple of months ago. – Thomas Jay Rush Dec 07 '16 at 13:42

1 Answers1

3

An Ethereum full node does store historic state. In fact, every block contains the root of the state tree, such that it "snapshots" the entire state every block. The reason this is isn't a gargantuan waste of space is that the Patricia trees can be easily combined over time. You can store the contract's code once, and every time it's referred to you can just reference it again.

The state cleaning was mostly for light nodes. If all you care about is what the state is now, there's no need to have the bloated states from before. For geth's fast sync and parity's warp sync, it's even more important that the state be small--otherwise, you'll have that much more to download. In addition, the larger the current state, the more resources a running full node consumes--itself a reason to clear the state.

Matthew Schmidt
  • 7,290
  • 1
  • 24
  • 35
  • Thanks. Now that you pointed me to is, it is well explained in section 4.1 of the Yellow Paper. There is 4 data items: nonce, balance, storageRoot, and codeHash. Is this why the clients can quickly return an account's balance and nonce and it's codeHash (but not the actual byte code), and storageRoot hash (but not the actual storage)? And is it further correct that because this all that's stored no such quick access to a list of an account's transactions is possible without spinning through the blocks searching for such transactions, or is there a shortcut to doing that as well? – Thomas Jay Rush Dec 08 '16 at 17:28
  • You can easily get the code--it's not that difficult for an implementation to make a hash-to-code mapping, and it's quite useful since contracts can also load each other's code. But there does not seem to be a shortcut for finding transactions from (let alone to, or internal transactions altogether.) – Matthew Schmidt Dec 08 '16 at 22:24