ERC-8109: Diamonds, Simplified

[mudgen]

@maxnorm

Fair point! Only deploying one contract with all the selectors with the one that modified make sense but the deployment with still cost more than only deploying a facet with the selector that need changes.

Indeed, you are correct.

@maxnorm

Imo, this approach still seem to break the on-chain reusability and the part to avoid redeploying already deployed logics blocks.

Yes, you are right.

@maxnorm

I like the idea. I agree that it’s simplifying a lot, but with a major downside from the original diamond proposition.

The lost in flexibility is my major concern with this approach. I’ll like to more of the implementation to have a better view on this.

Yes, you are right. There are upsides and downsides to this approach.

There are additional upsides to the facet-based approach:

1. It allows you to control the granularity of logic blocks. With the selector-based approach the granularity is functions. With the facet-based approach the granularity can be small facets, or large facets, or a mix between them, or it can be functions, by deploying each function as a separate facet.

2. In my past experience of people working on diamond projects, they tended to think and work at the facet level, and not at the function level. So I think working at the facet level is already what many people would tend to do.

3. It will be easier for tooling to work with facet-based diamonds because tooling won’t have to figure out (as much) which functions in facets are actually used in diamonds, since they all are (mostly). For example, currently, some block explorers may show all functions from all facets in a diamond, when displaying a diamond, even if the diamond doesn’t actually have some of the functions. This is of course wrong, but would be right if the diamond was facet-based.

4. Facet-based diamonds will match the verified source code of the facets used in the diamond. For example if 10 facets are added to the diamond and only some of the functions of each facet are added to the diamond, then the source code for each facets doesn’t match the functionality in the diamond since the diamond only has some of the functions. If the source of all the facets matches the functionality in the diamond, it is easier to read and understand the source code for the diamond.

By the way, ERC-8109 is not facet based, and I am no longer planning to make it facet based. ERC-8109 is a base ERC that standardizes terminology, events and introspection for tooling.

But I am planning to make a new standard, built on ERC-8109, that is facet based, adds an introspection function to facets and an optional upgradeDiamonds function.

The lost in flexibility is my major concern with this approach. I’ll like to more of the implementation to have a better view on this.

Great, I am currently working on a facet-based implementation.