Many people look at storage protocols, focusing only on throughput and latency. But I think the truly core aspect, and what everyone has misunderstood, is not the performance data itself, but whether you still have room to make changes later on.

Early-stage projects are like this: launch first, then worry about everything else—it's enough that it runs. Then gradually optimize, and handle historical issues later. It sounds reasonable, but once your user base, asset scale, and content volume start to snowball, you'll find yourself in trouble.

Why? Because you simply can't move. Want to change the data structure? No way, it would break the entire trust chain. Need to refactor the core logic? Even less daring, the risk is too high. Want to clean up some historical redundant data? That's an even bigger nightmare—affecting everything.

This is where a key design difference appears. The traditional approach is to overwrite objects—new states erase old states. But some protocols think of objects as evolving—new states are built on top of previous states, forming a continuous version chain.

This may sound like a technical detail, but it actually directly changes how you manage your project's lifecycle. For example, an active daily application updating its state five times a day would have 1,800 version evolutions in a year. Most system frameworks start to become rigid and performance degrades after about 200 modifications. But if the system is designed from the start to handle this high-frequency evolution scale, the results are completely different.

So my current view is: these storage schemes are not at all designed for new projects. Instead, they are meant for projects that want to take a long-term approach and need to remain flexible as users and assets continue to grow.