Limited ENS support for non rollup based sidechains

Proposal Summary

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.

Flow

On L1

  • User wraps their ENS name
  • Transfer it to a sidechain using ERC1155 compatible bridge

On sidechain

  • Registrar.new(wrapperContractId, sidechainRegistryAddress) is a constructor function that sets the wrapper contract Id
  • Registrar.claim(tokenId) will lookup 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

Benefits

  • Should work on any EVM compatible chains with bridges that supports ERC1155 token transfer
  • No change on ENS registry nor resolver

Limitations

The lack of ability to verify the state on L1

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.

No support for contract address as ownership

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.

The potential ownership collisions on subdomains

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.

Open Questions.

  • What happens when the name expires on L1?

Comparisons with other proposals

Rollup agnostic integration

TLDR version is

    1. Each ENS name changes their resolver that returns a gateway URL
    1. The gateway URL returns the data with a proof
    1. 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

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.

Chainlink as a crosschain Oracle

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.

The challenge game

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.

1 Like

So, the idea here would be that a name that’s been migrated to a sidechain can only be used - updated and resolved - by clients of that sidechain?

How does the arbitrary message bridge for sidechains work? Could we use its signing mechanism to produce proofs for Durin that have the same security guarantees as the AMB itself?

1 Like

Yes. The use case is to let the domain owner issue subdomains to their users just like argent used to do. https://www.cometh.io on Polygon chain actually had the use case in mind.

I can ask xDAI team to comment but I highly doubt we can reuse their architecture because of the following reasons.

  • It probably only works for xDAI unless we setup AMB bridge for other chains
  • If you issue a subdomain once crossing the bridge (which is the primary use case), the bridge has no information about the subdomain.
  • The bridge has no information once the asset crosses the bridge so it won’t track owner transfer information.
1 Like