Governance of the .ETH namespace and ENS foundation


#1

I’ve been thinking a lot about how to handle rent fees and where they should go to. We’ve solved it in the current registrar by burning fees and locking up ether but it seems new registrar discussions are increasingly in favor or having fees go to a main foundation. It’s important to analyze the checks and balances on that institution to make sure they remain relevant and don’t start any rent seeking behavior in the future. I don’t have a solution here but I would like to start with a few premises. The premise 0 of all these is that we have a single entity, let’s call it ENS Foundation, that gets all the automatic fees:

  • Forking ENS is the ultimate measure users can adopt to “fire” the ENS foundation. Anyone can fork ENS with no fees or fees to other entities, which effectively removes all the money to the foundation if they do some behavior considered bad
  • Forking is a behavior that reduces overall utility of all namespaces. If there’s only one ENS, everything is simpler and easier. If there are multiple competing ENSs, then the usability starts to require more complexity. If one ENS fork becomes as big as the main one, then suddenly the usability creates large problems, as we need in practice to create a new namespace for namespaces (foobar.eth.1 vs foobar.eth.2)

Therefore the goal of ENS governance should be:

Add mechanisms that allow people to voice their grievances on ENS foundation, and to be able to eventually replace it without needing to fork ENS itself.

Of course, these are similar governance challenges than ethereum itself, but I would say we have some unique opportunities here to experiment on better systems. I would argue that the most valuable ENS should be the only one that needs to exist, but there are two caveats:

  • Any mechanism for finding the value of a name can be abused (people overbidding their own domains) if that has secondary benefits, such as giving you voting power
  • An ENS system in which names are more expensive is not necessarily a better one

I don’t have any proposal on how to solve this governance system but I have a few suggestions on what it looks like:

  • ENS contenders are mostly competing for the “eth” registrar, not the ENS contract itself, so we should encourage all contenders to somehow be built using the same mechanisms, specially under the “eth” namespace. So contenders to replace the ETH should all be built using a registrar of something.eth and they would bid to go up and replace the main namespace.. We could even generalize it further and say that if some very good solid solution emerges in a few years, it could even replace the root registrar.
  • Fees should be locked for a few years and any new contender should only start getting fees generated at least one year after being active, but preferably only get them even later, so that if someone manages to abuse and hijack it, the market should react accordingly and the fees by then would be much smaller

So here’s the basic scaffolding I see for ETH namespace governance:

  1. Any contender for the ETH namespace governance should register a name on the currently active namespace and deploy a sub registrar there, that can be already used instantly
  2. ???
  3. Once step 2 decides on a new registrar becomes the active one, but current name holders are grandfathered in and have 2 years to migrate to the new one
  4. All new fees generated to the new registrar are locked for one year before being released, so effectively the new registrar will take up to 2-3 years to receive the full profits of being the new registrar, and by then if it’s seen as a bad entity, people can either try to change it again or fork ENS in its entirety

As you can see, the governance is 75% solved, I just need some help figuring out the step 2. :wink:


#2

I think your thoughts on centralisation risks, and the corresponding balance - the ability to fork - are spot on.

However, I don’t think we need a mechanism built into ENS to handle this. Anyone can already fork ENS by deploying their own ENS registry. If the current registry is a poor enough solution, it should be easy to convince people to switch.

I’m strongly against any mechanism that could suddenly hand off control over the entire namespace to a new party - it’d be far too easy to manipulate.


#3

I have to agree with Nick on this, the ability to hand off power depends on community governance which is insanely dangerous. The forking of ENS is easy enough, if one thinks they can do it better, they should attempt to. If they really did do it better they should have no issue in gaining the necessary network effects.

Also I question what issues other than rent would get someone to fork ENS.


#4

I don’t mind a central authority collecting rent, I prefer the whole system to be open-source, democratic, accessible, secure, I would like to see the funds going to help keep the system viable, workable, accessible, etc


#5

I really like the spirit of this but think that there are many general and practical questions we could ask about adding mechanisms for people to voice their grievances and which would also come before replacing ENS. For instance:

  • Are the mechanisms to voice grievances there for anyone or end users more specifically?
  • How might different groups of people (individuals and communities of end users, enterprises, states) voice different types of grievances on equal footing?
  • What else can people do besides voice grievances? Can they help drive consensus from the periphery to core decision making? How will this be made fair?
  • What determines how much input someone can give? What makes it meaningful?

If rent fees go to the ENS foundation I assume it would carry the responsibility for enabling as much consensus building and participation among users/developers as possible, as well as upholding technical standards and relevant innovations. There are lots of pitfalls here, without even considering the possibility emerging of foundation rent-seeking and subsequent ENS contenders. Failure in these social and technical processes may provide enough motivation to replace or fork, even if the foundation’s motives remain unaffected by the new income. Critiques of ICANN’s At-Large community come to mind here, which, however accurate, suggest what not to do.


#6

To be clear, the purpose of this post is to propose limitations on how you can hand off the control: mainly, that a new eth namespace owner would only control new registrations and renewals and that it would be purposefully slowed down.

If you fork a completely new ENS, you have none of these guarantees.

But having multiple competing forks is also bad so I think it’s worth exploring the possibility of adding internal mechanisms to allow updates so that forking is not needed.

By “voice grievances” I’m just using the expression for the idea to allow internal mechanisms to make the system better from the inside out, not proposing a literal forum.


Now, of course I understand the main point that simplicity is queen and we don’t want to add unnecessary complex code, but I think it’s worth exploring the idea, before any code is done. I would love to, long long term, see ENS replace ALL naming systems, including ICANN, but that’s not going to happen if it has a single central authority behind it. That’s why I prefer to add an internal system where people can experiment in subdomains, which then can be eventually migrated to ETH namespace, which then can be migrated to the root registrar which then can be used to replace all registrars :wink:

But of course, I will totally accept the conclusion “not worth the added complexity”, AS LONG as we actually think about it first


#7

You can build those restrictions into your fork, though, if you think it’s necessary.

It’s not clear to me how this would work - can you elaborate? How would you ‘migrate’ from something as a subdomain to using it as a main domain?


#8

I mean this sounds like an insane amount of complexity which would bulk up the registrar.


#9

I’ve given more thought about the feedback and I’d like to distill the initial proposal to add a few practical suggestions.

The owner of the “.eth” namespace should be a simple contract with the following restrictions:

  1. The contract has a “resolver” that pings a “resolver contract”, a “receiver” address for which it forwards the funds and a “manager” that can make changes to these three variables. The resolver would be the contract containing the new resolver logic and the other two would initially be the same address, set to a multisig wallet held by the ENS foundation, but that could change in the future

  2. Manager cannot change “resolver”, “manager” or “receiver” immediately, only schedule it to be changed in a future date (minimum 6 - 12 months maybe?)

  3. Funds are not immediately redirected to the “receiver” and instead are held for some long time (1-6 months maybe?) until they can be sent

  4. If any funds by domain holders are locked in, if the manager or receiving address changes, they should be able to unlock their funds and not renew their domains

This gives a few guarantees to domain holders, (basically the ones they already have now) that the ENS foundation cannot turn evil and take their domains with them overnight. That if they intend to do something bad, everyone will have time to create a new ENS fork and deploy the infrastructure to replace it. That if they change the registrar, it only affects renewals and new names, not current held names.

If the ENS foundation wants, in the future, to replace it’s multisig with a more democratic process, it’s encouraged to do so, but I’m not proposing it do it right away. The behaviors the smart contract prevents are basic ones that a well run and responsible organization would not do any way so it’s not a hinderance, but we are using smart contracts to enforce them and to give the public more guarantees and reasons to trust the system – how it should be.


#10

Do you mean ‘registrar’, here? A resolver resolves names to resources, and isn’t something that the .eth registrar controls.

Perhaps instead, the contract could allow the user to pre-pay rent, and allow the receiver to only claim that portion that has already been ‘spent’ - so if a user deletes their domain halfway through the registration period, they are guaranteed a 50% refund.


#11

I think the main overarching theme I mean is basically that whatever model we end up with the eth namespace registrar, or whoever gets the fees, we should definitely start it with a contract that gives domain owners a few guarantees that, if ENS foundation suddenly turns evil, they cannot takeover control of all names overnight, that domain holders will be able to keep their names for at least another year after any change in the rules, that they can unlock any funds previously held, etc

If we start on that solid basis, I’m much less worried on who and how the fees are made. Any “emergency situation” should be dealt on the root multisig (which should be independent of the ENS foundation).


#12

Yup, sounds like a reasonable plan to me.


#13

Wouldn’t the ideal guarantee here be that the ENS foundation by its own code cannot turn evil ever?

Also what do you mean with “funds previously held”, wouldn’t this be dependent on how we decide to solve rent and what to do with those funds? I remember a discussion about burning, would we need to keep funds in escrow before burning or whatever?


#14

Making the foundation be code is easy and it probably will be some sort of multisig. But which code it should be is the complicated governance question.

What I’m proposing here is not to solve the governance big problem, but to add minimum guarantees on the code itself. Doesn’t guarantee good governance, but limits the effects of bad governance.


#15

So we are on the same page here, I was not under the idea that the entire foundation should be represented through code, but that the ENS code itself guarantees that we can do no evil. For example stealing domains etc etc. This should be relatively easy to guarantee in code.


#16

as much as I enjoyed the creativity and stimulating discussion, I would like to remind myself the entire proposal start from an assumption that we’re better off by having “ENS Foundation” style holding the rental fee and investing/using for x,y,z than burning it.

While burning/taking coins out of circulation have an immense deflationary effect on long run, it’s hard for me to imagine how centralized authority could put the fund in a better use than such an elegant democratic; indirectly n% interest to all ETH holders


#17

One discussion that @nickjohnson and I had was to burn a certain % and use the rest for arbitration incentivization, I don’t know what the current status on that decision is as it was just a light conversation. I am sure we will revist that soon. I am for burning a certain % but would disagree to burning the full amount.


#18

I think there’s a commons problem here: there’s no doubt that ENS names would be more useful for everyone if there were active funded developers, sponsored conferences and meeting groups, instead of the current status quo where it’s a side project of multiple developers with other priorities too. And while funds being burned benefit all eth holders, they don’t do as much to benefit ENS as a whole. But how to spend the money better and who gets to make that decision is a big problem.

Which is why this proposal exists: a ENS foundation should have limited power decided by code, and if ultimately the community feels they are abusing that power or not doing a good job, they should be able to fork the ENS code and have funds burned instead. There’s probably some intermediary governance steps between “it’s us or fork off” but it’s hard to solve them.


#19

what do you mean by arbitration incentivization?

Indeed Alex that is very useful and much needed today, but when we get to a consensus about 1) name release structure/auction 2) ENS allocative efficiency scheme /renting mechanism, what else the ENS foundation will need to do?

There will be some work to be done but how resource intensive is that,

  • Developers: YES active work will be needed
  • Events: let it be sponsored by market players, like ENSLISTING, NameBazaar, DomainSale etc (you know better than I am, how much Ethereum foundation spent on events like EdCon, DevCon etc…? I assume pretty much as any other sponsor…)
  • Marketing & Business development: maybe something like ICANN gTLD fee
  • ?? what else we’re missing

according to @nickjohnson post https://medium.com/the-ethereum-name-service/state-of-the-ens-week-6-5597c62249bc just the fund lost due to failed reveals ~5000 ETH might be enough… no? if we have to have ENS Foundation and donation/sponsorship/subsidy of let’s say Ethereum foundation all wasn’t an option, then maybe we can use that funds of the failed reveals for ENS foundation?? maybe… and if we have to definitely the proposal of Alex and discussion afterword here create a solid ground for governance of it

I personally wish to have as simple as possible ENS, truly smart autonomous, with minimum interventionism, and not enough on stake for a malicious agent to even try… these all harder to design but easier to run.

btw, guys would you be so kind to refer me to a place that has discussions about not burning all fee -if there is a thread about that- I would like to get


#20

The fact that for ENS dispute resolution we need to incentivize community arbitrators to actually do the resolution work. We were considering doing this through fees we take in.

This seems almost a little naive, the point of the ENS foundation is not only to build it and then ditch off, there is a lot we need to maintain, we need to drive adoption, maybe add new features. DNSSEC will take a while until we have various registars who are integrated. It’s not just “build a registar and begone”.

Why go beg for sponsors if there is an effective way for the ENS foundation to be able to take in funds and give back to the community through various events?

This assumes that the next ENS registar will function the same as prior, as far as I know, revealing will not be the same so funds cannot be lost. Additionally using lost funds would incentivize us to build the registrar as hard as possible and make the UX as bad as possible so users lose funds. Doesn’t seem all that ideal to me.

The disussion was in private chats, so nothing of that has been discussed in the public yet really.