4

The ZeppelinOS docs clearly explain the importance of state variable order when upgrading smart contracts, but say little on whether the same rules apply to functions.

3

TLDR: Only affects variables

ZeppelinOS does upgradability by using the proxy pattern, you can actually change the way it behaves, depending on the specific implementation the order of variables may matter, we can preserve data across upgrades etc.

In their current default implementation we can simplify the process with this structure:

Client -> Proxy contract -> Logic contract

The way the upgrade works:

  1. The new functionality is added by deploying a new "Logic contract" with the upgrades
  2. The pointer in the "Proxy contract" is changed, to send transactions to the new "Logic contract".

Since transactions from the client go to the "Proxy contract", the address hasn't changed and the user can interact the same way it did before, with the same address.

The key to your question, is where are the variables are stored and updated, again, there are multiple implementations, the simplest is to keep the variables in the proxy, this means that the variables are stored in the "Proxy contract", some logic gets executed in the "Logic contract", which updates the variables on the Proxy contract.

This is why when you are updating your logic, the old variables are stored on the same positions on the non updated proxy contract, and why keeping those consistent matter. On the other hand, since the functions are stored on the new logic contract, we don't need to worry about those.

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

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