Create a new registrar which allows claiming ownership of the name on a side chain to the owner of the ENS Wrapper contract (A wrapper contract to turn any ENS names into NFT) bridged from L1.
- User wraps their ENS name
- Transfer it to a sidechain using ERC1155 compatible bridge
Registrar.new(wrapperContractId, sidechainRegistryAddress)is a constructor function that sets the wrapper contract Id
WrapperContract.ownerOf(tokenId)and set ownership to the owner of the wrapper token while transferring the ownership of the wrapper token to the registrar
Registrar.release(tokenId)will unset the ownership to 0x and transfer the ownership back
- Should work on any EVM compatible chains with bridges that supports ERC1155 token transfer
- No change on ENS registry nor resolver
Unlike the rollup agnostic integration proposal (to be discussed later), this solution does only provide an ENS lookup service to each sidechain and no way to verify the state on L1.
I think this is an acceptable compromise as most of Dapp’s “L2/sidechain solution” is to create a replica of their platform in multiple chains and they act independently. The only thing this proposal is providing is to be able to let the user claim the name they own on L1. Without this solution, Dapp developers (eg: Colony on xDAI) are currently deploying their own instance of ENS just to claim their own ENS names which are high maintenance and wasted effort for the dapp developers.
Because most contract-based accounts (eg: multisig) cannot retain the same contract id, if the user wraps the ENS ownership to multisig and cross it to the side chain, the same contract address is less likely to claim the ownership.
This is a known limitation of the sidechain in general so it should be avoided at the user level by transferring the ownership back to EOA before crossing the bridge.
It is technically possible to have subdomains on L1 and the sidechains owned by different owners if the name has issued subdomains on L1 before transferring the name to the sidechain then create the same name on the sidechain.
I don’t think there is a simple way to prevent that at the protocol level so it will be the name owner’s responsibility to only transfer names to take care of the inconsistency.
- What happens when the name expires on L1?
TLDR version is
- Each ENS name changes their resolver that returns a gateway URL
- The gateway URL returns the data with a proof
- L1 can verify the data with proof so that each Dapp/wallet/exchanges only use L1 as canonical data of truth.
To achieve #3 while retaining the same security model, the target L2 chains must have a way to allow L1 to verify. The possible ways are
- a: L2 periodically commit state root proof (available on most rollups)
- b: Sidechain return data with a signature of the validator which L1 can validate
Even though b is technically possible, this requires the target sidechain to open up API just for the purpose of the ENS gateway which may not be practical as this is an extra infrastructure to support the platform. Also b: would only work for a simple PoA(proof of authorities) system that trust any transaction signed by one of the authorities. It may not be able to support more complex PoS as L1 needs to know which validator to trust for the specific state it tries to verify.
AMB ENS mirroring service was proposed by xDAI team at the last year’s ENS workshop.
Their idea is to use Arbitrary Message Bridge (AMB) to transfer ENS ownership data. The difference with this proposal is that our proposal doesn’t require every chain to have an AMB bridge so more platform agnostic. It should work in theory as long as chains have a bridge to transfer ERC1155 between each chain.
Another alternative is to let users claim using chainlink as an Oracle to verify a state across chains.
This has a slight advantage over the main proposal because we can use the oracle to invalidate the claim when the name expires. The downside is a dependency on a third-party dependency.
This is originally proposed by Vitalik but we pivoted away to use rollup’s own attestation mechanism so that we don’t have to maintain our own “ENS attesters”. Given that sidechains (BSC and Polygon specifically) became more popular than it was at the time we discussed the solution, we could potentially revise if this approach is feasible for non-rollup based sidechains as well.