Oneshot accounts

Add lighter accounts that can be consumed only once.

Je n'ai pas encore fait les tests unitaires car la config de mock est assez longue à faire. Mais les tests d'intégration sont là.

Est-ce que l'ordre des deposit_event importe ? Si non, le code des calls peut être un peu factorisé sans coût.

requested review from @librelois

Est-ce que l'ordre des deposit_event importe ? Si non, le code des calls peut être un peu factorisé sans coût.

Non on s'en fou, va y factorise le code :)

Je n'ai pas encore fait les tests unitaires car la config de mock est assez longue à faire

Si tu peut prendre le temps de le faire dans cette PR ce serait bien

Il faudrait aussi un test end2end, car j'ai peur qu'on est des soucis lors de la consommation d'un oneshot account du fait que le compte n'existe pas du point de vue de la pallet sytem !

added 1 commit

• e775eae8 - feat(duniter-account): finalized PoC oneshot account

Compare with previous version

@tuxmain évite de rajouter le suffixe 1 dans tout ce qui apparais au monde extérieur, comme les nom des call et de leurs paramètres :)

On le fait uniquement dons le code interne.

@tuxmain pour les call qui consomment un oneshot account, il faut empecher substrate de créer un compte via l'incrément du nonce. Pour ce faire, je propose de créer notre propre wrapper DuniterCheckNonce<Inner: SignedExtension>(Inner) et dans l'impl du trait SignedExtension réécrire uniquement le comportement de la méthode pre_dispath dans le cas d'un call qui consomme un oneshot account. Il faut bien sur être transparent en appelant la méthode de Inner dans tout les autres cas.

Cherche les occurences à CheckNonce dans la codebase et tu verra ou est ce que c'est injecté pour chaque runtime

added 18 commits

• e775eae8...8bc5e17f - 16 commits from branch master
• 984d95d8 - PoC about oneshot accounts
• 5b6686a1 - feat(duniter-account): finalized PoC oneshot account

Compare with previous version

added 1 commit

• 0406fec8 - feat(duniter-account): finalized PoC oneshot account

Compare with previous version

added 74 commits

• 0406fec8...33630d52 - 72 commits from branch master
• 6d4f4bfb - PoC about oneshot accounts
• 2a6e392b - feat(duniter-account): finalized PoC oneshot account

Compare with previous version

@librelois Je crois qu'il ne reste qu'à faire prendre les frais sur le oneshot account plutôt que sur le compte normal.

Juste pour confirmer : il faut utiliser un OnChargeTransaction custom, c'est ça ?

Il faut aussi décider, pour consume_oneshot_account_two_dests, si on prend les frais sur un destinataire, ou également sur les deux, ou avec un ratio défini par l'utilisateur. Je dirais que sur un seul c'est plus pratique pour l'utilisateur et plus rapide à calculer.

added RN-runtime label

@tuxmain il faut créer une implémentation du trait pallet_transaction_payment::OnChargeTransaction dans la pallet oneshot_account qui doit prentre un générique Inner et apeller Inner dans tous les cas sauf si le call est censé être émis par un oneshot account. Si le call est consé être émis par un oneshot account il faut prélever les fauis au oneshot account, pas au destinataire. Il ne faut jamais prelever des frais à un compte qui n'a pas signé pour ça, ce serait une grave faille de sécurité.

@tuxmain aussi je pense qu'il faut déplacer tout ça dans une nouvelle pallet oneshot_account , et bouger également le CheckNonce dedans. Oui c'est plus dur mais ça me semble être un découplage essentiel. La fonctionnalité "onethot account" que nous ajoutons ici n'est pas spécifique à duniter, donc ça doit être dans sa propre pallet, pallet qu'on pourra d'ailleurs extraire dans son propre dépôt à l'avenir quand elle sera mature.