Optimize BeaconProxy deployment costs avoiding storage writes

[lastperson]

🧐 Motivation
Currently BeaconProxy design while correctly using an immutable variable to store the beacon address, still writes the same address to storage with an explanation: "so that it can be accessed externally"
Lets avoid storage modification to reduce deployment costs.

📝 Details
Proxies are meant to be deployed as cheap as possible. Paying extra 24000 gas per deployment just to simplify the external access to the beacon address, which is also prone to become out of sync with the actual immutable value sounds like a bad deal.
Immutable variable could also be read from the proxy directly, just need to know the location in code.
Deployment gas with storage write: 167k
Deployment gas without storage write: 143k

This commit introduces the necessary changes: lastperson@3eb97b4

[Amxx]

Hello @lastperson, and thank your for raising that issue.

As explained in the link you share, the goal it to make the beacon proxy ERC-1967 compliant. While its technically correct that "Immutable variable could also be read from the proxy directly, just need to know the location in code.", I think the just is not as simple as you make it sound. The version of the code, on the compiler used, on the compiler settings, on the targetted evm version .... all these thing can change the location.

Being able to access this info is not a theoretical issue. The upgrades plugin activlly relies on that.

I would also put a grain of salt to the claim that "Proxies are meant to be deployed as cheap as possible". I don't think that is true, particularly with Beacon Proxies. If you want a cheap deployment, use a non-upgradeable clone. Features, such as upgrdeability have a cost, both at deployment and runtime. Additionnally, I think deployment cost is a side effect, and the main issue is execution cost. Likelly your contract is going to me used multiple times, and the overhead of the Beacon design is particularly expensive. That is the most expensive of the proxy to run. This makes me think that if you are ready to pay that extra cost for functionnality, maybe the additional sstore is not such an issue compared to the services provided.

[ernestognw]

I would also put a grain of salt to the claim that "Proxies are meant to be deployed as cheap as possible". I don't think that is true

Strongly agree with this. It's cool to find potential optimizations but in cases like these, there's off-chain infra relying on contracts following the standard that would be affected by non-compliant proxies.

Essentially, any ERC is a product of community consensus. Particularly with ERC-1967, that consensus included the storage slots. Multiple services would rely on that given we agreed it's standard.

Assuming the deployment cost difference is indeed 24000 gas units (haven't checked), that would still be ~36 dollars at 100 gwei gas price and ETH being at 15,000 USD. I would say it's non preferrable, but I would balance it against breaking infrastructure depending on an ERC we've previously had consensus at.

Things get less expensive in L2s of course.