-
Notifications
You must be signed in to change notification settings - Fork 2.6k
Conversation
Co-authored-by: Guillaume Thiolliere <gui.thiolliere@gmail.com>
…shawntabrizi-name-service
* set_name and bid tests * claim and free tests * assign, unassign, make_permanent tests * fixes * whitespace fixes * remove unused dep Co-authored-by: Shawn Tabrizi <shawntabrizi@gmail.com>
|
||
impl<T: Config> Pallet<T> { | ||
/// Get the commitment hash from the raw name and secret. | ||
pub fn commitment_hash(name: &[u8], secret: u64) -> CommitmentHash { |
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 think the secret here should either be a Config type or a [u8; 32]
, just using a u64
is a but unprofessional IMHO.
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.
nope
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 not? A chain developer can put very large commitment alive periods, in which this would become unsafe.
Signed-off-by: Oliver Tale-Yazdi <oliver.tale-yazdi@parity.io>
Signed-off-by: Oliver Tale-Yazdi <oliver.tale-yazdi@parity.io>
Signed-off-by: Oliver Tale-Yazdi <oliver.tale-yazdi@parity.io>
…ytech/substrate into shawntabriz-name-service-2
Signed-off-by: Oliver Tale-Yazdi <oliver.tale-yazdi@parity.io>
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 think front-running cannot be avoided even with blinded commitments, as someone might discard the reveal tx, and make a new commitment with the same name and a different secret, and then reveal that. Other than that, few nit-picks. Haven't gone over benchmarks nor test cases.
pub(super) type AddressResolver<T: Config> = | ||
StorageMap<_, Blake2_128Concat, NameHash, T::AccountId>; | ||
|
||
/// This resolver maps name hashes to an account |
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.
Copy-paste typo.
BytesStorage<T::AccountId, BalanceOf<T>, BoundedNameOf<T>>, | ||
>; | ||
|
||
/// This resolver maps name hashes to an account |
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.
Typo here as well.
pub enum Event<T: Config> { | ||
/// A new `Commitment` has taken place. | ||
Committed { depositor: T::AccountId, owner: T::AccountId, hash: CommitmentHash }, | ||
/// A new `Registration` has taken added. |
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.
/// A new `Registration` has taken place.
/// A new `Registration` has taken added. | ||
NameRegistered { name_hash: NameHash, owner: T::AccountId }, | ||
/// A `Registration` has been transferred to a new owner. | ||
NewOwner { from: T::AccountId, to: T::AccountId }, |
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.
Would it make sense to add the name hash being transferred?
secret: u64, | ||
length: T::BlockNumber, | ||
) -> DispatchResult { | ||
ensure!(name.len() <= T::MaxNameLength::get() as usize, Error::<T>::NameTooLong); |
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.
Would T::MaxNameLength::get().saturated_into::<u32>()
be more correct?
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.
Also, instead of preventing names that are too short by setting an unresonably high registration fee, why can't the check be performed 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 think casting a u32
to a usize
is not a problem, but I can still change it.
Also, instead of preventing names that are too short by setting an unresonably high registration fee, why can't the check be performed here?
Yea that should be added.
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 think casting to usize is fine. this behavior exists a lot of places afaik
impl<T: Config> Pallet<T> { | ||
pub fn registration_fee(name: Vec<u8>, length: T::BlockNumber) -> BalanceOf<T> { | ||
let name_length = name.len(); | ||
let fee_reg = if name_length < 3 { |
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 doesn't feel completely right to prevent names that are too short by simply returning a very high fee. Also, this is called in a single place, so it might make sense to simply perform the check before this function is called. Furthermore, why is the 3 a magic number and not part of the pallet's configuration?
} | ||
|
||
/// Check if an account is a controller or owner of this name registration. | ||
pub fn is_controller(registration: &RegistrationOf<T>, user: &T::AccountId) -> bool { |
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.
Since it also checks ownership, perhaps renaming it to can_control
would be clearer.
/// Register the raw name for a given name hash. This can be used as a reverse lookup for | ||
/// front-ends. | ||
/// | ||
/// This is a permissionless function that anyone can call who is willing to place a deposit |
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 it correct to talk about deposits here? The NameServiceResolver
trait does not really enforce it. This seems a (recommended) implementation detail.
|
||
// TODO AUDIT WARNING: Can return an error after `withdraw` happens. Needs to be | ||
// transactional or refactored. | ||
Self::do_register( |
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 guess this could just be moved up before calling T::RegistrationFeeHandler::on_unbalanced
? Then there are no failures after this is executed.
name: Vec<u8>, | ||
) -> DispatchResult { | ||
let sender = ensure_signed(origin)?; | ||
ensure!(Registrations::<T>::contains_key(name_hash), Error::<T>::RegistrationNotFound); |
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 is there no ensure!(Self::is_controller(®istration, &sender), Error::<T>::NotController);
here?
* add conceret types for runtime * Adjusting the PerByteFee Co-authored-by: Shawn Tabrizi <shawntabrizi@gmail.com> * fix format Co-authored-by: Shawn Tabrizi <shawntabrizi@gmail.com>
Hey, is anyone still working on this? Due to the inactivity this issue has been automatically marked as stale. It will be closed if no further activity occurs. Thank you for your contributions. |
In progress.