5

Situation:

let's assume we have

  • a data storage contract
  • libraries that import the data storage contract
  • a business logic contract that implements the libraries

Question:

  • can we use ENS, or more specifically it's approach with registry, owner and resolver, as "upgrade tool", by publishing a "name" for the contract, and letting the resolver point to the currently valid business logic contract?
eth
  • 85,679
  • 53
  • 285
  • 406
wavekiter
  • 157
  • 8

2 Answers2

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-facing contracts to effectively take over. They would refrain from hard-coding the contract address and use a logical name instead, much like DNS. Then they would use the Ethereum Name Service to resolve "live" contract address(es).

http://ens.readthedocs.io/en/latest/introduction.html

Rob Hitchens
  • 55,151
  • 11
  • 89
  • 145
  • are you aware of an example code implementing this? – wavekiter Feb 10 '17 at 03:08
  • No. My impression is its so new the best discussions are about the merits of proposed improvements, etc. In practice, it might be better to deploy your own contract that just returns an address in a way you understand clearly; to achieve a similar result. This doc does a reasonable job of explaining the vision for the global scale solution: https://medium.com/@_maurelian/explaining-the-ethereum-namespace-auction-241bec6ef751#.mkdqtklv5 – Rob Hitchens Feb 10 '17 at 03:42
0

Yes, an ENS domain can be updated to point to a new address if a new contract needs to be deployed for updated business logic or code fixes. However, the data storage of the old contract will stay with the old contract.

To prepare for this possibility, it would be ideal to code the original contracts to have some sort of "freeze" functionality, where the contract can be put into a locked-down, read-only state. Then any new contracts could point to the older contract (a "parent"), and could include logic to read the old/existing state off the older contract (using its public access methods), as a means to bootstrap the data of the new contract.

The MiniMeToken takes this idea (though without freezing the original contract), by having logic that if a query transaction is looking for data further back than the history of the current contract goes, it knows to go to the parent contract to look up that history.

MidnightLightning
  • 2,988
  • 16
  • 28