Merkle tree state compression algorithm idea

The idea for state compression is to condense a sequence of merkle tree modifications where each value is modified once or more to a block where each item is only ever modified once - or, when the before and after merkle tree hashes are known for a sequence of operations, then any operation which takes the same state and produces the existing new state using fewer operations can be used to replace that data.

For merkle tree modifications, a program which can provide a sequence of merkle tree updates from an existing root to a new value where each account is only ever updated once, for example - if Bob sends 8 transactions to Alice, the block could be condensed into the difference of Bob and Alice's balances without needing to perform the application logic for the all transactions.

Example

before_balances = copy(balances)
for tx in transactions:
    balances[tx.from] -= tx.amount
    balances[tx.to] -= tx.amount

# Display delta from Before -> After transactions
for acct, balance in balances.items():
    print(acct, balance - before_balances[account])

Using verifiable computation it's possible to modify history and potentially discard transactions without needing recursive snarks. Functions can be created which take two or more previous state transitions and condense them into one - discarding making proofs O(1) relative to the number of transactions - and the only public information necessary is 'from state A, these keys were set to these values, the resulting merkle root is B'.

An unusual feature of this structure is that if you have two trust points, A and Z, data can be deleted during history compression. For example, if you have snapshots of the trust points (A and Z), and only know the merkle-root of B .. Y; then I show a zkSNARK proof of 'update merkle tree A -> Z' and provide you with the new values of each leaf modified by the update then you can delete all data about B .. Y.

As a result the current snapshot is the leaf value of every item in the tree and the number of items. If every merkle-tree update proof costs 20,000 constraints then that's 2m constraints per 100 updates, 20m per 1000, 200m per 10k etc.