Solving the 24kb Max Contract Size Limit

[mudgen]

@bingen and Aragon One wrote an article about the maximum contract size limit and how to solve it.

The bottom of the blog post says this:

What else can we do? Have you run into similar issues? Let us know if you have other strategies to reduce contract sizes, we would love to know! (You can reach out to us on our chat and our forum)

I wrote a blog post that explains how the max contract size limit is solved using the Diamond Standard. See it here: https://dev.to/mudgen/ethereum-s-maximum-contract-size-limit-is-solved-with-the-diamond-standard-2189

The Diamond Standard is a standard way of creating a proxy contract that uses any number of delegate/facet contracts to implement functionality. There is no max contract size limit with this approach. See the blog post I wrote for more details.

It would be great if the Aragon blog post could be updated to mention the Diamond Standard as a possible solution.

[bingen]

Hi @mudgen

thanks a lot for your suggestion! I had a look at that Diamond Standard after your tweet and it looks very interesting.

However, before editing that blog post, I would like to be able to try it out first, to be able to asses first hand the pros and cons of the pattern, compare it to ad-hoc solutions or to other kind of proxies. Actually I’m thinking that it may even be a good topic for another whole blog post, as a continuation to that one. But I need time for this.

[mudgen]

@bingen That makes total sense! I would love for you to try it out and evaluate it and potentially write a blog post about it.

I have decided to give you lots of time for this! The Diamond Standard may be very useful for the next version of Aragon One contracts and/or new contract systems. Perhaps some time can be made on that basis.

I think the Diamond Standard is particularly good for governance and DAOs because it enables fine grained and flexible contract upgrades that can be approved and done by voting.

If you have further quesitons or want to discuss diamond things, here’s an invite like for Discord: https://discord.gg/bvcMGr

[light]

Just saw this blog post about the Diamond Standard:

Good idea, bad design: How the Diamond standard falls short

[mudgen]

@light Yea, I’d disregard Trail of Bit’s blog post. Or go read EIP-2535 Diamond Standard and the diamond reference implementations for yourself. Come to your own conclusion.

Trail of Bit’s blog post is about an old version of the Diamond Standard and an old implementation of it. The standard and its implementations have improved since then. And some of the data in Trail of Bit’s blog post is wrong or misleading. I will be writing an article to address these things.

By the way Trail of Bit’s also tells people not to use OpenZepplen’s upgradeable contracts: https://forum.openzeppelin.com/t/openzeppelin-usage-in-audited-well-known-projects/2556/5

If you want to see a smart contract audit report of an up-to-date diamond implementation then see the one here by Quantstamp: https://certificate.quantstamp.com/full/aavegotchi-ghst-staking

[mudgen]

I wrote an in-depth response to the article by Josselin Feist from Trail of Bits about the diamond standard here: https://dev.to/mudgen/addressing-josselin-feist-s-concern-s-of-eip-2535-diamond-standard-me8