0

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.

The questions:

  1. Solhint has a warning of max-states-count of 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?
  2. 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?
  3. 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?
Improve this question
5
  • 1
    object oriented design is the best thing to do. using "central storage" like you say is not an option. later you will find yourself that you need to separate business logic of your app into different modules and you won't be able to do this with a single contract having it all
    – Nulik
    Feb 3 at 0:03
  • 1
    there is no limit on storage use, even if solidity starts to limit it to some number of variables you always can code in assembly and in assembly there is no limit for state variables. So your only limit is the price. You will run out of money faster than you fill all the storage. What they didn't tell you is that Ethereum platform is not a cryptocurrency but an expensive data-hosting platform ;)
    – Nulik
    Feb 3 at 0:05
  • @Nulik thanks for your reply! Regarding storage, I agree. that is very true. could you please elaborate on your first comment? I am planning to use a multi-implementation proxies, so that I can add logic to the module or remove it with ease. I also think I can always add new modules or separate functionality at any time. technically, this is not a single contract, it is just a single address. why won't I be able to separate logic later? I can move logic to a new contract with upgrades and connect them through addresses at any time, no?
    – Whytecrowe
    Feb 3 at 19:20
  • What I would recommend is to study complex projects (i.e their contracts directory) to get an idea how is functionality separated in different contracts/modules/libraries/interfaces/etc. I suggest Augur (v2) or Uniswap V3 (core + periphery), these are good starting points.
    – Nulik
    Feb 7 at 16:54
  • @Nulik I guess I wasn't clear in my questions, don't ask them here often. I've seen/analyzed many of these contracts and I know exactly what you mean. Some central registry is required to be the validator otherwise there's no point. But it can be simple while more specific modules will separate responsibility and other functions. I think, I've clarified the design. Thank you for taking the time!
    – Whytecrowe
    Feb 7 at 18:37

0

Reset to default

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.