Ethereum Stack Exchange is a question and answer site for users of Ethereum, the decentralized application platform and smart contract enabled blockchain. It only takes a minute to sign up.
Sign up to join this community
It was my understanding that Truffle migrations will move updated contracts to new addresses. As a developer, you can use this feature to update already deployed contracts with new code.
ZeppelinOS has a complicated solution using proxies. Is it doing more for you than a regular migration?
In case of truffle the stored values will not remain in the upgraded contract whereas in proxy approach it is possible to obtain the stored values in the upgraded contract too.
In truffle upgrade a new version of contract is being deployed to the network and we will be obtaining a new contract address. If try to console the contract address in migrations file you will be able to see different contract address for consecutive deployments.
Whereas when we use proxies to upgrade the smart contract we will be having logic and storage in separate contracts. So that the logic contract will be updated every time until all the bugs are cleared but the storage contract will remain same. In order to do that we will be using the proxy contract approach.
refer : https://hackernoon.com/how-to-make-smart-contracts-upgradable-2612e771d5a2
Smart contracts are immutable (code cannot be changed) by design.
Truffle and ZeppelinOS are platforms for the development of smart contracts for Ethereum based blockchains.
Truffle migrate manages the deployment of contracts to blockchain(s). Each time you migrate a contract you deploy a new instance to a new public address. To use the new smart contract instance, users (including dApps) would need to change to use the new address. https://www.trufflesuite.com/docs/truffle/getting-started/running-migrations
ZeppelinOS provides an easy to use, simple, robust, and opt-in upgrade mechanism for smart contracts that can be controlled by any type of governance, be it a multi-sig wallet, a simple address or a complex DAO.
The basic idea is using a proxy for upgrades. The first contract is a simple wrapper or "proxy" which users interact with directly and is in charge of forwarding transactions to and from the second contract, which contains the logic. The key concept to understand is that the logic contract can be replaced while the proxy, or the access point is never changed. Both contracts are still immutable in the sense that their code cannot be changed, but the logic contract can simply be swapped by another contract. The wrapper can thus point to a different logic implementation and in doing so, the software is "upgraded". https://docs.zeppelinos.org/docs/pattern.html
You can learn more about ZeppelinOS in the documentation: https://docs.zeppelinos.org/docs/start.html
If you have further questions about ZeppelinOS please ask in the community forum: https://forum.zeppelin.solutions
