EIP 2535: Diamond standard explained – Part 1: Why diamonds?

In this 4 part series, let’s dive deep into EIP-2535 Diamond standard and understand why diamonds, what are diamonds and how to use diamonds!

One of the main USPs for smart contracts is that they are immutable. Being immutable has its own advantages by removing trust from the system. But from a developer’s point of view, it poses a lot of challenges. That’s where EIP 2535: Diamond standard helps. Additionally there are few more use cases where Diamond standard helps building robust products. Let’s try to understand why it’s a really “cool” EIP. 

Why EIP 2535: Diamond standard? 

  • Normal cycle of build-test-deploy-bug fixes cannot be followed in case of smart contracts. Once deployed, you cannot alter the bytecode at a particular address. Diamond standard allows flexibility in this regard. Let’s say you have incorrectly written a function in your contract. You can easily replace  the faulty function with the corrected one, without changing the address ( i.e. deploying the new contract entirely )
  • Lot of the great teams in this space are building complex applications on-chain e.g. full fledged identity verification system, money markets etc. In case of such complex and large apps, requirements often change. Teams need to ‘upgrade’ the codebase owing to external services dependencies, need for adding / supporting new functionalities or simply for product-market fit reasons. Diamonds are made for such situations.
  • Solidity contracts are compiled to bytecode and the bytecode is deployed and stored on the Ethereum network. If the bytecode of a contract exceeds 24KB then it is rejected by the Ethereum network. There are few majors you can take in order to minimize the contract size at compile time, but your options are limited. Plus, the functionality itself might require code which exceeds the 24KB max limit. In this case, you have an option of splitting your logic in multiple contracts. However, managing dependencies and separate contracts bloats the architecture in the longer run. Again, diamonds for the rescue.   

In short, EIP 2535: Diamond standard allows you to write “transparently” upgradable, flexible, modular and logically easy to maintain smart contracts. And I think it’s really cool! In part 2 of this series, let’s understand what diamonds are and how they work exactly. I am sure you will know that I am not exaggerating. Until then, let’s stay in touch on my twitter.


Discover more from BitsByBlocks

Subscribe to get the latest posts sent to your email.


Comments

2 responses to “EIP 2535: Diamond standard explained – Part 1: Why diamonds?”

  1. […] part 1 of this series, we tried to understand why the EIP-2535: Diamond standard is required. In short, […]

Leave a Reply

Your email address will not be published. Required fields are marked *

Discover more from BitsByBlocks

Subscribe now to keep reading and get access to the full archive.

Continue reading