区块链基础
Contract storage layout
Persistent values occupy locations interpreted by implementation code.
研究文章和参考条目以英语发布。导航提供七种语言。
人物与项目
本文目录
Persistent values have a physical arrangement
A contract may expose names such as owner, balances or paused in source code, but its persistent values are stored according to a layout. Solidity assigns state variables to storage slots and can pack small values together. Mappings and dynamic arrays use derived locations rather than placing every element sequentially beside the variable’s declaration. Reading a slot without knowing the layout can therefore produce a plausible-looking but incorrect interpretation. Solidity storage layout.
Why upgrades can misread existing data
Consider a simplified upgradeable contract with an owner address in one slot and a counter in another. Its replacement implementation expects those locations in the opposite order. The old bytes do not rearrange themselves to match the new variable names. Code can begin treating an existing value as a different field, with consequences for access checks or accounting.
This is an illustrative failure, not a description of a named project. Its point is that preserving a proxy address does not prove that an upgrade preserves the interpretation of its data. A reviewer needs both implementations’ layouts and the actual upgrade method. A reassuring diff of function names is insufficient when the state those functions read has changed meaning.
A source-code label is not a privacy boundary
Solidity’s private visibility controls which code can access a variable through the language’s normal rules. It does not make onchain storage secret. Persistent contract state is part of the execution environment; secrets should not be treated as protected merely because an automatically generated public getter is absent. Ethereum: state variables and visibility.
Suppose an application advertises that a private variable safely hides a winning answer. The relevant assessment asks what is stored, where it is stored and when it becomes observable. A screenshot showing no public getter does not answer those questions. This also differs from encrypted data: encryption requires an actual cryptographic scheme and key-handling model, not a visibility keyword.
What a useful upgrade review preserves
Record the proxy address, the old and proposed implementation addresses, compiler settings, layout outputs and the upgrade transaction or proposal. Compare inherited fields and packed values as well as obvious top-level declarations. If the project uses a namespaced storage convention, inspect that convention instead of assuming an older sequential layout. The cited Solidity documentation explains why layout is an interface that other code can depend upon.
A test should start from representative existing state, not only a fresh deployment with zero balances and empty mappings. For example, an accounting migration can appear correct when every user has a zero balance yet fail when populated records occupy the locations being reinterpreted. Preserve the pre-upgrade values and the expected post-upgrade invariants so another reviewer can reproduce the comparison.
Finally, distinguish compatibility from authorisation. An upgrade can be storage-compatible but controlled by a single key with excessive powers. Conversely, a multisig vote can approve a technically incompatible implementation. Both need examination. Continue with upgradeable proxies and governance execution.