NameWrapper updates (including testnet deployment addresses)

jefflau.eth · September 20, 2022, 10:21am

Following the July audit, I am very happy to announce that today we have deployed the new suite of ENS contracts to the Goerli test network. This is an important step for the ENS protocol to finally release the new suite of contracts to mainnet, which powers the next version of our app as well various community projects that are also in the works.

The new contracts that have been deployed are:

NameWrapper
New .eth Registrar Controller
New Reverse Registrar
New Public Resolver
Exponential Price Curve Oracle
StaticMetadataService

Discovery mechanisms

As usual these contracts can be discovered using ENS directly:

NameWrapper - ens.resolver(namehash('eth')).interfaceImplementer('0x019a38fe')
New .eth Registrar Controller - ens.resolver(namehash('eth')).interfaceImplementer('0x612e8c09')
New Reverse Registrar - ens.owner(namehash('addr.reverse'))
New Public Resolver - ens.resolver(namehash('resolver.ens.eth')).addr()
Exponential Price Curve Oracle - ethController.prices()
StaticMetadataService - nameWrapper.metadataService()

Addresses Sepolia 30/6/2023

NameWrapper - 0x0635513f179D50A207757E05759CbD106d7dFcE8
New .eth Registrar Controller - 0xFED6a969AaA60E4961FCD3EBF1A2e8913ac65B72
Reverse Registrar - 0xA0a1AbcDAe1a2a4A2EF8e9113Ff0e02DD81DC0C6
New Public Resolver - 0x8FADE66B79cC9f707aB26799354482EB93a5B7dD
Exponential Price Curve Oracle - 0x6810dbce73c67506f785a225f818b30d8f209aab

Addresses Mainnet 29/3/2023

NameWrapper - 0xd4416b13d2b3a9abae7acd5d6c2bbdbe25686401
New .eth Registrar Controller - 0x253553366da8546fc250f225fe3d25d0c782303b
New Reverse Registrar - 0xa58e81fe9b61b5c3fe2afd33cf304c454abfc7cb
New Public Resolver - 0x231b0ee14048e9dccd1d247744d114a4eb5e8e63
Exponential Price Curve Oracle - 0x7542565191d074ce84fbfa92cae13acb84788ca9

Addresses Goerli 14/3/2023

NameWrapper - 0x114D4603199df73e7D157787f8778E21fCd13066
New .eth Registrar Controller - 0xCc5e7dB10E65EED1BBD105359e7268aa660f6734
New Reverse Registrar - 0x4f7A657451358a22dc397d5eE7981FfC526cd856
New Public Resolver - 0xd7a4F6473f32aC2Af804B3686AE8F1932bC35750
Exponential Price Curve Oracle - 0xE4354bCf22e3C6a6496C31901399D46FC4Ac6a61
Static Metadata Service - 0x269eb6AeDeEa030B96354Bc73f0A09eae3546e23

Addresses Goerli 3/3/2023

~~NameWrapper - 0x23d86f0bf4900978B191378B134519371Da52f75~~
~~New .eth Registrar Controller - 0x5642D2E447567672723512a0D7b2E85994BB2FEb~~
~~New Reverse Registrar - 0x4f7A657451358a22dc397d5eE7981FfC526cd856~~
~~New Public Resolver - 0x342cf18D3e41DE491aa1a3067574C849AdA6a2Ad~~
~~Exponential Price Curve Oracle - 0xE4354bCf22e3C6a6496C31901399D46FC4Ac6a61~~
~~Static Metadata Service - 0x269eb6AeDeEa030B96354Bc73f0A09eae3546e23~~

Addresses Goerli 31/1/2023

~~NameWrapper - 0x060f1546642E67c485D56248201feA2f9AB1803C~~
~~New .eth Registrar Controller - 0x603A4F2e7615d0099244496883062bA2eFBbeaf0~~
~~New Reverse Registrar - 0x9a879320A9F7ad2BBb02063d67baF5551D6BD8B0~~
~~New Public Resolver - 0x19c2d5D0f035563344dBB7bE5fD09c8dad62b001~~
~~Exponential Price Curve Oracle - 0x446C8f1ce718D100a2018B887416cDd4A213E95c~~
~~Static Metadata Service - 0x3848564e209f23351EDD1997c95468e819f47dCa~~

Addresses Goerli 13/1/2023

~~NameWrapper - 0xEe1F756aCde7E81B2D8cC6aB3c8A1E2cE6db0F39~~
~~New .eth Registrar Controller - 0xb7A1f9e633fdeaAa2ec44bE00a61a7Db9a733D70~~
~~New Reverse Registrar - 0x9a879320A9F7ad2BBb02063d67baF5551D6BD8B0~~
~~New Public Resolver - 0x2800Ec5BAB9CE9226d19E0ad5BC607e3cfC4347E~~
~~Exponential Price Curve Oracle - 0x446C8f1ce718D100a2018B887416cDd4A213E95c~~
~~Static Metadata Service - 0x3848564e209f23351EDD1997c95468e819f47dCa~~

Addresses Goerli 9/2022

~~NameWrapper - 0x582224b8d4534F4749EFA4f22eF7241E0C56D4B8~~
~~New .eth Registrar Controller - 0x9C51161bA2FB02Cc0a403332B607117685f34831~~
~~New Reverse Registrar - 0xD5610A08E370051a01fdfe4bB3ddf5270af1aA48~~
~~New Public Resolver - 0xE264d5bb84bA3b8061ADC38D3D76e6674aB91852~~
~~Exponential Price Curve Oracle - 0x446C8f1ce718D100a2018B887416cDd4A213E95c~~
~~Static Metadata Service - 0x9DAfDe161D690d9e18f8021c392B0dBCBf0Cf8cB~~

Addresses Ropsten

~~NameWrapper - 0xF82155e2a43Be0871821E9654Fc8Ae894FB8307C~~
~~New .eth Registrar Controller - 0xa5627AB7Ae47063B533622C34FEBDb52d3281dF8~~
~~New Reverse Registrar - 0x806246b52f8cB61655d3038c58D2f63Aa55d4edE~~
~~New Public Resolver - 0x13F0659Ee6bb7484C884FEeFb7F75C93951ef837~~
~~Exponential Price Curve Oracle - 0x0e765d28FABf9E219770CAb07D64967451026bD7~~
~~Static Metadata Service - 0x3bAa5F3ea7bFCC8948c4140f233d72c11eBF0bdB~~

Ropsten is no longer being updated since it has been deprecated by Infura, please use Goerli.

Developer Details

We are no longer using a different reverse resolver for setting your reverse name, it now uses the PublicResolver. The .eth controller will now be a controller of the NameWrapper and not a controller of the Base Registrar contract (.eth owner). This is because all registrations will now be wrapped by default and the registration functions on the .eth controller go through the Wrapper, which then call the Base Registrar.

The new controller now lets you set additional records in the register function, meaning you can register and create your records at the same time. It uses resolver.multicall underneath, so you can encode the transactions in the same way. It also optionally allows you to set your reverse record

On the discovery mechanisms, we have added the NameWrapper interface to the .eth resolver and the address can be discovered by calling interfaceImplementer() with the wrapper id 0x019a38fe .

The new contracts have not been hooked up to our V2 app (app.ens.domains), so you will largely be unable to interact with these contracts using our UI. We will announce when the V3 app has been deployed on testnet, and once that happens we welcome the community to help us thoroughly test the new app and contracts

Next steps

There are a few things that need to be done before we can deploy these to mainnet, a thorough testing on testnet, internally as well as in the community. Once we are happy with that, we will be in a position to deploy the contracts to mainnet and activate them via a DAO wide vote.

Executable proposal has been posted: [Draft] [Executable] Activate new .eth controller and new Reverse Registrar

jefflau.eth · September 30, 2022, 6:03am

We have redeployed these contracts to testnet with some minor changes. I’ve updated the addresses above

serenae · October 5, 2022, 1:34pm

Hey @mdt or anyone who knows:

I was playing around with these new contracts and was wondering about the metadata service. Is that not expected to be functional yet, or is there a separate Goerli deployment for it? Because it doesn’t look like the ens-metadata-service.appspot.com/name/0x{id} endpoint works currently.

Will the same metadata service be used for both the current NFT contract and the new NameWrapper contract? I ask because the route /name/0x{id} returned from the StaticMetadataService doesn’t have a contract address in it, and we know that the NFT token ID for .eth 2LDs will be different in the old vs. new contracts. So just wondering how all that will work, thanks!

mdt · October 5, 2022, 3:05pm

Namewrapper address and interface is not updated in metadata service yet. I will be updating it very soon.

jefflau.eth · October 7, 2022, 4:30am

Redeployed the NameWrapper, Controller and Public Resolver to Goerli. Addresses updated in the above post.

Also updated the NameWrapper interfaceId

Edit: Since Ropsten has been deprecated from infura, we have decided not to deploy the edited contracts to ropsten.

jefflau.eth · October 19, 2022, 11:44pm

Edited the NameWrapper interfaceId again. We were accidentally using the interface from the NameWrapper instead of the INameWrapper

lcfr.eth · October 22, 2022, 6:19pm

Hey @jefflau.eth @nick.eth etc

I’ve been playing with the wrapper and realized that when a .eth 2LD expires (ERC721) the ERC1155 is still transferrable / tradable / sellable until or unless the .eth 2LD (ERC721) is re-registered.

As getData sets all fuses to 0 (false) if block.timestamp > expiry.

I think it should set CANNOT_TRANSFER to True instead of setting CAN_DO_ANYTHING?

        function getData(uint256 tokenId)
        ...
            if (block.timestamp > expiry) {
                //fuses = 0; // allow transfers on expiration
                fuses = 4; // CANNOT_TRANSFER ?
            } else {
                fuses = uint32(t >> 160);
            }
        ...

My concern here is that people can register .eth 2LD name’s for 1 month or wrap and let any currently owned .eth 2LD expire - then still be able to sell the ERC1155 on market places after the name expires until someone decides to manually re-register the .eth 2LD.

The 1155 could be traded many times before that happens or someone realizes. Then the person who “paid” for the name will get rugged when a new person registers it again and the token is burned and finally transferred away from the current “holder”.

my foundry test : gist:9b3e75ecc77fdf74a4380e89404f015d (github.com)

jefflau.eth · October 22, 2022, 9:07pm

Hey @lcfr.eth ,

Thanks for this report, it’s very useful to us having you test our contract. There’s a couple problems with this solution as-is:

CANNOT_TRANSFER will continue to be burned after the name is renewed as fuses are ORed together.
Stopping transfers for wrapper expired names means that all names that don’t have expiry will be also untransferrable. We would prefer if possible to not force expiry to be extended for names that don’t require fuse burning.

That being said, this is definitely a problem and we’re going to look into a mitigation now that can fix this problem.

lcfr.eth · October 22, 2022, 9:27pm

Thanks @jefflau.eth (I suggested another solution but it was basically the same so deleted). Missed the | originally in _mint but I see now.

serenae · October 22, 2022, 10:03pm

Could you prevent that by only making that check if expiry > 0? Like in safeBatchTransferFrom/_transfer:

if (!_canTransfer(fuses) || (expiry > 0 && block.timestamp > expiry)) {
    revert OperationProhibited(bytes32(id));
}

A more general question is, should all wrapped tokens be non-transferrable if the expiry has been reached (and wasn’t 0 to begin with)? Or should this only apply to the .eth 2LD tokens?

jefflau.eth · October 28, 2022, 8:01pm

This ended up being a much longer fix than I anticipated, because the expiry issue was also an issue throughout all subdomains.

To mitigate this, we are now changing the way expiry works so it affects ownership across .eth and subdomains. Here is a short summary of how things have changed with the fix and changes:

Expiry affects ownership if PARENT_CANNOT_CONTROL (PCC) is burned. This means if any name is expired, you lose ownership and therefore control over a name. No transfers, or record setting.
Wrapper expiry and .eth expiry are no longer separate. Wrapper expiry for .eth names are always synced with the registrar contract and will expire, because PCC is always set on .eth names on wrapETH2LD().
Otherwise if PCC is not burned, the name functions just as normal wrapped names without fuses and expired names can be transferred around as normal
Expired names can have their fuses set to anything by the parent up to the parent’s expiry as normal.
Fuses are now split between parent controlled and name controlled. uint16 for owner controlled. uint16 for parent controlled. This allows custom parent controlled fuses which create some interesting usecases that I would like to expand upon in the future
There is now a IS_DOT_ETH fuse, that gets autoburnt by wrapETH2LD(), it shouldn’t be burnable by any other name and should revert if you try and burn it.
setChildFuses() is not callable by .eth names anymore. It was special cased before to allow .eth to extend their expiry, but now that it doesn’t exist, it isn’t necessary anymore
setChildFuses() is special cased for TLD owners. This is done so expiry/fuses can be set for DNSSEC names and so their subdomains can also have their fuses set. Of course this doesn’t give the same guarantees as .eth, but may still be useful.

I’m sure there are other things I have missed out, but these summarise most of what I’ve been working on this week. I still have quite a bit of testing to finish off next week, but wanted to give an update before the weekend. I will work on a longer post explaining things in more detail once the PR has been merged and we are moving to testnet

Here is the WIP PR: Wrapper expiry refactor by jefflau · Pull Request #145 · ensdomains/ens-contracts · GitHub

Thanks again @lcfr.eth for the report, it was much appreciated.

nick.eth · October 31, 2022, 1:38am

@lcfr.eth Had you reported this during the audit, it would have been classified as ‘medium’ and awarded about $3500 of the prize pool. I’ve sent you $3500 USDC and some ENS tokens from ENS Labs as thanks for finding this.

lcfr.eth · November 1, 2022, 2:05pm

Thank you @nick.eth and the whole team

will continue hacking on the new stuff and bring up any more concerns if any.

sterlacci.eth · November 3, 2022, 5:41pm

Hey it seems like the new ENS goerli deployments broke the old ReverseRegistrar https://goerli.etherscan.io/address/0x6F628b68b30Dc3c17f345c9dbBb1E483c2b7aE5c causing set name failures, although now it seems like they are able to go through.

Would like to know how the mainnet deployments will affect the current ReverseRegistrar as this is a contract dependency of ours.

nick.eth · November 4, 2022, 1:14am

There can only be one reverse registrar at a time. The new Goerli deployment deploys a new one, which should be backwards-compatible.

How were you fetching the address of the reverse registrar, and what transactions are you sending to it?

sterlacci.eth · November 4, 2022, 1:33pm

We hard coded as we assumed it would be constant. Our contract is basically a subdomain registrar that deploys a gnosis safe and assigns it a pod.xyz subdomain, so we are calling setName on the reverse registrar in the context of the safe.

serenae · November 10, 2022, 9:38pm

@jefflau.eth Something else I noticed in the new contracts, there’s now a hard cap of 255 bytes for all labels:

if (bytes(label).length > 255) {
    revert LabelTooLong(label);
}

This means that nobody would be able to:

Register any new .eth 2LDs that have a >255 byte label
Wrap any existing .eth 2LDs that have a >255 byte label
Create any new subnames (under a wrapped name) that have a >255 byte label

Is this new behavior intentional?

It looks like the encoded name is just used to populate the names mapping, and to emit in the NameWrapped event. If on-chain storage is the concern, couldn’t the contract just refrain from populating the names mapping if it’s >255 bytes, rather than reverting the transaction? Or are there other reasons why we should have a hard cap now?

nick.eth · November 10, 2022, 10:37pm

That’s correct. The limitation is because a single byte is used to represent the length of each label in DNS encoding, which we use to store name preimages, which are sometimes processed onchain.

serenae · November 10, 2022, 11:09pm

Gotcha, thanks! I thought it was contained to the _addLabel function, but I see that readLabel gets called in the regular wrap function too. So actually it’s broader than I thought, nobody will be able to:

Register any new .eth 2LDs that have a >255 byte label
Wrap any existing name or subname (.eth or DNS) that has a >255 byte label
Create any new subnames (under a wrapped name) that have a >255 byte label

Is that DNS-encoded name actually necessary for anything though? As I mentioned, instead of reverting transactions could the names mapping just not be populated for any such labels?

If this was purely contained to the NameWrapper, and the new registrar controller allowed you to still register non-wrapped names directly, then I don’t think it’d be much of an issue. But that’s not the case right? Once these new contracts are put into place, all new .eth 2LD registrations will be forced through the NameWrapper and wrapped by default, right?

I’m not necessarily defending really long names here, I don’t know if they have any practical use or are just novelties. But if deployed, this would be an important new contract-level restriction that the ENS community would need to be aware of. Also, this means that any currently existing >255 byte .eth 2LDs will suddenly become extremely scarce, as it will be impossible to create any more of them.

nick.eth · November 10, 2022, 11:33pm

True, except via the legacy registrar contract.

As you observe, it’s used in wrap in order to hash the name and check it’s not a .eth 2LD. Outside that it’s used primarily offchain at the moment, but not exclusively, and it’s much easier to build functionality on top of if it’s guaranteed to have the plaintext for every name.

No, the existing registrar will remain enabled and permit registration of unwrapped names.