Marking certain functions as public rather than internal depending on usage.

[swan-of-bodom]

I have been playing around trying to reduce contract sizes after reading this:

https://ethereum.org/en/developers/tutorials/downsizing-contracts-to-fight-the-contract-size-limit/

Specifically the part where it mentions making library functions public rather than internal. Declaring them as internal means they get imported into the actual contract, and thus takes up space depending on the size of the function, while making them public means the library keeps the size of it.

I am relying on the common logarithm function from the PRBMathUD60x18 library in one of my contracts. When I did the .log10() method in my contract function, I see that my contract increased by 4kb :(

So i removed it and contract size went back to normal:

Since I need the log10 function only once in my contracts I marked the function as public in the PRBMathUD60x18 contract:

And and yay! it works perfectly barely increasing the contract size while the size of the PRBMathUD60x18 lib increases:

Since I am also using the geometric mean and sqrt functions for certain other contracts, I made them public and managed to reduce the size of my contracts by almost 1kb

So just a tip for newbies like me using PRBMath, if you plan on using the function a lot (like mul, div) then keep them as internal, if you plan on using the functions sparingly, keep as public :)

[PaulRBerg]

Hi @0xHyoga, thanks for documenting this. Unfortunately, you may need to keep using the internal modifier in the PRBMath functions. As a rule of thumb, it is recommended not to fiddle with an external library's source code.

When you mark the log10 function as public, Solidity expects you to deploy the library at a separate address and then link your consuming contract. You can read about how linking libraries works here.

Obviously, having to re-deploy PRBMath every time you deploy your contract is bad UX and will ultimately end up costing you a lot, likely more than via the other approach.

The solution is to keep using internal and find other ways to reduce the contract size. PRBMath increases the size of your consumer contract because logarithms are not trivial to compute in Solidity.

[swan-of-bodom]

Hi @PaulRBerg Thanks for sending that article, wasn't aware of this. I will follow your advice then! However I find it strange that the article I referenced from ethereum.org suggests marking certain functions as public.

I figured there would be a trade-off somewhere though, and I guess it comes at deployment and messy UX like you mention. I will see if i can find a solution around this then, since the function is such a beast that it takes quite a bit of space in the contracts 😄 Thanks!

[PaulRBerg]

Well I think that the "ethereum.org" article is referring to the case when you design your own library. In that case deploying the library and linking it is easier because you are in full control of it.

Happy to help. Good luck!

[PaulRBerg]

Locking this conversation, since this will no longer be an issue in PRBMath V3 (coming soon), which uses user-defined value types and free functions instead of the library approach.