EIP 2535 aka ‘the Diamond Standard’
Ever heard about EIP 2535? Many projects are using it under the hood these days. Surprised right? I have had my fair share of time spent on projects where I made use of this idea for granted, as I have scaled applications on this very idea of “proxified” approach. Many still scratch their heads when they hear the word ‘Diamond standard’. Why would you even need this Diamond Standard? What are the few best possible scenarios where diamonds really help you scale up the architecture? Let’s put it into super simple words. Fewer jargons, more intuition. let’s get into it!
So what is EIP 2535? In short, it’s a way to organize large and very complex solidity smart contracts. It’s organized and kind of a proxy pattern with one single contract, proxying calls to several different contracts behind. So basically, you have a smart contract living at one single address that can make calls to various different contracts at different addresses.
In practice, in a large decentralized application, you would organize similar logic into various smart contracts. And these contracts can be deployed separately from each other and don’t even have to talk to each other. Cool right? But super weird! Let’s talk a bit more about the specifics here.
Each of these smaller contracts behind the main proxy contract are called facets. They’re called facets because, in a diamond, each edge of a diamond or side of a diamond is called the diamond’s facet. Diamond contracts are also upgradable. What makes diamond contracts different from other proxy patterns is that the upgrades are very granular. Instead of adding and removing a single implementation contract. You can add, remove and upgrade individual functions from different contracts as you see fit.
Confused a bit? Yea, I know. I said no jargons. Let’s simplify further.
So how does a diamond work? First, every diamond has a main diamond contract. This contract doesn’t have a lot of functionality code. Ideally, a diamond contract should just have a fallback function and a way to map and look up functions from other contracts. If you’re not familiar with solidity fallback functions, these are the functions that are called when you’re calling a contract with a function name that doesn’t actually exist on the contract. The diamond takes advantage of this feature in solidity.
Say, for example, you call the function A on your diamond. The diamond contract itself does not have a function A. Instead it is going to take the signature of the function that you just called, look it up in a mapping and figure out which contract actually has function A. The contract will then use delegate call, which essentially loads the code from another contract and uses it in the context of the diamond contract. So using delegate call, the diamond will forward all of your arguments and parameters to the function A in the contract that it found in its mapping and then update the state or return as needed.
Diamonds are upgraded by using a special method called “diamond cut”. Depending on the arguments you pass to this method, you could add, remove, or even replace functions within your diamond. This method will update the internal mapping of the diamond contract. So it knows where to look for specific functions in specific contracts. In practice, the diamond cut method actually lives in a separate contract from the main diamond. This is important because there’s one downside to using a diamond, but I’ll write about in the end.
So what are the benefits of using a diamond? It makes it very easy to code and organize large and complex and smart contract projects. It helps you to avoid size limits when coding your smart contracts. For example, ethereum has a 24 kilobytes size limit for smart contracts. If your contract is large and complex, you may be prevented from even deploying this contract. A diamond lets you break this contract up into smaller contracts so you can deploy the entire application.
Another benefit to using a diamond is it allows you to build your application fast. In the web3 world, things are changing at a very fast pace. In order to succeed, you need to be able to build fast, break things, and then iterate on those ideas quickly. Diamond allows you to do this by upgrading only parts of your contract without having to change the address of the overall contract.
Now, what are some of the cons of using a diamond? Because a diamond is upgradeable requires the user to inherently trust you as the smart contract developer. This is fine in the beginning, if you have the trust of your community and you have a good reputation, but there’s always the idea of lingering that you could “rug pull” with some malicious code at any time.
Remember when I wrote above about the upgradability method, being a separate contract to the diamond, the fact that it’s in a separate contract means that you can actually use this method for upgrading, removing and adding functions in your contract to remove the upgradability itself. In essence, when you’re ready, you can make your diamond contract immutable, so no longer upgradable. This is a great way to make your contract trustless after around, uh, iterating and fixing bugs and getting your smart contract into a state that is ready and secure for users to use long-term.
And that’s basically it.
Imma grab my lunch now! I hope this article intrigues you to explore the Ethereum diamond standard or EIP 2535. What do you think? Is it a good standard? Have you tried it already, or are you looking forward to trying it?
I’ll be happy to collaborate, discuss or answer any of your questions. Ping me on Discord @dapper_saeed.
Peace out!
