Longs long solved problem. You only need to store the last state of the ledger and the chain of hashes that lead there to validate that any give block actually

Longs long solved problem. You only need to store the last state of the ledger and the chain of hashes that lead there to validate that any give block actually did happen. If you dont care about validating past block you dont even need the chain of hashes but just the last state. Instead of huge transaction chains to get to the balance people use snapshots where they basically sum up everything in the past to a give point in time and add new transaction from there on. More "modern" systems like the XRPL or ETH directly use accounts with balances. If you have the last state so all accounts and all balances you can move (subtract from one and add to the other) you dont have to sum past transaction to know if someone actually has a balance to move. You can also easily sum all balances which must give the total (if the supply is fixed). >"If you have a solution for this that does not require trusting anyone...." You do not need to trust anyone you need to trust EVERYONE at one point in time exactly when you want to join and use the system. If you decide to use for example the XRPL today maybe even run a node and validate transaction yourself, then at the time "now()" the last state that everyone else agrees on that is what you need to "trust" or rather accept. You need to accept that to this date the people who ran it before you didn't never collude to "fix" or manipulate the ledger state of the past. If you think they colluded in the past and the current state is not how it should be then the system is useless to you. It doesn't matter if you can point to the exact event in some historical data. And you dont need the historical data to know such an event happen because it obviously would be hugely controversial and well documented outside of the transaction history (probably would result in a fork etc. so you could pick the chain you agree on). If you are worried about a mistake in the past that no one even noticed then that is not a problem since by definition the code everyone runs is the rules. A bug is a bug in the rules and if everyone agrees on the current state it doesn't matter that something went wrong somewhere in the past, its only important that the current state is agreed on. If you assume the past is immutable then a past bug has no effect on the future function of the system (Exception ofc is when the past was changed then you need to assume that people collude again to do it again). People think the past is immutable if we have it recorded but actual it is immutable if there is agreement on the current states finality. Think of the whole system like a closed room with people who together hold a fix number of coins. Once everyone knows the balance of everyone and there is no dispute on the balances everyone can transact with everyone. There is zero need to know the past transactions that took place. If someone has 5 coins he can give you 3 and everyone sees that he now has 2 and you 3 more. If a new person enters the room he must have zero coins else the total increased. He can then instantly accept coins from anyone once he know the current undisputed balances of everyone. Again he does not need to know from whom you got your coins just that everyone agrees that you own them.