Should I move the plugin installation functions in a glorified target contract?

[PaulRBerg]

The proxy version on the staging branch has become rather expensive to deploy. Based on my preliminary findings, it can take anything between ~750k and 1.4k to deploy it, based on how the Solidity optimizer is configured.

Then, as I explained in this comment, it will not be possible to call the installPlugin method immediately after calling deploy. So users will have to sign another transaction to install the plugins they want (adding a deployAndInstallPlugin method would be overkill).

Given the above, I am now considering deleting the installPlugin and the uninstallPlugin functions from the proxy itself, relegating them to a "glorified" target contract that will ship with the PRBProxy system. That means that I will personally deploy the said target contract, and the only difference for the user experience will be that instead of calling installPlugin, users will have to ABI-encode the call and call execute instead.

The major benefits of doing this would be:

1. Significantly lower deployment cost.
2. Less overhead for those PRBProxy users who are not interested in the plugin system.

[SolcAndMe]

Agree! To me this further opens up the question on where to draw the line between what should be part of the Proxy's bytecode and what should be moved into a dedicated target contract to further optimize for deployment cost.

[PaulRBerg]

Thanks for the response.

I am now also considering moving the transferOwnership function to a glorified (or "enshrined" target), since transferring ownership is a relatively uncommon action. The added deployment cost does not seem worth it.

I will have a dedicated section for this in the wiki.

[PaulRBerg]

I ended up implementing this:

#74

The installPlugin and uninstallPlugin functions are now in the enshrined target contract PRBProxyHelpers, which will be deployed simultaneously with the factory and the registry.

I have also moved the setPermission function to this other contract for the same reasons (saving gas + potentially unneeded feature).

[PaulRBerg]

Since v4.0.0-beta.4, the enshrined target contract is called PRBProxyAnnex:

https://github.com/PaulRBerg/prb-proxy/blob/df2a49acc591709c637a66a432b1bfe6758f3ae9/src/PRBProxyAnnex.sol