RFC: upgradeable contracts addressed by ENS name


#1

The rough idea is to implement a router pattern or similar (providing upgradeability to the contract) as an ENS resolver. It should create a convenient and standard way to address, call and manage a contract’s current version by ENS name.

Before I start spending time on implemtation, I would very appreciate any feedback.
Especially if it is a bad idea and should not work :wink:


#2

How about using subdomains and simple (numerical, non-semantic) version numbering? So if your ENS domain was mycontract.eth then:

  • mycontract.eth would resolve to the latest version of the contract
  • 1.mycontract.eth would resolve to version 1 of the contract
  • x.mycontract.eth would resolve to version x of the contract

This would avoid the need for a custom resolver or complex upgrade logic. You could also expand it to provide named versions (beta.mycontract.eth) if required.


#3

I would not like to see any version information encoded in subdoman, because there are other stuff what subdomains can be used for.

A version information has no direct analogy in DNS system and thus should be expressed in ENS in some other way in order to prevent ambiguity.

EXAMPLES:

  • myfoobar.eth - a root domain for organization
  • www.myfoobar.eth - a swarm hash of the orga’s site.
  • shop.myfoobar.eth - a decentralized market place (an upgradable contract).
  • owner.user.myfoobar.eth - EUL-alias of the owner (EUL-ethereum universal login)

let’s try to add a version information:

  • myfoobar!0.eth - an initial resolver for the organization’s domain
  • shop!2.myfoobar.eth - a version #2 of decentralized market place.
  • owner!0.user.myfoobar!1.eth - EUL-alias of the very first owner of 2nd orga version.

the ‘!’ character is not allowed in DNS names, but it makes clear
it would be better to express version information in other way than in subdomains.

Do you possibly know any ENS standarts or at least ideas to express a version information?


#4

I would not like to see any version information encoded in subdoman, because there are other stuff what subdomains can be used for.

Purely numerical subdomains? Perhaps, but it’s a use for ENS as good as any other. Or if some sort of identifier was an absolute requirement then you could prefix the number with ‘v’, ‘version_’ or whatever you wanted.

In your example, if you purchased myfoobar!0.eth, what would stop someone from purchasing myfoobar!1.eth?


#5

hmm… you are right, I am wrong.
Version identifier can’t be part of the main domain.
But as part of a subdomain is ok, right?