-
Notifications
You must be signed in to change notification settings - Fork 413
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
base: dev
Are you sure you want to change the base?
Conversation
jefflau
commented
Jul 24, 2023
•
edited
Loading
edited
- 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
.vscode/settings.json
Outdated
There was a problem hiding this comment.
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, |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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, |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
import "./L2ReverseResolverBase.sol"; | ||
import "../../resolvers/profiles/INameResolver.sol"; | ||
|
||
abstract contract L2NameResolver is INameResolver, L2ReverseResolverBase { |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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 { |
There was a problem hiding this comment.
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); |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This point still stands
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The original reverseRegistrar does this: https://github.com/ensdomains/ens-contracts/blob/staging/contracts/reverseRegistrar/IReverseRegistrar.sol
There was a problem hiding this comment.
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 = |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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) { |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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?
What is the rational of the reverse registrar having |
2b4cf91
to
d25e521
Compare
You probably need to add |
I think there is already a function there? |
|
||
## 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. |
There was a problem hiding this comment.
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!
470d7c3
to
d2315a9
Compare
77cd582
to
a97255a
Compare