On Property rights and threat models for ENS

Due to the recent situation I’ve seen some people raise concerns on property rights and threat models to ENS in general and .eth names. How can the personal beliefs of the Delegates affect ens names? Can a name be taken away from a person if they go against the values of the majority of delegates, or even a vocal minority? What if Delegates are compelled by authorities to act on a given set of names?

This is an evolving document and I welcome feedback and clarification.

1) Your registered .eth names cannot be taken from you

Per EP1 the .eth controllers and price oracles have been passed to the DAO. This grants the DAO powers like setting the price oracle or setting what the top level ETH resolves (like any subdomains have their own info attached to it, top levels domains like eth can also have. It’s not very used).

The ENS DAO does NOT control the ENS root yet. That in theory would grant it control of any top level domain, but .eth names are locked and cannot be changed.

2) The constitution is not a guarantee, but exists to give legitimacy and framework to future code changes

While article I of the ENS constitution reads: “ENS governance will not enact any change that infringes on the rights of ENS users to retain names they own, or unfairly discriminate against name owners’ ability to extend, transfer, or otherwise use their names.” it is intentionally a mutable constitution: “Article V. Amendments to this constitution by majority vote. Any change may be made to this constitution only by two-thirds majority and at least 1% of all tokens participating.”

The 1% quorum on article V is intentionally low, with the idea that there would be some initial changes and then we could increase it. In Snapshot the proposal with least participation so far was voted by 1.6 million tokens, while the largest one was 4.8. The Constitution was ratified with 15M tokens. On With Tally, which is unchain, the two executed proposals got over 3M votes. The top 10 delegators have, combined 2.5 M votes delegated to them, meaning that about five people have enough votes to reach quorum for a constitutional amendment.

The constitution should always be used for legitimacy, but not as a substitute for code: if we want a hard guarantee of something we need to put it on chain, not purely as a social aspect.

In a way, the code, the tokens, the constitution represent a balance. The code has it’s own rules and the Constitution has their own edicts. If they are in sync, the community is happy and there’s a balance. If they are in sync then the community can declare one or the other illegitimate and attempt to fix or fork it. If say, the code gets broken somehow and names are locked forever, or if someone buys enough tokens to pass a particularly unpopular amendment, the community last resource is a fork–abandon the current codebase and move forward with another. This would be painful and split the community in half, but having that option is better than the project dying and it’s a good last resort of blockchain governance.

You never know when the community will split over something like what happened last week. If we want to make sure we have stronger guarantees for our core values we must:

  • Protect the code by making sure that parts we do not want to change are locked
  • Protect the Constitution by increasing the quorum after we are happy and decide against further amendments.
  1. Threat model. What is the worst that can happen?

Given the information above, here’s a scenario: if someone can buy enough tokens to pass a proposal on the DAO, they can also pass an amendment on the constitution. An attacker could do these things:

  • While they can’t take names from people, they can increase rent so that names become too expensive to maintain or change the token the names are paid for to a token that is only accessible to a specific set of people (let’s say requires KYC in the US)
  • An attacker could change the registration premium oracle in a way that it only accepts a specific token or NFT so as only a specific pre selected community could take them.

Now those are all hypothetical scenarios and we have to take in consideration the risk of locking up the code too soon and losing important features like L2 support or the new cheaper DNS integration. Some of that can be mitigated by having a time lock, so that if we can see the new rent is going up in 1 month, people have time to renew their names or abandon the project. What I am proposing here is simple:

We need to reevaluate possible attack vectors and mitigate them sooner than later.

Some relevant contracts:

Questions that I haven’t been able to answer:

  • Where is the “lock” in .eth happening? (edit: above)
  • When we change rules like the temporary premium price, in which level is it? Can it be changed arbitrarily?
  • What else can it be changed? If we can change the rent to only accept ENS, how flexible is the system still?
6 Likes

The root node is owned by root.ens.eth, which enforces access restrictions on who can update individual TLDs.

  • When we change rules like the temporary premium price, in which level is it? Can it be changed arbitrarily?

This is done by replacing the price oracle or the registrar controller. The DAO can make arbitrary changes to both of these contracts.

3 Likes

This is likely to be deemed to be an ultra vires act, as you can’t tie the hands of a future body to act that possess the same powers, pursuant to the Constitution.

4 Likes

Thanks @AvsA for this concise summary. It was really necessary since a lot of misinformation floating around is about “ENS will take your names based on your views”.

2 Likes

I have started a repo for threat analysis to DAO structures, starting with ENS. It’s in Python. I’ll update where there are any mentionable findings.

4 Likes

I ran some very basic simulations to access if the DAO can be ‘taken hostage’ by a select number of delegates by triggering on-chain votes with sufficient quorum of 1,000,000 votes. @AvsA pointed out that the top 5 delegates make up for sufficient quorum. I generalised the process to N number of delegates (‘colluders’) over the list of top 50 delegates scrapped from Sybil.org. The top 20 delegates are listed below for quick look-up:

1	brantly.eth		    5.362		367162
2	coinbase.eth		4.840		331375
3	nick.eth			4.149		284107
4	she256.eth	 	    4.065		278319
5	cory_eth			4.000		273907
6	avsa.eth			3.245		222209
7	lefteris.eth		3.202		219252
8	rainbowwallet.eth	2.986		204457
9	fireeyesdao.eth		2.493		170668
10	mikedemarais.eth	2.418		165575
11	griff.eth		    2.417		165522
12	simona.eth		    2.342		160346
13	ChainLinkGod		2.197		150455
14	superphiz.eth		1.996		136646
15	imtoken.eth		    1.719		117721
16	keikreutler.eth	 	1.349		92342
17	maaria.eth	   	    0.975		66762
18	devdao.eth		    0.913		62496
19	marspunks.eth		0.887		60748
20	metaphor.xyz		0.882		60418

The full set of results can be found here. To summarise:

colluders  threats
3          0
4          302
5          17920
6          478783

‘colluders’ == number of rogue delegates
‘threats’ == number of possible combinations of rogue delegates with > 1,000,000 votes in total

These results suggest that a vote can be triggered by as few as 4 not-necessarily-top delegates. In comparison, in a utopic world where all 50 delegates have equal votes, quorum cannot be reached unless a minimum of 9 delegates collude.

In further detail, in each case I looked for reoccurrence of delegates across all combinations of attacks and gave them a threat score (see below)



All three cases put together show the expected trend (see below). Notably, when N > 25, ‘colluders’ effectively become ‘agreers’ since now the majority decides the fate of the protocol.

3 Likes

Thanks @AvsA for starting this thread!

root.ens.eth is owned by the multisig, so I’m still confused as to whether or not the .eth lock can be overridden by the multisig (or governance, in the future), even via a Constitution change or using other extraordinary measures.

Nick, can you help to clarify this?

I think that .eth cannot even be changed by the root, that’s what @James and @nick.eth said in this thread: [EP1] [Social] Proposal: Transfer ENS Treasury and Contract Ownership

Importantly, control over the ENS root will remain with the ENS root multisig for now. Control over the root allows for the creation and replacement of ENS top-level domains (TLDs) other than .eth (.eth is locked and cannot be changed by the root).

I get that. But, this being Ethereum, we can never be sure that something that was changed after the smart contract was deployed is irreversible unless we can look at it on-chain and understand that it’s forever immutable. I am just trying to understand how the “lock” was implemented and get totally confident that it can’t be reversed by the multisig.

2 Likes

This is a fantastic comment! Considering that the delegate power will always be a power law, what do you think is a good quorum to raise the bar?

3 Likes

The lock cannot be overriden. It exists to deny even the owner the ability to change a record.

2 Likes

Well played: the extent of a corporation’s competence to enter into contracts depends on the scope of the power its charter grants.

1 Like

More than that: Canonical definition of ultra vires directly decides on the scope of limiting power by eliminating all acts that violate causality principles, for example, new laws cannot be enforced on non-existent entities (in the future). Beyond the trivial ultra vires, the charter can of course set their own ultra vires.

Does this mean that the keys are burnt for this contract? Other than that, a code can always be reversed unless there is a one-way hashing in there somewhere that explicitly prevents this.

The quorum question isn’t easy to answer if you are looking for one consistent value. if you are willing to adopt a dynamic value, then it is easier. The reason: the delegate vote distribution (as well as threat score) will always be a power law (Rankγ) like you said, but it could be of different index γ which decides the slope. In utopia, γ = 0. In real life, you’d still want this value to be as low as possible and the power law to be as flat as possible. Flatter power law will require more number of colluders to attack and therefore decrease the likelihood. Having said that, the delegate vote count is not fixed, so the power laws are always shifting. Currently, threat to ENS starts at 4 colluders and Brantly, Coinbase, Nick feature in roughly 80%, 65%, 40% of these hypothetical attacks respectively as a reference. What number do you think is safe? It is a dynamic question (γ is varying) and should be treated as such. Beyond that, even if you flatten the power law, there will still be a finite number of colluders who could attack the protocol.

However, it doesn’t hurt to run a simulation with a higher quorum and with the current delegate vote distribution, a quorum of 2,000,000 will require a minimum of 7-8 colluders. This is obviously far better than 4 colluders but not very safe in a general context. Other list of values below:

quorum       min_colluders
1,000,000    4
2,000,000    7-8
3,000,000    13-14
4,000,000    27-28

Having looked at these values, quorum should be raised to 2,000,000 in my opinion. The “attacks” are only attacks on quorum so relatively safe and don’t need a hyper-strict criteria. I will run more simulations for a full on-chain voting. If I find something meaningful, I’ll go ahead and attack the protocol. You know where to find me. :smiling_imp:

Contracts don’t have private keys. The code limits what can be done with the resources it manages.

Can the smart contract implementation that contains the lock be replaced with a new implementation?

Would it be possible to document the Ethereum addresses for all of these smart contracts so we can get some independent eyes on them?

Thanks!

1 Like

Registrar contract: 0x57f1887a8BF19b14fC0dF6Fd9B2acc9Af147eA85
Controller contract: 0x283Af0B28c62C092C9727F1Ee09c02CA627EB7F5 (original post is missing this @AvsA)
DAO Access contract: 0x323A76393544d5ecca80cd6ef2A560C6a395b7E3
ENS Root contract: 0xaB528d626EC275E3faD363fF1393A41F581c5897 (this is what you want I think)
Root Multisig contract: 0xCF60916b6CB4753f58533808fA610FcbD4098Ec0

No.

Avsa is putting something together; for now, you can see them as subdomains of ens.eth: ENS App

I’ll be continuing the threat analysis in greater detail on this dedicated domain: ens.inplco.eth which essentially links to this mirror: ENS - Interplanetary Forum. I’ll keep updating here with meaningful findings but not in full detail

CC: @nick.eth, @AvsA