Compte plafonné et alimentation glissante

R&D
1

Avec @1000i100 on a discuté de deux fonctionnalités qui, ensemble, amélioreraient la simplicité d’usage et la sécurité d’un petit compte portefeuille embarqué (sur un téléphone avec code PIN faible par exemple).

[EDIT 1000i100, si ça te va tu peux supprimé la mention de l’édit pour la lisibilité]

L’intension

Reproduire le comportement des plafonds de paiement des cartes bancaires afin de limiter les dégâts en cas de vol.
Ainsi il devient possible d’utiliser au quotidien un compte portefeuille moins sécurisé (code pin court voir sans code pin si on veut imiter les paiements sans contact), sans avoir besoin de se reconnecter régulièrement à un compte de haute sécurité pour approvisionner le compte quotidien. En ne se connectant pas régulièrement au compte de haute sécurité, on peut se permettre d’avoir une sécurisation réellement élevée sans que ce soit contraignant au quotidien, et ça évite d’user cette haute sécurité en s’authentifiant de partout dessus, donc depuis le même terminal que le compte d’usage quotididien.

[FIN EDIT 1000i100]

Compte plafonné

Un compte pourrait définir son plafond. Le surplus d’une transaction dépassant le plafond serait envoyé sur un compte indiqué (typiquement le compte membre, ou un portefeuille plus sécurisé).

Cela éviterait de placer accidentellement (fausse manip, paiement reçu) trop d’argent sur un compte vulnérable.

Overhead runtime:

  • 16 octets de storage par compte (pour tous les comptes) si on le met dans duniter-account
  • 48 octets de storage par compte plafonné si c’est une palette à part, plus une lecture storage pour chaque transaction

Je verrais cette fonctionnalité dans duniter-account puisque c’est un test à réaliser à chaque transaction et que l’overhead dans AccountData est faible.

Alimentation glissante

On pourrait définir un compte à alimenter régulièrement (de manière glissante) pour un certain montant par jour. Un extrinsic du compte destinataire déclencherait un versement d’un montant calculé en fonction du temps écoulé depuis le dernier versement.

Le montant calculé serait proportionnel à la durée depuis le dernier versement, avec pour maximum le montant correspondant à une période donnée. Par exemple si on configure 100G1 sur 10 jours, pour toute durée de 10 jours ou plus on verse 100G1. Pour 5 jours on verse 50G1.

Ainsi, on n’a plus besoin de s’authentifier sur son compte membre pour alimenter son portefeuille, ce qui est un gain de sécurité.

Overhead runtime: 80 octets de storage par versement automatique.

Je mettrais plutôt cette fonctionnalité dans une palette à part, puisqu’elle ne nécessite que quelques extrinsics supplémentaires.

Edit: barré des trucs, réorganisé paragraphes, corrigé coût runtime

5 Likes
2

Merci pour le récap de notre discussion :slight_smile:

Je ne comprends pas pourquoi tu ajoutes ce paragraphe dans la partie plafonnée.

Pour moi, un compte plafonné, on définit le montant du plafond, le compte cible pour le surplus, et si le compte reçoit plus que le plafond, c’est transféré automatiquement, du coup pas besoin de délais.

3

Si le versement automatique n’a pas de délai, rien n’empêche de vider le compte source en 100 fois s’il le faut, à hauteur d’un plafond par bloc. Le délai assure qu’on ne verse pas plus d’un certain montant par une certaine période de temps, en moyenne.

En effet le plafond de versement (qui n’est pas le même que le plafond du compte) n’est pas nécessaire (je croyais mais non), mais il plafonne sur une certaine période de temps en absolu (et pas en moyenne). Sa seule utilité est alors d’empêcher un versement trop important sur un compte non plafonné avec beaucoup d’arriérés à rattraper, mais pour éviter ça il suffit de configurer un plafond au compte.

Un usage possible des comptes plafonnés qui ouvre la porte à de l’exploitation est de donner à quelqu’un un compte plafonné qui renvoie le surplus à mon propre compte. Cependant il n’y a pas beaucoup de différence entre accepter de plafonner son compte et accepter d’envoyer des transactions. (la mise en place d’un plafond requerrait l’accord des deux comptes concernés (*), et la résiliation pourrait se faire unilatéralement)

(*) Pour éviter les boucles ou les situations coûteuses en runtime, il faut :

  • qu’un compte plafonné ne puisse pas recevoir de surplus de plafond ;
  • qu’un compte plafonné envoie son surplus à un unique compte.

Un usage possible du versement automatique est le paiement récurrent.

4

Ok, si le délai est pour l’alimentation automatique régulière (en fenêtre glissante) on est sur la même longueur d’onde :slight_smile:

5

Excellente idée! C’est effectivement pratique pour ne pas devoir recharger son porte-monnaie sans arrêt en se connectant à son compte forgeron.

Est-ce utilisable pour payer un abonnement?
Pour répondre au besoin de virement automatique sur le portefeuille d’un tiers.

Pour gérer ces “cas utilisateur”, j’avais imaginé pouvoir établir une liste de clefs destinataire auxquelles un % du DU est transféré chaque jour (100% étant évidemment le maximum).