Basics
-
Smart contracts storage:
- Bytecode - the code that contains functions that EOAs can call.
- Storage - the contents of variables in the contract.
-
The storage can be mutated after the contract is deployed.
-
But the bytecode is immutable once deployed.
Upgrading via Variables
- Since contract storage can be changed post-deployment, applications may alter behavior based on the value of a certain variable. Eg:
- A staking contract may change the staking rewards by setting it in a variable.
- Farcaster uses a variable to restrict registration. When the value of the var is set to 0, other client-apps will be able to register.
Upgrading via Contract Pointers
- Sometimes applications may need to change the application logic itself.
- A main dispatch contract holds the address of the actual contract and makes the call there.
- This only works if the function interface of the first and second contract are same.
Upgrading via Proxies
- The EVM provides a special opcode called
delegatecall. This fetches the code of another contract (the logic contract) and executes it within the storage context of the original contract (the proxy). - Similar to running a script off the internet, dangerous.
- This enables applications to migrate to a different logic without losing all the state changes.
Metadata
- People:: 0xfoobar
- Related:: EVM
- References:: - Smart Contract Upgradability
- Status::research_more
- Created:: 24th Oct 2022
- Updated::
$=dv.el('t', dv.current().file.mday)