Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
A pass at upgradeability #75
I'm going to leave some clarifying comments, but there is a lot in this one so it might be easier to review by reading over it once and then we can sit down and run through it
Overall it seems like this approach gives us the benefit of being able to easily upgrade contract logic, at the expense of hacking around solidity and the EVM in the following ways:
- Requiring getters and a single read for each property of a struct.
- Needing to read certain dynamic values from LOGs instead of the chain (which may go away with Byzantium).
- Dropping down to assembly and delegating calls from proxy to target contracts. Not that this is explicity unsafe, but we're fiddling around with memory and addresses where we place call data and read return values.
- Needing to keep storage values in the same order within contracts as we add new ones during upgrades. This is potentially prone to bugs, programmer error, or even breakage due to underlying tools or EVM updates.
I think that, especially due to this last point, the way to look at this is: it gives us the ability to upgrade if we need to using this mechanism for now...but we may not be able to rely on it for all cases and forever into the future.
Agreed on how to look at the upgradeability related additions in this PR. I think it makes sense to have a working version of this approach in this codebase for now and press on with other tasks knowing that we have a basic upgradeability solution to work with. And perhaps we will get more information in time (i.e. feedback, Byzantium on the mainnet, Solidity development) that changes how we look at this solution (for better or for worse)