Comments (5)
These are all great reasons to avoid the extra SSTORE. Also, an SSTORE is on the list of things we'd push to optimize for.
Nonetheless, ERC1967 didn't provide a standard way to retrieve the beacon address from a client but it suggests doing it by reading from the slot:
[...] In order to know the logic contract used by a beacon proxy, a client SHOULD:
- Read the address of the beacon for the beacon logic storage slot;
- Call the implementation() function on the beacon contract.
Aside from our upgrades plugins library relying on the slot value, we also agreed that, if following the standard, there's not a more reliable option to retrieve the admin, implementation, and beacon addresses than from the slot.
I think a better solution would be to retrieve the immutable from the end of the bytecode
Yeah this is good, but it's non-standard. It's breaking for platforms and tooling supporting EIP-1967, although it's possible everyone just adapts (not optimistic about this).
or emit an event instead of using storage
The EIP states that storage slot changes SHOULD be notified by events. If we're not changing the slot, then clients should arguably not expect an event to be emitted. This is just too ambiguous to rely on imo.
Since this is only done at construction, we generally thought the extra SSTORE was not the end of the world in this case 😅
from openzeppelin-contracts.
Hello @kadenzipfel
This sstore was kept on purpose. While it is not necessary for the contract to work, it is used for "beacon discovery".
The beacon proxy contains no public function, so that it is fully transparent, but that means it also does not (and cannot) include any getter. Now immagine you want to know which beacon a proxy uses. There is no easy way to do so. Our tolling used to rely (and still relies) on ERC-1967 slots for that kind of information.
Writting the address of the beacon to theBEACON_SLOT
sets that slot so that tolling suc as OpenZeppelin's upgrade plugin are able to detect which beacon is used.Fair enough, but fwiw I think a better solution would be to retrieve the immutable from the end of the bytecode or emit an event instead of using storage
Both methods can be effective, and the choice often depends on factors such as gas efficiency.
If gas efficiency is a concern, parsing the bytecode might be more expensive than reading from storage, so emitting an event could be a lighter-weight solution. On the other hand, if the gas cost is acceptable, parsing the bytecode might offer a more compact storage and reduce the reliance on additional storage slots.
from openzeppelin-contracts.
Closing for inactivity. I'll assume we agreed on the resolution 😋
Comments will be kept open in case anyone wants to add something.
from openzeppelin-contracts.
Hello @kadenzipfel
This sstore was kept on purpose. While it is not necessary for the contract to work, it is used for "beacon discovery".
The beacon proxy contains no public function, so that it is fully transparent, but that means it also does not (and cannot) include any getter. Now immagine you want to know which beacon a proxy uses. There is no easy way to do so. Our tolling used to rely (and still relies) on ERC-1967 slots for that kind of information.
Writting the address of the beacon to the BEACON_SLOT
sets that slot so that tolling suc as OpenZeppelin's upgrade plugin are able to detect which beacon is used.
from openzeppelin-contracts.
Hello @kadenzipfel
This sstore was kept on purpose. While it is not necessary for the contract to work, it is used for "beacon discovery".
The beacon proxy contains no public function, so that it is fully transparent, but that means it also does not (and cannot) include any getter. Now immagine you want to know which beacon a proxy uses. There is no easy way to do so. Our tolling used to rely (and still relies) on ERC-1967 slots for that kind of information.
Writting the address of the beacon to the
BEACON_SLOT
sets that slot so that tolling suc as OpenZeppelin's upgrade plugin are able to detect which beacon is used.
Fair enough, but fwiw I think a better solution would be to retrieve the immutable from the end of the bytecode or emit an event instead of using storage
from openzeppelin-contracts.
Related Issues (20)
- Add a MerkleProof.verify function that support arbitrary internal hashes
- Use transient storage in ReentrancyGuard
- Incorrect "deadline" field description in IERC20Permit HOT 4
- Remove pseudo-fuzzing tests in hardhat in favor of foundry fuzzing. HOT 3
- ERC2771Forwarder has a flaky tampered signature test
- Security considerations regarding `SignatureChecker.isValidERC1271SignatureNow` HOT 2
- Consider adding block.chainid in ERC2771Forwarder transactions HOT 2
- Online tools support custom Solidity versions HOT 1
- Add paginated lookups for EnumerableSet and EnumerableMap HOT 2
- WebAuthn implementation
- Implement a CircularBuffer
- [Vanta] Remediate "Low vulnerabilities identified in packages are addressed (Github Repo)" for npm-undici/CVE-2024-24758 HOT 1
- Online tools support custom Solidity versions HOT 1
- Use EIP-1967 for Ownable storage HOT 5
- Ownable2Step doesn't call Ownable constructor HOT 1
- Mining Apps for quickest rise dividend
- Potentially redundant getVotes in Governor propose function HOT 1
- The natspec comment of IAccessControl regarding `RoleGranted` event should be updated HOT 1
- Improve gas efficiency of `SafeERC20.forceApprove` when the token returns a bool on approve
- Merge 4.9.6 and 5.0.2 changelog entry into master HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
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.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from openzeppelin-contracts.