Upgradable Solidity smart contracts

[flowersinthesand]

At first, we, ICONDAO, considered introducing the upgradable plugin by OpenZeppelin as a solution to this problem but after all encountered EIP-170: Contract code size limit issue, writing smart contracts and implementing features.

Here are solutions we found to circumvent the issue: https://docs.google.com/document/d/1IWiZv4UDvdDyykEfLCLXPGjkW_O__iHeRgOtt8ttGG0/edit#

We prefer Separating Smart Contracts to Implementing EIP-2535: Diamonds as a solution in that it's not safe enough to write a new implementation for the standard in draft at the moment. However, we would like to hear various opinions on this first. Team, please read it and share your thought.

[unamed12]

@mohamedelshami @conor10 Happy to hear your opinion if you have opinions here

[unamed12]

To-do: Send over details on BMC, BSH, BMV implementation structure design changes

[cow-hs]

Fix Suggestion: Separating Smart Contracts

[mohamedelshami]

I have read the proposed document from @flowersinthesand and a did bit of research on the EIP-2535 standard. Here are some of my thoughts based on my understanding so far:

• Besides the upgradability feature; the diamond pattern solves the size limit problem. We will virtually have unlimited size when doing upgrades or introducing new functionality to the contracts.
• Fine-grained control over contract upgrades, incremental updates can be made to specific facet functions.
• It's possible to freeze the implementation in the future by changing the diamondCut() in the proxy contract.
• As @flowersinthesand pointed out, the proposal is still a draft. However, been adopted by well-known projects - e.g. Aavegotchihttps://docs.aavegotchi.com/overview/diamond-standard.
• There are some tools (e.g. hardhat deployer) that may simplify the deployment process.

Having said that, there're some downsides:

• It adds complexity and maintenance overhead.
• Adds extra unnecessary code and makes contract header to read.
• Intracalls are more expensive.
• It's unlikely the EIP-2535 will be pass community approval unless the design is simplified.
  Note: EIP-1662 is discussing removing the contract size limit Removing Contract Size Limit ethereum/EIPs#1662
• There are potentially some systematic risk and security challenges associated with this approach.
• There some more points here on the auditing outcome of the diamond pattern https://blog.trailofbits.com/2020/10/30/good-idea-bad-design-how-the-diamond-standard-falls-short/.

I'm more in favor of the first approach which is to separate the contracts into smaller components. So general rule of thumb is to separate contracts into state contracts and implementation. There are cases like BMV where MPT and Accumulator be easily broken down into 3 contracts, each one of those contracts has its own state. In the long term, we can still introduce a simplified proxy

In terms of coding practices in Solidity, not sure how much size optimization can be done but there are some tips here https://soliditydeveloper.com/max-contract-size.

In short, I would say we attempt the first approach first while staying open to introduce the Diamond pattern or something similar in the future.

[flowersinthesand]

Closing as we concluded to adopt 'Separating Smart Contracts'

[flowersinthesand]

Oh there's no something like close in Discussions 😅

[nymkappa]

You can choose an accepted answer, it's similar 👍