Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Move ERC1967 to Final (Last call deadline reached) #5035

Merged
merged 3 commits into from
May 17, 2022
Merged

Move ERC1967 to Final (Last call deadline reached) #5035

Changes from all commits
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
cd20276
Make ERC1967 final as per the end of the last call period
Amxx Apr 24, 2022
a279312
Merge branch 'master' into ERC1967/final
Amxx May 13, 2022
8d2600f
Make ERC1967 final as per the end of the (second) last call period
Amxx May 13, 2022
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
5 changes: 2 additions & 3 deletions EIPS/eip-1967.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -4,8 +4,7 @@ title: Standard Proxy Storage Slots
description: Standardise where proxies store the address of the logic contract they delegate to, as well as other proxy-specific information.
author: Santiago Palladino (@spalladino), Francisco Giordano (@frangio)
discussions-to: https://ethereum-magicians.org/t/eip-1967-standard-proxy-storage-slots/3185
status: Last Call
last-call-deadline: 2022-05-14
status: Final
type: Standards Track
category: ERC
created: 2019-04-24
Expand Down Expand Up @@ -94,7 +93,7 @@ The fact that proxy public functions are potentially exploitable makes it necess

The main requirement for the storage slots chosen is that they must never be picked by the compiler to store any contract state variable. Otherwise, a logic contract could inadvertently overwrite this information on the proxy when writing to a variable of its own.

Solidity maps variables to storage based on the order in which they were declared, after the contract inheritance chain is linearized: the first variable is assigned the first slot, and so on. The exception is values in dynamic arrays and mappings, which are stored in the hash of the concatenation of the key and the storage slot. The Solidity development team has confirmed that the storage layout is to be preserved among new versions:
Solidity maps variables to storage based on the order in which they were declared, after the contract inheritance chain is linearized: the first variable is assigned the first slot, and so on. The exception is values in dynamic arrays and mappings, which are stored in the hash of the concatenation of the key and the storage slot. The Solidity development team has confirmed that the storage layout is to be preserved among new versions:

> The layout of state variables in storage is considered to be part of the external interface of Solidity due to the fact that storage pointers can be passed to libraries. This means that any change to the rules outlined in this section is considered a breaking change of the language and due to its critical nature should be considered very carefully before being executed. In the event of such a breaking change, we would want to release a compatibility mode in which the compiler would generate bytecode supporting the old layout.

Expand Down