Answering Some Diamond Questions

Why use Diamond instead of some other proxy pattern?

The reason to use a Diamond instead of a different proxy pattern is because a diamond can do some things that other proxy patterns cannot.

• Specifically a Diamonds enables you to have unlimited smart contract functionality at a single Ethereum address, bypassing the 24KB smart contract size limit. So if you want more functionality at an Ethereum address than can fit in a single contract then use a Diamond.

• A Diamond enables a project to develop and deploy incrementally without hitting a contract size limitation. In other proxy patterns you can upgrade the implementation contract to add new functionality but eventually the proxy pattern will hit the max contract size limit. A Diamond let's a project deploy something useful and extend the diamond over time in a standard and organized way.

Instead of using EIP-2535 why not use deployed Solidity libraries?

That is what EIP-2535 is doing but it is an established, organized and standardized approach for doing that which provides optional upgradeability, efficiency, transparency, interoperability and tooling. The facets of the diamond can be smart contract which are used like deployed Solidity libraries. Or the facets of a diamond can be actual deployed Solidity libraries.

Pros and cons of using a Diamond

Pros:

• Unlimited smart contract functionality at a single Ethereum address. This is useful for organizing a larger smart contract code base and integrating with user interfaces and other smart contract systems and 3rd party projects.

• Fine-grained and incremental upgrades. With a Diamond you can just upgrade the parts that need to be upgraded and leave the other parts alone, instead of having to redeploy everything.

• The capability to create independent, reusable deployed smart contracts. This is a level of modularity that did not exist before.

• Introspection and transparency of a smart contract system (a Diamond) with its loupe functions. The louper.dev user interface uses this capability to show and use diamond functionality.

• A Diamond provides an organized way to extend a smart contract system after it has been deployed.

• Joining a group of enthusiastic and experienced smart smart contract developers.

Cons:

• OpenZeppelin contracts do not currently work with diamonds. But this is changing because OpenZeppelin plans to use Diamond Storage in its next major version. Diamond Storage is a technique for organizing and managing state variables, particularly in upgradeable contracts. Note that OpenZeppelin Solidity libraries do work in Diamonds. Other smart contract libraries such as solidstate-solidity and ERC721A-Upgradable can be used with diamonds.

• Learning curve to understand the Diamonds standard and Solidity techniques that are used.

typical workflow of what to do when

Diamonds is a flexible and general purpose solution to implement many kinds of smart contracts. Many projects start with a reference implementation and build on top of that or from there. Here is such a reference implementation: diamond-1-hardhat.

costs of using Diamond (like cons): gas costs, complexity

Gas cost: The runtime gas cost to call functions on a diamond is about the same as other proxy contract patterns. Sometimes a diamond can reduce runtime gas costs in larger systems because it can share internal functions between its internal contracts (called facets) and use other techniques. More information about gas costs of diamonds is in an article here.

Complexity cost: A single diamond has multiple implementation contracts called facets. The facets can be isolated and independent from each other, in which case you can manage and think of each facet separately, which can reduce complexity. However it is possible to implement facets in a way that they share state variables between each other, in which case facets can affect each other and you need to think of and manage the facets together to the degree that they are integrated.

all this could be exemplified with a simple project with/without Diamond. To me, it is a crucial decision to go with some proxy pattern and I'd have to be able to evaluate the risks and chances.

Diamonds are useful for organizing larger projects which may not be considered simple because of the larger code base. To give an example of how a diamond can organize a code base, checkout the "Facets" documentation for the Aavegotchi project here: https://docs.aavegotchi.com/overview/facets