Static Diamond Challenge
It is well known that EIP2535 Diamonds can be upgradeable.
However they can also be immutable and so have the same immutable guarantees as any other immutable contract.
The current implementations of EIP-2535 can be upgradeable or immutable. Making a diamond immutable is simply done by not adding the upgrade function `diamondCut` to the diamond during deployment, or removing it later if it is added.
EIP-2535 does not require a diamond to have the `diamondCut` function to comply with the standard. It is optional.
However it seems that it may be possible to create an implementation of EIP2535 that is immutable and without any option of upgrades. And does not use a Solidity mapping to map function selectors to facet addresses. This could possibly reduce the gas cost to call functions on a diamond. That is what this challenge is about.
Is it possible to create a viable immutable-only EIP2535 implementation?
By “viable” is meant these things:
Is the implementation simple enough?
Is the deployment and runtime gas costs the same or less than the current implementations?
Do you want to take the Static Diamond challenge and see what is possible? If so then try implementing this.
The existing EIP2535 diamond implementations use a Solidity mapping that maps selectors to facet addresses. Instead of doing that see if there is a relatively gas-efficient way to use a search algorithm instead.
Notice that a Solidity mapping is not required to comply with EIP-2535. The standard defines a mapping this way:
A mapping for the purposes of this EIP is an association between two things and does not refer to a specific implementation.
Note that any Static Diamond implementation must follow the EIP-2535 standard. That means the DiamondCut function needs to be emitted in the diamond proxy constructor to specify what functions and facets are used. The diamond needs to implement the four loupe functions.
Keep in mind that the four read-only loupe functions are meant to be called off-chain so their gas efficiency is not very important.
Perhaps some off-chain code could be written to automate the generation of hard coded selectors and facet addresses and generate Solidity code that is something like this: https://github.com/Synthetixio/synthetix-v3/tree/main/packages/hardhat-router#router-generation
Make a github repo with the implementation and invite me to take a look.
Resources to learn more about EIP-2535 can be found here: Awesome Diamonds
It is possible to create a viable immutable-only implementation of EIP-2535. In such an implementation, the diamondCut function would not be included, and the contract would be designed to be immutable and not capable of being upgraded.
To accomplish this, the contract would need to be designed to include all the necessary functions and data storage structures at the time of deployment. This would require a thorough understanding of the intended use cases for the contract and careful planning to ensure that all necessary functions and data structures are included.
Additionally, the contract could use a different approach for mapping function selectors to facet addresses. For example, instead of using a Solidity mapping, the contract could use an array or other data structure to store the mapping between function selectors and facet addresses. This could potentially reduce the gas cost of calling functions on the diamond.