I’m creating this thread to list undocumented Duniter concepts that I do not understand or that I do not have time do document in the code yet.
1 Like
I started documenting in the code why we have an AccountData different from substrate’s one. Still not very clear to me, but has to do with the random_id: Option<H256> which also has to be documented.
(see La solution pour des identicones sécurisées: le random id for reference)
- accounts corresponding to an identity are allowed to exist without deposit
1 Like
AccountIdToSalt the account id (e.g. 32 bytes of pubkey) is used as a salt to generate the random id from the vrf.
MaxNewAccountsPerBlock. Seems to be related with the random id. Not sure why we would limit the number of new accounts per block in an other way that extrinsic costs provides if not for random id. I whish we could remove this layer of complexity which makes the migration more difficult to perform as there is more useless code to understand, test, and document. But apparently for @elois this is the opposite:
Same for PendingRandomIdAssignments, PendingNewAccounts, RandomIdAssigned event… What a level of complexity for a feature that does not make consensus, will not be implemented in the main clients, and was added by a guy blaming other for slowing down the migration process.
2 Likes
Duniter cli commands are mainly managed directly by substrate. But you should know that Duniter itself introduces subtleties. For example the build-spec command ignores the DUNITER_GENESIS_CONFIG environment variable if you provide --chain gdev and not --dev. But since it’s not documented you have to read the (without comments) code to get it. That’s an example why relying on environment variable is weak because it short-circuits substrate command line parsing.
WASM_BINARY ad WASM_BINARY_BLOATY is a Substrate concept but is seems very strange. I have to understand what it is and document it.
[edit] What are the differences between WASM_BINARY and WASM_BINARY_BLOATY - Polkadot Forum
IdtyCertMeta has a next_issuable_on field and IdtyValue have next_creatable_identity_on field. I do not understand yet how these two work together.
Membership events are defined both in Duniter primitives and Membership pallet:
in Duniter primitives
pub enum Event<IdtyId, MetaData = ()> {
/// A membership has acquired
MembershipAcquired(IdtyId, MetaData),
/// A membership has expired
MembershipExpired(IdtyId),
/// A membership has renewed
MembershipRenewed(IdtyId),
/// An identity requested membership
MembershipRequested(IdtyId),
/// A membership has revoked
MembershipRevoked(IdtyId),
/// A pending membership request has expired
PendingMembershipExpired(IdtyId),
}
in Membership pallet
pub enum Event<T: Config<I>, I: 'static = ()> {
/// A membership has acquired
/// [idty_id]
MembershipAcquired(T::IdtyId),
/// A membership has expired
/// [idty_id]
MembershipExpired(T::IdtyId),
/// A membership has renewed
/// [idty_id]
MembershipRenewed(T::IdtyId),
/// An identity requested membership
/// [idty_id]
MembershipRequested(T::IdtyId),
/// A membership has revoked
/// [idty_id]
MembershipRevoked(T::IdtyId),
/// A pending membership request has expired
/// [idty_id]
PendingMembershipExpired(T::IdtyId),
}
Not sure if it is useful or redundant.
When I asked Elois by email if he thought it was a good idea to remove pallet duniter-account and provide-randomness, he told me that we could keep the latter because the feature was quite light and could be useful. The fact is that pallet is not documented either, especially the trait OnFilledRandomness which is quite mysterious to me right now 
1 Like
pallet identity has some unused errors:
#[pallet::error]
pub enum Error<T> {
/// [...]
/// Right already added
RightAlreadyAdded,
/// Right does not exist
RightNotExist,
}
Never appear anywhere else in the code, I wonder why they are here.
They were used before, but the code must have been removed. You can search through commit history with this command:
git grep RightNotExist $(git rev-list --all)
iirc Élois removed the rights system because it was too complex and not that useful. So we can remove these variants.
This does not emit a dead code warning because the enum is public (as it may be used outside the crate, the compiler cannot prove it’s unused). The only workaround seems to be making the enum private and wrapping it into a public enum. But this can be annoying and unpractical.
We’ll have to be careful with these enums, because changing the variants order may change the SCALE encoded representation and cause problems on wallets with outdated metadata.
2 Likes
It becomes clearer if we imagine an identity creation period larger than the certification period. I still have to document that.
2 posts were merged into an existing topic: Programming style Duniter v2
oneshot-account : I don’t really understand the problem this pallet is trying to solve.
Git says it was created by @tuxmain and I also found ticket #44 mentioning it.
edit : another mention here: RFC pour les dérivations des HD Wallets dans Duniter V2S - #3 by elois
Oneshot accounts are cheaper accounts that can only be created and emptied. They consume less storage and cost less transaction fees.
They are useful for usages like mixing (see GMixer) where you need several intermediate transactions, or single-use “banknotes” for example.
As anonymous or private-amount transactions will not be implemented in the foreseeable future, oneshot accounts reduce the cost of anonymization systems.
3 Likes
There is a subtlety in account management:
As you can see, if you look the at system.account(address) there is a result, but if you look at balances.account(address) you get a default value (because there is nothing). That’s normal because the account info is not managed by balance pallet but by duniter-account pallet. But this is counter-intuitive and should be fixed or documented. (I’ll see if it is easy to de-duplicate free/reserved/feeFrozen).
1 Like
This also mean that there is a problem between monetaryMass and totalIssuance.
at genesis
2 Likes
When a non-validated identity is removed (confirmed or unconfirmed), all the certs it received are also removed. I think it was done to mimic Duniter v1 behavior where there could be multiple certs at the same time in the mempool without using the certification limit. I hesitated to put this here or in Counterintuitive Duniter concepts