J’avais déjà ouvert le sujet il y a précisément un an (Proposition to remove duniter-account pallet), mais nous y voilà à nouveau. Pour résumer, substrate offre la possibilité d’utiliser son système de compte ou de le personnaliser. Elois a choisi de personnaliser avec une pallet (duniter-account) qui apporte plusieurs fonctionnalités, dont certaines qui me semblent superflues. Jusque là ces fonctionnalités additionnelles ne me semblaient pas gênantes et donc leur retrait n’était pas prioraire, mais comme nous approchons d’une phase de test sérieuse dans laquelle je compte inviter plus d’utilisateurs (ĞDev Runtime 800), il est temps de réévaluer les priorités.
Description des structures
AccountInfo de la pallet du frame frame-system
/// Information of an account.
pub struct AccountInfo<Nonce, AccountData> {
/// The number of transactions this account has sent.
pub nonce: Nonce,
/// The number of other modules that currently depend on this account's existence. The account
/// cannot be reaped until this is zero.
pub consumers: RefCount,
/// The number of other modules that allow this account to exist. The account may not be reaped
/// until this and `sufficients` are both zero.
pub providers: RefCount,
/// The number of modules that allow this account to exist for their own purposes only. The
/// account may not be reaped until this and `providers` are both zero.
pub sufficients: RefCount,
/// The additional data that belongs to this account. Used to store the balance(s) in a lot of
/// chains.
pub data: AccountData,
}
AccountData de la pallet pallet-balances (
non utilisé dans Duniter)
/// All balance information for an account.
pub struct AccountData<Balance> {
/// Non-reserved part of the balance which the account holder may be able to control.
///
/// This is the only balance that matters in terms of most operations on tokens.
pub free: Balance,
/// Balance which is has active holds on it and may not be used at all.
///
/// This is the sum of all individual holds together with any sums still under the (deprecated)
/// reserves API.
pub reserved: Balance,
/// The amount that `free + reserved` may not drop below when reducing the balance, except for
/// actions where the account owner cannot reasonably benefit from the balance reduction, such
/// as slashing.
pub frozen: Balance,
/// Extra information about this account. The MSB is a flag indicating whether the new ref-
/// counting logic is in place for this account.
pub flags: ExtraFlags,
}
AccountData de la pallet duniter-account
// see `struct AccountData` for details in substrate code
pub struct AccountData<Balance, IdtyId> {
/// A random identifier that can not be chosen by the user
// this intends to be used as a robust identification system
pub(super) random_id: Option<H256>,
// see Substrate AccountData
pub(super) free: Balance,
// see Substrate AccountData
pub(super) reserved: Balance,
// see Substrate AccountData
fee_frozen: Balance,
/// an optional pointer to an identity
// used to know if this account is linked to a member
// used in quota system to refund fees
pub linked_idty: Option<IdtyId>,
}
Liste de fonctionnalités
random_id→ idée non mature à mon avis, exprimée ici (La solution pour des identicones sécurisées: le random id). #152 vise à le supprimer, @cgeek s’en occupe dans !235linked_idty→ introduit pour Implémentation des quotas, champ léger qui me semble pertinent- taxe de création de compte → censée “financer le random_id” et “permettre un dépôt existentiel plus petit”, à discuter
- ajustement du compteur de référence → permet de créer une identité pour un compte qui n’a pas de Ğ1, à discuter
- mécanisme de frais de transactions personnalisé → implémenté pour les quotas, me semble pertinent pour permettre le remboursement des frais pour les comptes liés à une identité
Points à discuter
Il y a donc deux points à discuter :
- souhaite-t-on permettre la création d’identité pour un compte non alimenté ?
- a-t-on vraiment besoin de la taxe de création de compte ?
Par rapport au premier point, je dirais que non : pour confirmer son identité, le compte doit pouvoir appeler le call, et donc payer les frais d’extrinsic. La seule utilité est l’exonération de la taxe de création de compte, donc ça nous amène au deuxième point.
Pour cette taxe de création de compte, la question est plus compliquée : combien faudrait-il de comptes simultanément dans le storage pour que cela nuise au réseau ? Quel doit être le prix en Ğ1 à investir pour pouvoir nuire au réseau ? Quelle serait la valeur du dépôt existentiel pour qu’il réponde à lui seul à cette menace ? Cette valeur est-elle trop élevée ?
Voilà pour moi le sujet le plus important et urgent à traiter.
