This may be documented, but I’m new to this an still trying to put it all together. What I’m thinking about is implementing a process in a smart contract. However, that process may need to be modified in the future. Since smart contracts are both immutable and irrevocable (meaning once published I can’t stop v1.0 process from being used in the future), I was thinking of using “delegatecall” for various “subfunctions” of the process. Since the contract has an account, can I store the address of each “subfunction library” in the smart contract’s account and have the smart contract read the address from the account to make the “delegatecall”? Since reading account memory is expensive, how costly would this be?
So reading further I discovered “Deactivate” and “SelfDestruct” which have their own problems. However at the end of that topic, I see:
" If you want to deactivate your contracts, you should instead disable them by changing some internal state which causes all functions to revert. This makes it impossible to use the contract, as it returns Ether immediately."
This suggests that I might be able to update the addresses (if I can change some value in the internal state to disable the function, I should be able to update the “library address”) but I’d still like to confirm where this is stored.
So I should have read the whitepaper (Ethereum Whitepaper | ethereum.org) first:
“A general outline for how to code a DAO is as follows. The simplest design is simply a piece of self-modifying code that changes if two thirds of members agree on a change. Although code is theoretically immutable, one can easily get around this and have de-facto mutability by having chunks of the code in separate contracts, and having the address of which contracts to call stored in the modifiable storage.”
1 Like
Use a eip 1967 proxy
Thanks. The comment by Noic Labs about “Malicious backdoors in Ethereum proxies” provides more than sufficient motivation to use the stand method.