We’re rewarding the question askers & reputations are being recalculated! Read more.
132

Once a contract is in the blockchain, it is final and cannot be changed. Certain parameters, of course, can be changed if they are allowed to change via the original code. One method of updating contracts is to use a versioning system. For example, you could have an entryway contract that just forwards all calls to the most recent version of the contract, ...


33

One method is to use a System of Contracts as outlined below: Contract "Register" - will contain pairs "name - address" for all contracts of your system; Contract Backend; Contract Frontend using Backend; Deploy Register & get address of it; Deploy Backend & register address of Backend into already deployed Register; Hardcode the address of Register ...


30

Contract code is permanent. There is no way to alter the code of a deployed contract except by destroying it altogether by the SELFDESTRUCT opcode (selfdestruct() in solidity.) There's four ways, more or less, to cope with this: Don't. Just have the contract be eternal, no matter what happens. Use some scheme to work around this limitation. Create a new ...


29

Contract code is immutable, the storage is mutable, but you cannot execute code placed into storage, at least for now. Bugfixes to contracts As for bugfixes, the common pattern is to have proxy or lookup contracts to be a gateway to the real one, which in case of a change or bugfix would be replaced. Replacing it also means losing the old storage contents. ...


21

Contracts deployed on a blockchain are immutable, so this means: address and code of a deployed contract cannot be changed deploying a newer (or even identical) contract will create a new address code cannot be added to a deployed contract If the contract issues want to have a way to upgrade the contract code, so that account data and other things carry ...


14

The Migrations contract stores (in last_completed_migration) a number that corresponds to the last applied "migration" script, found in the migrations folder. Deploying this Migrations contract is always the first such step anyway. The numbering convention is x_script_name.js, with x starting at 1. Your real-meat contracts would typically come in scripts ...


13

The short answer is that contract code is immutable so you can't update without destroying the contract and deploying a new one in which case any state will be lost and users, other contracts or user interfaces will need to interact with another contract. However there are various patterns which allow you to point to a new version and optionally keep state ...


11

The most voted answer is to use delegatecall and it is very tricky to get correct. https://blog.trailofbits.com/2018/09/05/contract-upgrade-anti-patterns describes some upgrade methods, as well as critical considerations so that you don't introduce more bugs or a buggy upgrade method that doesn't work. Proxy pattern recommendations Check for the ...


11

@Nick Johnson has a base contract for upgradeable contracts. As he says, before using one should be "fully understanding the limitations and drawbacks." /** * Base contract that all upgradeable contracts should use. * * Contracts implementing this interface are all called using delegatecall from * a dispatcher. As a result, the _sizes and _dest ...


8

A hardfork is a change in the protocol that is not backwards compatible, ie transactions from nodes running the older software will not be considered valid. With a soft fork nodes running an older version of the software could still publish valid transactions, they will just not have the latest and greatest features.


7

Coming to one of the basic principles at Ethereum that is a Smart Contract cannot be modified after deployment. BUT, you can still have Upgradable Smart Contracts if you put the following into consideration This has to be planed from the start. The key point is number 4. But all the others are essential to have a real and smooth Smart Contract Upgrade. ...


5

A hardfork is a situation where by consensus the ethereum peers agree to change the blockchain protocol spec as of a certain block number. The Homestead release has been hardcoded into the current ethereum clients to occur at block number 1,150,000. Nodes need to be upgraded to the latest release in order to continue functioning correctly after the ...


5

We(I and My team) have recently worked on Upgradable Contracts problem after referring to colony.io's post on Upgradable Contracts. So, we came with a solution in which we have different layers of contract rather than having one single Contract. If I describe it briefly then one need to make the storage part very generic so that once you create it, you can ...


5

Here's a sketch of a way to do it, but be warned this isn't for the faint of heart. Create a base contract with a global variable that will point to the current library. Create the contract (the host) inheriting from the base contract. Also create the first real library for it. Create a library (the proxy) inheriting from the base contract. (This will ...


5

Upgrading Mist on Ubuntu Backup your keystore (/.ethereum/keystore) Backup your data folder (/.config/Mist) Download the latest zip from here and install. For more information on backing up wallets, see here: How to backup mist wallets? Upgrading geth $ sudo apt-get install software-properties-common $ sudo add-apt-repository -y ppa:ethereum/ethereum $ ...


4

Here is an example of a real use case of Truffle migrations. I have a storage contract and an interface contract. The interface needs to know where the storage is and the storage needs to grant permissions to the interface. So in the second migration (the first one is reserved for Truffle housekeeping) I'm deploying the storage: var MEStorage = artifacts....


3

According to my experience in the following code https://gist.github.com/anonymous/c23f944b139a76693abbae261ad577b8 it is enough implementing those ones you are using. In the example: /// ---- dataStorage interface contract dataStorage { function getBalanceOf(address _account) constant returns (uint256 balance); function setBalanceOf(address ...


3

This is a pretty general question for this site, so it might get voted down. It's clear you've done some homework and you're considering how all the parts of an upgradable system of contracts would fit together. Yes. It's a name resolver that could be used to resolve a contract address. That affords developers with the option of appointing new user-...


3

Allows you to have a contract with a stable address, but fully controllable and upgradeable behavior. https://github.com/u2/ether-router https://github.com/ConsenSys/smart-contract-best-practices#upgrading-broken-contracts


3

zos introduced a framework for us to easily implement an upgradable smart contract PTAL: https://docs.zeppelinos.org/docs/start.html


3

As you already figured out, you have to upgrade to mist 0.5.2 first. The homestead fork was active at block 1,150,000 and only post-homestead releases like geth 1.3.5, eth 1.2.2, mist 0.5.2 will sync past that block. So rather update now and sync later.


3

The short and precise definition is provided by BIP 123: Hard Forks In a hard fork, structures that were invalid under the old rules become valid under the new rules. Soft Forks In a soft fork, some structures that were valid under the old rules are no longer valid under the new rules. Structures that were invalid under the old rules ...


3

It looks like its cooked into geth here: https://github.com/ethereum/go-ethereum/blob/master/jsre/ethereum_js.go#L2419 module.exports={ "version": "0.13.0" } I'd ask one of the contributors to this file to see if it needs to be updated yet. (I'm sure they'll update it as testing allows.) Here is a summary on each of the new web3.js major features.


3

This is a community wiki. If releases of other clients are available, please edit the list below. EVERYONE: Update clients! Upgrade geth nodes at least to version 1.3.5 Upgrade ++eth nodes to at least version 1.2.2 Upgrade mist browser to at least version 0.5.1 Upgrade parity nodes to at least version 0.9.1 Upgrade ethereumj nodes to at least version 1.2.0 ...


3

No, the Caller doesn't need to know the complete interface of the Callee. As you have stated : As far as I understand if a caller uses just one function from a callee contract it only needs to know the signature of this function, not the whole interface. The calling contract isn't omniscient, it cannot know if the interface you gave is complete or not. ...


3

This is because Solidity sets up the variables in storage sequentially. So if you move the references of storage variables in the upgraded one, they'll be referring to the wrong slot in storage. Here's an example: contract StorageOriginal { uint public first = 10; uint public second = 20; } and contract StorageNew { uint public second; ...


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 ...


3

Have a look here: https://medium.com/chainsecurity/constantinople-enables-new-reentrancy-attack-ace4088297d9 TLDR; Repricing SSTORE defeats the re-entrancy protection that the gas stipend is meant to provide. That would be a breaking change to some deployed contracts. Hope it helps.


2

As long as the client is updated there won't be a problem. Just as with browsers and mobile devices – upgrades are important to ensure the security of the system. The Internet in your area could go down as well, so, as far as locks are concerned, that's going to depend on code more than the blockchain.


Only top voted, non community-wiki answers of a minimum length are eligible