Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add L2 reverse registrar contract #265

Open
wants to merge 37 commits into
base: dev
Choose a base branch
from
Open

Add L2 reverse registrar contract #265

wants to merge 37 commits into from

Conversation

jefflau
Copy link
Member

@jefflau jefflau commented Jul 24, 2023

  • Resolver profiles for setName and setText
  • Signature record setting for setName
  • Signature record setting for setName for an Ownable contract
  • Signature record setting for setText
  • Signature record setting for setText for an Ownable contract
  • Signature record setting for clearRecords

@jefflau jefflau marked this pull request as ready for review October 19, 2023 05:40
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This should probably be added to .gitignore.

address addr,
string memory name,
address relayer,
uint256 signatureExpiry,
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wonder if, rather than using expiry, we should use inception? That gives us an ordering over signatures and we know that we can ignore earlier ones if we have a later one.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What do you mean by inception? Do you mean a nonce-based system?

function setNameForAddrWithSignature(
address addr,
string memory name,
address relayer,
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why does relayer need to be specified here?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I was thinking if someone wanted to be more restrictive on who could send the tx, but maybe it doesn't matter given that all of the arguments are set within the signature.

contracts/reverseRegistrar/L2ReverseClaimer.sol Outdated Show resolved Hide resolved
import "./L2ReverseResolverBase.sol";
import "../../resolvers/profiles/INameResolver.sol";

abstract contract L2NameResolver is INameResolver, L2ReverseResolverBase {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this different to NameResolver? Can't we avoid the need for duplication here by implementing the L2-specific functionality as a mixin at the top of the inheritance hierarchy, instead of the bottom?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So the problem I had was, I needed access to the address not the node in authorisation. And the original resolver uses bytes32 node. Whereas the reverse registrar passes through address for authorisation. I wasn't sure how to change the modifier here without duplicating the contracts.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Given we call _setName in the parent contract, is there any point in making these separate contracts at all, then?

import "./L2ReverseResolverBase.sol";
import "../../resolvers/profiles/INameResolver.sol";

abstract contract L2NameResolver is INameResolver, L2ReverseResolverBase {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Given we call _setName in the parent contract, is there any point in making these separate contracts at all, then?

pragma solidity >=0.8.4;

interface IL2ReverseRegistrar {
function setName(string memory name) external returns (bytes32);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why do we need to return bytes32 for transactions? setName on L1 doesn't return anything https://github.com/ensdomains/ens-contracts/blob/staging/contracts/resolvers/profiles/NameResolver.sol#L15 . The same applies to all set* functions.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This point still stands

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Isn't it the contract you added several months ago? What was the intention at that time? If it's wrong then it should be fixed now unless it requires some sort of complex migration work as the change itself is not so critical

event VersionChanged(bytes32 indexed node, uint64 newVersion);
bytes32 public immutable L2_REVERSE_NODE;

bytes32 constant lookup =
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you add a comment explaining what lookup is?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm actually not 100% sure, this is lifted from the original reverse registar

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@Arachnid do you know what this is?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's just '0123456789abcdef' in hex form; it allows quickly mapping from a number from 0-15 to a hexadecimal character.

* May only be called by the owner of that node in the ENS registry.
* @param addr The node to update.
*/
function clearRecords(address addr) public virtual authorised(addr) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you add test for this function as the implementation defers a lot from the L1 equivalent.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The implementation code of clearRecords and clearRecordsWithSignature are identical (only difference in modifier). Can you refactor to avoid code duplication?

@makoto
Copy link
Member

makoto commented Oct 26, 2023

What is the rational of the reverse registrar having setText which wasn't the case for L1 reverse registrar? Also, if there is a valid reason for it, what's the reason of reverse registrar not having setAddr either?

@makoto
Copy link
Member

makoto commented Nov 28, 2023

You probably need to add function supportsInterface

@jefflau
Copy link
Member Author

jefflau commented Dec 6, 2023

You probably need to add function supportsInterface

I think there is already a function there?

contracts/reverseRegistrar/L2ReverseRegistrar.sol Outdated Show resolved Hide resolved
contracts/reverseRegistrar/L2ReverseRegistrar.sol Outdated Show resolved Hide resolved
contracts/reverseRegistrar/L2ReverseRegistrar.sol Outdated Show resolved Hide resolved
contracts/reverseRegistrar/L2ReverseRegistrar.sol Outdated Show resolved Hide resolved
contracts/reverseRegistrar/L2ReverseRegistrar.sol Outdated Show resolved Hide resolved

## Summary

The L2 Reverse registrar is a combination of a resolver and a reverse registrar that allows the name to be set for a particular reverse node.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Some more docs would be good!

@makoto makoto mentioned this pull request Apr 4, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants