One of the things we’ve been doing at Enscribe is looking at onchain release management for smart contracts, capturing version information in ENS records.
We’ve published an initial post on this subject, would love to get feedback from the community on what we’ve covered.
We’ll be following up with approaches for proxy contracts too.
We believe that ENS can be a key component of onchain versioning for contracts and we’re hoping with feedback from the community we can move the space forwards.
Looks good! What I’d love to see is a dedicated contract versioning registrar. This could be on a special-purpose namespace that isn’t resolvable directly by clients (eg, something like a _version TLD) or to start just on a regular TLD. The registrar would let you register a subname, but retain control over it; for subnames you own you could publish a new version, which would allocate the next available integer to the contract address supplied, as well as updating the latest alias to point at this deployment.
That way, you could register enscribe.contract.eth and publish a new version, which would be automatically numbered as 42.enscribe.contract.eth and latest.enscribe.contract.eth. Users could either point at the latest release or point to a specific version, benefiting from the guarantee of immutability.
An additional layer of indirection might be even better - allow people to register an org, with subnames for individual contracts.
Glad it resonates with you @nick.eth
Are you suggesting that a ‘centralized’ Registrar be created that will take care of automatically setting forward resolutions (i.e. the next version and the ‘latest’ tag) when a contract is deployed?
For example, with a name like `42.enscribe.contract.eth`, the `contract.eth` 2ld needs to centralized so that only the correct org owner can register their org’s subname.
What is also important is figuring how the orgs will prove the ownership of the contract irrespective of whether the contract is `Ownable` or not. This is because we want this Versioning Registrar to work for all the contracts without anyone trying to game the system (like tag a wrong contract under their org)
That’s right. And you would not grant ownership of x.contract.eth or version.x.contract.eth to the owner of the contract, because otherwise you cannot enforce guarantees around immutability - all updates would be handled via the registrar.
I don’t think this is a problem you need to solve. Someone can name an arbitrary contract that isn’t theirs if they want - no harm is done.