Contract storage: the persistent state a transaction changes

Persistent data

An EVM contract can keep values in persistent storage. Solidity assigns slots according to its storage-layout rules, with specific arrangements for packed values, mappings and dynamic arrays. A transaction can update that state when execution succeeds, and later calls read the new values.

This is where an application may record an owner, a user's debt, an allowance, a pause flag or an implementation address. Reading source code without checking the deployed state leaves important questions unanswered: which account is the owner now, is the contract paused, and which parameters are active?

Upgrades make layout consequential

An upgrade can execute new logic over old storage. If the replacement logic interprets a slot differently, data that used to represent one value can acquire a different meaning. Compatibility is therefore more than whether the new functions compile.

For an investigation, preserve both the code identity and the block at which state was read. Proxy upgrades explain how logic changes while an address remains the same. Evidence snapshots explain why a current read cannot establish what the storage contained before a disputed transaction.

Quellen und Originale

• Solidity: storage layout