One important thing to understand is that the challenge is less about storage capacity and more about database architecture. Most clients use LevelDB as the key-value database for storing state. LevelDB is quite efficient, and there are few viable alternatives.
LevelDB stores key-value pairs in read-only “level” files, organized by generation.
I won’t go too deep into the architecture of LevelDB, but the key point is that these level files are periodically compacted (i.e., merged). As the database grows, large files occasionally get compacted at random times. This can cause the database to stall intermittently. As a result, historical nodes with larger states and databases will fall behind regular nodes with smaller databases.
To solve this problem, clients will need to adopt a more advanced architecture, where LevelDB is split into multiple shards (e.g., by the first bytes of the key). If you use, say, 32 shards, then you can utilize 32 CPU cores in parallel, and each shard’s database will be 32 times smaller. Additionally, you can spread the data across multiple SSDs, improving read/write bandwidth by a factor of 32.
If LevelDB remains monolithic, then only a single core is utilized during database updates, and moving to a more powerful machine won’t help the historical node keep up.
So, the key point is that the challenge is not so much about storage requirements, but about re-architecting clients into a parallel, sharded database architecture — which is significantly more complex to engineer and QA.
Yes, but with unbounded state growth people have to buy new equipment regularly with no change to the gas limit.
This doesn’t solve state growth for the most important type of node oporater: RPC provider (ideally local). There are solutions to this like Portal Network, but it is unclear if that will work without incentives. There are incentivized designs that could work, but I don’t think anyone is working on them.
This assumes the relative gas usage of state vs compute remains constant at all price points, which I’m incredibly skeptical of. There are new state heavy use cases that open up once gas price is low enough (like Ethereum as a backup system or S3).
I think the key problem with almost all discussions on this topic in that they seem entirely focused on builders/stakers and everyone ignores the operators who I believe are by far the most important, which are RPC operators. We should be pushing hard to get regular users running their own trustless clients for answering RPC requests and those need fast random access to all state.
Things that reduce the state a builder or validator needs doesn’t help with this at all. While this is a solvable problem in theory, almost no solutions to the state problem or discussions of state growth even mention this class of operator. Solving decentralized state with unbounded growth in a way that gives usable response times for random access is a hard problem, and until that is solved we shouldn’t be seriously considering cranking up the state growth.
Get in touch with techspymax for all your hack related such as; Cloning, Tracking, Spying, Retrieving of deleted text messages, Upgrading of results, Hack social media accounts, Erase criminal record. His service is safe and secure. Get in touch with him via his email techspymax @ gma il co m
