EIP-2535: Diamonds

[mudgen]

EIP-2535 Diamonds exists here: https://eips.ethereum.org/EIPS/eip-2535

Below is a feedback and discussion of the standard.

[androolloyd]

This is great.

Would be curious to see a uniswap build using the Diamond pattern.

[mudgen]

@androolloyd yes, me too!

[pi0neerpat]

I think you need to add the proper table to the top of this file. Wait, this is an issue not a PR. I'm confused are you trying to make a new EIP?

(Putting discussion here since I don't see an external link)

This looks interesting, albeit very ahead of it's time. You've clearly put a lot of thought into it, and it is very well written. I'm curious to see how this intersects with governance. My jerk reaction is that this is only useful in a specific application that includes permission-based "cut" control. But even that would introduce lots of systemic risk. For now I think we are all stuck with upgrades being controlled by a single source of control, like Maker and rDAI, which publish documentation to record the history of changes. I look forward to the day where this fine-grained control is reality, and small changes can be made on-the-fly without introducing additional risk!

Am I missing another use-case for this?

Edit: (follow-up) how can we isolate storage on the same permissioned system that we use to allow cuts?

[mudgen]

@pi0neerpat thanks for your kind comments! The discussion is here. An official EIP for this standard is coming soon. It will be EIP 2535.

Companies are already using this kind of architecture (ERC1538) for their contracts, such as Caesar's Triumph, Enjin and others. It is real and in use today.

Enjin's NFT standard EIP 1155 recommends using an architecture like ERC1538 for upgrades.

I don't know why you think a diamond can't be controlled by a single source. The reference implementation of the standard is implemented that way -- only the single owner of the diamond can make changes. Maybe I am understanding you wrong? Authentication is not part of the standard, it can be fine grained or not.

A big use case is contracts with designs that exceed the max size of contracts, since diamonds don't have a max size. It is also very nice that while diamonds can be large their functionality can still be compartmented by facets. Particularly NFT contracts tend to exceed the max size limit, such as implementations of ERC721 and ERC998 and others that implement an NFT but also need to implement custom functionality for the application.

Permissions and authentication for cuts and access to storage variables can be handled in the same way as any other contract. Yes, if you wanted to, you could add various different permissions/authentications for different changes and handling different storage variables. Or you could keep it simple and not do that.

[leonardoalt]

The owners(s) of an upgradeable contract have the ability to alter, add or remove data from the contract's data storage. Owner(s) of a contract can also execute any arbitrary code in the contract on behalf of any address. Owners(s) can do these things by adding a function to the contract that they call to execute arbitrary code. This is an issue for upgradeable contracts in general and is not specific to diamonds.

Well, exactly. How is this standard any different from the centralized owned upgradeable smart contracts out there? Why not a standard that abstracts upgrades being opt-in only by default?

[leonardoalt]

This is great.

Would be curious to see a uniswap build using the Diamond pattern.

To me Uniswap is great exactly because it's not upgradeable/centralized.

[mudgen]

@leonardoalt It is different in a lot of ways, but it is not different in regards to ownership/authentication. Ownership/authentication is not part of this standard. The ownership/authentication can be implemented in a diamond any way anybody wants.

I realize now that the way EIP-2535 Diamonds is currently written it misleads people into thinking that EIP-2535 Diamonds specifies how authentication/ownership is implemented or should work. It doesn't. So I think I will change the text you quoted because it is misleading. It certainly does not have to be that way, it just could be that way, depending on how ownership/authentication is implemented.

But note that the standard does suggest a different way to do ownership or authentication. See the "Decentralized Authority" section.

Also, the upgrade functionality can be removed in a diamond making a diamond immutable. This could be done by removing the cut function. And it possibly could be added back depending on certain cases dictated by the implementation of the diamond -- there are so many possibilities to what could be implemented and EIP-2535 Diamonds does not limit what can be done.

Why not a standard that abstracts upgrades being opt-in only by default?

Standards or tutorials or implementations that build on top of EIP-2535 Diamonds to provide different ownership/authentication/upgrade schemes are very much wanted!

EIP-2535 Diamonds provides basic architecture and structure and points of interoperability with user interfaces and software, and it leaves up to the implementer what the diamond does and how it works.

[pi0neerpat]

@mudgen

I don't know why you think a diamond can't be controlled by a single source.

The only reason I say this is because the single source would just publish documentation whenever they made a change. There's no real reason to emitt changes as events or capture this on-chain. Maker and other protocols already have governance processes to document this already.

A big use case is contracts with designs that exceed the max size of contracts, since diamonds don't have a max size.

That's a very good feature!

Companies are already using this kind of architecture (ERC1538) for their contracts, such as Caesar's Triumph, Enjin and others. It is real and in use today

I'll have to look more closely at these. This could be really useful for @austintgriffith DAOG game where the rules of the game are updated on-the-fly. Right now the rules are limited in scope, but this could allow more open-ended rules to be added or removed.

Permissions and authentication for cuts and access to storage variables can be handled in the same way as any other contract.

I'm glad you think this is possible because I really think this is the best potential use-case for this system. For instance, in the DAOG game, you could allow players to add/remove rules, without letting them interfere with the core game logic (i.e. the logic and storage deciding who wins and can withdraw the prize pot). Or with a Moloch, you could set certain thresholds for high/low impact changes to the dao contract itself. Dao members could pass smaller rules more easily, to run segregated and quick experiments, without risking the dao's funds.

[leonardoalt]

the upgrade functionality can be removed in a diamond making a diamond immutable.

The upgrade functionality can also be removed by the contract not being upgradeable in the first place.

there are so many possibilities to what could be implemented and the diamond standard does not limit what can be done

Exactly my point. It is basically a really complicated way to make contracts as mutable as simply delegating everything to a dynamic address, which is actually a lot more transparent and simpler to read and check what it's doing. Complicated upgrade standards enable backdoors by obfuscation, especially when you can literally change everything.

[mudgen]

@leonardoalt Its is really not very complicated. It is new and the standard does provide a lot of information to help use and implement the standard.

EIP-2535 Diamonds is this

1. One function for adding/replacing/removing functions.
2. One event for logging changes.
3. Some functions for showing what functions the contract has.

A big part of the standard is transparency (logging changes), which removes obfuscation. I plan to make a user interface that shows and visualizes all changes to a diamond.

[mudgen]

Some good discussion of EIP-2535 Diamonds here: https://ethereum-magicians.org/t/diamond-contract-standard/4038