While architecting a smart contract system, which is expected to grow to a large size and be highly scalable, the question arose to use a central module with storage and functionality set in one place vs scattering different modules and storages around to separate each node's management and responsibility.
The main questions are about storage of all possible names and their respective data. If I were to design a system with one central storage for all data, how soon we can possibly run into problems? Consider this for mapping type storage that is independent of the amount of values.
- Solhint has a warning of
max-states-countof 15 state vars. This just seems as a part of "good practice", but does it actually have a big effect on scalability or system robustness? What if we, after upgrades, end up with 20/30/50 slots on the same address? How bad can this be and what kind of problems might arise? Any other things that need to be taken into account here?
- Knowing that the possible theoretical limit of smart contract storage memory is somewhere around 2^256 * 32 bytes, this seems that running out of memory with even a large storage structure is not very likely, is this actually the case in reality?
- What are the downsides of using multi-implementation proxies (similar to diamonds, but simpler in implementation) with wide functionality and large storage, unified to a single address and easy to manage and traverse, vs potentially millions of scattered smart contracts with separated responsibility, functionality and storages?