georgepisaltu
21fbc00d04
This PR is a follow up to #1661 - [x] rename the `simple` module to `legacy` - [x] fix benchmarks to disregard the number of additional fields - [x] change the storage deposits to charge per encoded byte of the identity information instance, removing the need for `fn additional(&self) -> usize` in `IdentityInformationProvider` - [x] ~add an extrinsic to rejig deposits to account for the change above~ - [ ] ~ensure through proper configuration that the new byte-based deposit is always lower than whatever is reserved now~ - [x] remove `IdentityFields` from the `set_fields` extrinsic signature, as per [this discussion](https://github.com/paritytech/polkadot-sdk/pull/1661#discussion_r1371703403) > ensure through proper configuration that the new byte-based deposit is always lower than whatever is reserved now Not sure this is needed anymore. If the new deposits are higher than what is currently on chain and users don't have enough funds to reserve what is needed, the extrinisc fails and they're basically grandfathered and frozen until they add more funds and/or make a change to their identity. This behavior seems fine to me. Original idea [here](https://github.com/paritytech/polkadot-sdk/pull/1661#issuecomment-1779606319). > add an extrinsic to rejig deposits to account for the change above This was initially implemented but now removed from this PR in favor of the implementation detailed [here](https://github.com/paritytech/polkadot-sdk/pull/2088). --------- Signed-off-by: georgepisaltu <george.pisaltu@parity.io> Co-authored-by: joepetrowski <joe@parity.io>
Identity Module
Overview
A federated naming system, allowing for multiple registrars to be added from a specified origin.
Registrars can set a fee to provide identity-verification service. Anyone can put forth a
proposed identity for a fixed deposit and ask for review by any number of registrars (paying
each of their fees). Registrar judgements are given as an enum, allowing for sophisticated,
multi-tier opinions.
Some judgements are identified as sticky, which means they cannot be removed except by complete removal of the identity, or by the registrar. Judgements are allowed to represent a portion of funds that have been reserved for the registrar.
A super-user can remove accounts and in doing so, slash the deposit.
All accounts may also have a limited number of sub-accounts which may be specified by the owner; by definition, these have equivalent ownership and each has an individual name.
The number of registrars should be limited, and the deposit made sufficiently large, to ensure no state-bloat attack is viable.
Interface
Dispatchable Functions
For general users
set_identity- Set the associated identity of an account; a small deposit is reserved if not already taken.clear_identity- Remove an account's associated identity; the deposit is returned.request_judgement- Request a judgement from a registrar, paying a fee.cancel_request- Cancel the previous request for a judgement.
For general users with sub-identities
set_subs- Set the sub-accounts of an identity.add_sub- Add a sub-identity to an identity.remove_sub- Remove a sub-identity of an identity.rename_sub- Rename a sub-identity of an identity.quit_sub- Remove a sub-identity of an identity (called by the sub-identity).
For registrars
set_fee- Set the fee required to be paid for a judgement to be given by the registrar.set_fields- Set the fields that a registrar cares about in their judgements.provide_judgement- Provide a judgement to an identity.
For super-users
add_registrar- Add a new registrar to the system.kill_identity- Forcibly remove the associated identity; the deposit is lost.
License: Apache-2.0