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.
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ā.
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.
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.
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.
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?
The lock cannot be overriden. It exists to deny even the owner the ability to change a record.
Well played: the extent of a corporationās competence to enter into contracts depends on the scope of the power its charter grants.
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.
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!
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: https://app.ens.domains/name/ens.eth/subdomains
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
Do we know how this distribution compares to other somewhat similar DAOs? Are we in the middle of the bell curve on this, or are we a deviation?