2

A developer of Remix told me that if a deployed contract suffers from a breaking change, then it may become a "dead" contract. Which means that it has become unaccessible in its runtime environment.

If that is true: What can I do as a Solidity programmer to prepare for a breaking change so that I port and preserve my existing contract of a past version?

To focus my question: It is a general question about backwards compatibility of an existing contract in the case of a hard fork.

Improve this question

1 Answer 1

Reset to default
3

In general future versions of Ethereum shouldn't break existing contracts. Future upgrades should respect the need for existing contracts to keep working. If they do, it is unlikely that you will be able to fix your contract.

However, there are certain aspects of the system that may well change, and you should avoid relying on those if you want to minimize the chances of your contract being broken by a future protocol upgrade. A couple that spring to mind:

  • Don't try to measure time by counting blocks. Sometimes people will suggest using block numbers as a proxy for time, because of some issues with the trustworthiness of timestamps. (See Solidity: Timestamp dependency, is it possible to do safely? for discussion of these issues). But the length of the block interval is already varying due to the ice age, and it could change radically in the transition to proof-of-stake.
  • Don't rely on gas prices remaining the same. Gas prices are hard-coded in the protocol, and listed in the yellowpaper. However, they were decided based on the approximate relative cost of performing different operations, and that in turn depends on the performance of the hardware and software they are run on. There has already been a hard-fork that changed the price of some operations that had turned out to be more relatively expensive than intended, making DoS easier, and they may well be repriced in future.

Finally, if you are able to create escape hatches in your contract, they can protect you problems caused by both protocol upgrades and new discoveries of security issues. These often come with trade-offs in the form of extra trust requirements, but sometimes the trade-off is worth making. For example, some contracts give developers or curators an ability to freeze the contract and return user funds in emergencies. Others allow wholesale upgrades of contract logic - see this answer for discussion of how to do this: Upgradeable smart contracts

Improve this answer
3
  • Thank you for answering. In recent changes we had the new keyword "payable". If a function of an old contract does not have it, then today it will automatically reject all Ether sent to it. I assume the EVM is not aware that the contract was compiled with another version. So the (programming) contract breaks. Correct?
    – otembajelle
    Commented Oct 8, 2017 at 7:35
  • 1
    This was a change to Solidity not the EVM. Solidity's job is to make bytecode that you send to the EVM. Once code is deployed, the bytecode can't changed, and changing future versions of Solidity makes no difference to it. If you tried to redeploy the code with a new version of Solidity, the newly deployed code would be broken by the change. You normally specify the Solidity version of your code with the pragma directive, which should prevent you from accidentally deploying using a new version to compile code intended for an older version.
    – Edmund Edgar
    Commented Oct 8, 2017 at 7:54
  • I have been looking for a plausible answer for a long time. Your answer that solves my puzzle. Thank you so much!
    – otembajelle
    Commented Oct 8, 2017 at 8:01

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.