Are there any ideas that's potentially more useful than implementing sharding?

[JustinDrake]

@kladkogex

since the Merkle root is changed everytime there is a token transfer, I will have to update my witness everytime someone touches this ERC-20 contract - correct ?) So I will constantly have to monitor the ERC-20 contract then.

With the current trie accumulator, every time someones touches the ERC-20 contract the witness changes. The good news is that we have witness auto-updates (as discovered by Vitalik I think, see here) so users won’t have to make the most recent updates:

@vbuterin

we put the witness outside the signed data in the transaction, and allow the miner that includes the transaction to adjust the witness as needed before including the transaction. If miners maintain a policy of holding onto all new state tree nodes that were created in, say, the last 24 hours, then they will necessarily have all the needed info to update the Merkle branches for any transactions published in the last 24 hours.

(This was then improved slightly with account abstraction and miner data; see here.)

IMO at least as powerful as witness auto-updating are Merkle Mountain Ranges (see here and here). They offer the following amazing properties:

@justin

1. Low frequency updates—witnesses are updated log(#{updates after insertion}), as opposed to once per insertion for tries

2. Extend-only updates—the witnesses (Merkle paths) only get extended, as opposed to having internal nodes be modified from unrelated object updates in the trie (this is great for parallelism)

3. Marginal memory overhead—witness maintenance requires only log(#{objects}) overhead, as opposed to #{objects} overhead for tries

4. Shorter average-case witnesses—size log(#{updates after insertion}), as opposed to size log(#{objects}) for tries

5. Shorter worst-case witnesses—size log(#{updates after insertion}), as opposed to size #{objects} for tries