Would you be able to comment on the criticisms of SMTs mentioned in this article: https://hackernoon.com/everything-you-didnt-know-about-the-handshake-naming-system-how-this-blockchain-project-will-483464309f33
It was extremely slow in terms of disk I/O and CPU cycles. To insert 5000 leaves, you would have to do a million rounds of hashing, or something insane. That’s fine if you’re storing certificate revocation lists because it doesn’t get updated that frequently. But if you have a blockchain which makes frequent updates to the tree, it’s sort of a bad solution.
… Eventually, you’ll put too much heat on the garbage collector, garbage collection pauses, and it starts getting noticeable. Generally, it’s good practice not to put that much stuff in memory. With the SMT, you need to keep an insane amount of stuff in memory just to make the lookups fast.
I’m curious if these are shortcomings to all SMTs (I believe the multiple hashing for writes is), or whether some of these observations are specific to the implementation they tested, and might be mitigated with clever optimizations, such as those described here: https://ethresear.ch/t/optimizing-sparse-merkle-trees/3751/5