The easiest standard for DELEGATECALL upgrade mechanism is https://gist.github.com/Arachnid/4ca9da48d51e23e5cfe0f0e14dd6318f

I don't get completely how it works, especially these aspects:

  1. The "eternal" storage which will survive upgrades should go to the Dispatcher, not the implementing/upgradeable contract, is that correct?
  2. Should the upgradeable contract have it's own storage at all or should it be without storage/state like libraries?
  3. Why can the delegated contract not change it's storage layout? Or is this true for the Dispatcher only?
  4. There are other solutions like delegating to a dedicated eternal storage contract (https://blog.colony.io/writing-upgradeable-contracts-in-solidity-6743f0eecc88) what are the advantages/disadvantages of these solutions

1 Answer 1

  1. Yes. Thanks to delegatecall semantics when the upgradable contracts are called through dispatcher state is stored and changed on the dispatcher contract.
  2. No, the storage of dispatcher will be used. This doesn't mean you cannot define variables on upgradable contracts. It just means that they will be stored in dispatcher storage space.
  3. As the storage is reused by next versions of upgraded contract, compatibility must be maintained. There are some rules for that:

When upgrading a contract, restrictions on permissible changes to the set of storage variables must be observed. New variables may be added, but existing ones may not be deleted or replaced. Changing variable names is acceptable. Structs in arrays may not be modified, but structs in maps can be, following the same rules described above.

  1. The Nick Johnson's Upgradable contract that you are referring to is very generic. It means that many different storage layouts may be used. This is the very high level of abstraction and may be hard to use by beginners. The colony approach defines a strict interface as you define explicit api for accessing data storage. It's less abstract and easier to use but it's limiting your possibilities.
  • Thanks, that clarifies a lot. Just some comments: ad 1,2) ok, as understand it, I just write the upgradeable contract without any modifications and all storage in this contract will be in the "storage space" of the Dispatcher, which can and should stay as is. ad 3) then I got it, I should not change order/modify state variables since they are in the Dispatchers storage space and could get messed up due to storage layout ad 4) this one I don't get, the colony-approach is completely different, right? (interface vs. dcall) So, isn't this much more expensive? That would be a severe tradeoff.
    – Ice09
    Commented Jul 19, 2017 at 6:23

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.