Hello, Ernesto from BGD Labs here, a team that has been building the Aave core protocol over the last few years. I would want to support the increase and comment on its importance from the perspective of Ethereum application developers.
For the last few years until now, when developing any type of mature smart contract, the 24kb limit is highly frequently one of the most “typical” blockers that force us to change architecture/flow-model. While one of the design principles of smart contracts is simplicity, and composition patterns almost always allow for introducing functionality without being affected by contract size limits, the reality is that the architectural/development flow works as follows:
- We come up with a product idea with a list of features. For example, a smart contract acting as a gateway/controller, with multiple public functions.
- One frequent architectural principle we have in some designs is: keep the business logic on the same contract, to 1) minimise the indirections for humans reviewing the code from a security perspective, and 2) minimise external calls. Meaning that we use composition (e.g., external libraries), but in certain systems, we want to minimise even those.
- We implement applying that principle.
- Very frequently, we notice we are above the 24kb limit after some prototyping, or that we are relatively close (up/down).
- Given that we don’t want to start with “dark” optimisations or not having any “room” to add new functionality that could appear later during development, we frequently go back to the architectural whiteboard and divide into more components. Or we simply discard some of the features to not bloat the complexity.
In some design/implementations, having strict limitations “forcing” compatibility patterns is positive for good practises. However, after years of developing various types of contracts and reaching the 24kb limit, I honestly believe that, regardless of the rationale for maintaining it, the 24kb limit is harming the Ethereum development ecosystem.
As a developer already trying to be very resource-minimisation oriented and design-conscious for the type of hosting machine that Ethereum is, it is very frustrating to find very strict blockers, whose rationale is relatively artificial. And I believe that me/my team’s case is actually not a very problematic one, because we have followed Ethereum from the beginning, and we understand there are nuances and reasons to keep the limit conservative. But for people with visibility strictly on the application development layer, the limit, I imagine, is even more frustrating.
Another example of the type of blocker this is: while doing features discussion with the team, the 24kb limitation is a first-class citizen on the discussion, from the angle of “That function is good/seems to belong on this contract, but considering the rest, it feels we will hit the 24kb”. While other blockchain-specific constraints **should** actually be part of the conversation (e.g., reduce iteration), this one simply feels wrong.
So in summary, big support to the increase, ideally to 48kb, but even to 32kb would be a pretty good improvement.