@mihaic195 thanks for that data. That helps me understand what you are building and some of the design of it.
But I don’t have enough details to know how these things were a challenge:
Why were these challenges? Can you tell the details of what you ran into exactly which was a challenge?
Why were these challenges? Can you tell the details of what you ran into exactly which was a challenge?
We have two versions, each with 10 facets and sharing multiple diamond storages. Upgrading or migrating storage can be difficult without some proper conventions.
I really like what you did with the Compose project! From a behavior perspective, the implementation is very similar: Facets implement logic, and deployed proxies can reuse that logic. The storage layout of the facets runs in the context of the deployed proxies.
Agree on versioning. had to develop internal tooling (both typescriot and solidity) to manage it
Yes, to properly add more storage variables to diamond storage structs in upgrades requires knowledge of how Solidity lays out storage variables, or knowledge of diamond storage upgrade rules (which I think you already figured out, but mentioning for passing readers). I wrote rules of struct upgrades here: Diamond Upgrades - by Nick Mudge 💎 - EIP-2535 Diamonds
I actually no longer recommend that people add new storage variables to existing diamond storage structs in upgrades. It can be simpler to just create a new diamond storage struct with the new storage variables that are wanted, even if it just one new variable. That way developers don’t have to know storage layout or upgrade rules (to some degree), and in addition they can create a sort of documented history of storage variables added over time within the code itself. A convention of diamond storage identifier names could be used with this method to more clearly and systematically show the evolution of diamond storage, but I think that such conventions should be in new standards or documentation.
I agree that the area of versioning of facets, which includes potentially different diamond storage structs, is an area to address to create conventions, systems of organization and tooling. Diamond storage identifiers are a big part of that, but to keep this standard (ERC-8042) simple and focused I would like to focus it on just what it is generally, and then new standards, conventions and tools etc. can build off of it, and narrow it down.
I really like what you did with the Compose project! From a behavior perspective, the implementation is very similar: Facets implement logic, and deployed proxies can reuse that logic. The storage layout of the facets runs in the context of the deployed proxies.
That’s awesome, and make sense!
ERC-8042: Diamond Storage is now a published ERC draft: ERC-8042: Diamond Storage
ERC-8042 Diamond Storage has moved to Last Call status: ERC-8042: Diamond Storage
I support this. My only nit would be I think diamond storage is a confusing term unless you know the historical reference. I would prefer:
@adraffy I understand. The “named” and “namedspace names” are good, but already taken by ERC-7201 Namespaced Storage Layout, and the name of this standard needs to be different enough so the two names don’t get confused.
ERC-8042 Diamond Storage became Final today: ERC-8042: Diamond Storage