Giter Club home page Giter Club logo

Comments (2)

Amxx avatar Amxx commented on June 14, 2024

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.

from openzeppelin-contracts.

ernestognw avatar ernestognw commented on June 14, 2024

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.

from openzeppelin-contracts.

Related Issues (20)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.