BitShares French ConneXion  

Permission dynamique des comptes


Gestion de l'environnement d’une corporation

BitShares crée les permissions autour d’une personne plutôt que de le concevoir autour de la cryptographie, ce qui le rend plus facile d’utilisation. Tous les comptes peuvent être contrôlés à partir de combinaisons pondérées d’autre comptes et de clés privées. Ceci a pour effet de créer une structure hiérarchisée qui, comme dans une société centralisée, reflète comment les droits sur un compte sont répartis. Un compte peut donc être contrôlé par plusieurs personnes en fonction de leurs permissions. Ceci est un facteur important pour la sécurité car en l’utilisant a bon escient, cela élimine virtuellement le risque de vol dû au hacking.


Background

La capacité à requérir plusieurs signatures digitales pour les opérations sensibles ayant lieu sur la blockchain est une part intégrale de la sécurité de la plate-forme. Alors qu’une clé unique peut se révéler compromise, de nombreuses clés distribuées à de nombreux endroits ajoutent de la redondance, ce qui engendre une plus grande sécurité pour le réseau.

Les blockchains compétitrices souffrent des défauts suivant:

# La technique de multi-sig M-of-N ne permet pas de refléter la gestion hiérarchique de beaucoup d’organisations de la vie réelle.
# Le modèle accordant le même poids à chaque clé M ne permet pas de refléter la notion de propriété asymétrique d’un compte.
# La coordination et les signatures doivent se faire hors de la plate-forme.
# Les clés ne peuvent pas être changées, sans l’intervention de tous les autres participants.
Les signatures ne peuvent pas être retirées durant l’attente des signatures par les autres clés.


Utilisation

La technologie des multi-signatures concerne essentiellement la gestion de permissions, en effet les permissions devraient être définies en fonction des utilisateurs et des organisations plutôt qu’en fonction des clés. Prenons l’exemple d’une entreprise gérée par trois individus: Alice, Bob et Carol. Alice et Bob possède chacun 40% de l’entreprise et Carol en possède 20%. Cette entreprise nécessite l’accord d’au moins deux des trois participants à chaque dépense. Vous pourriez définir l’organisation de cette entreprise en terme de clé mais qu'arrivera-t-il si Alice souhaite protéger son identité en faisant appel à une multi-sig? Alice choisit d’utiliser un service d’authentification à 2 facteurs qui sera requis chaque fois qu’elle voudra effectuer une action avec son compte. Cela protège à la fois Alice et l’entreprise, de plus, l’entreprise n’a pas besoin de revoir sa structure de permission pour permettre à cette dernière d’utiliser une authentification à 2 facteurs.


Solution

Nous introduisons une nouvelle approche des permissions basée sur l’ID unique de chaque compte.

Avec ce système, il est possible de définir un compte qui ne possède pas de clé mais qui dépend uniquement de l’approbation d’autres comptes. Ces autres comptes peuvent à leur tour dépendre de l’approbation de plusieurs autres comptes. Ce procédé construit une hiérarchie de comptes avant de donner leurs approbations. Chaque compte peut changer ses permissions, indépendemment des comptes plus haut placés dans la hiérarchie, rendant les permissions de comptes dynamiques.

Chaque compte définit ces permissions comme un ensemble de clés et/ou d’autres comptes auxquels sont assignés un certain poids par le détenteur du compte. Si le poids combiné des clés et/ou des comptes excède une certaine limite, alors l’approbation est donnée, la permission est accordée.

La deuxième option est d’inclure la transaction à approuver dans l’état actuel de la blockchain et de permettre aux comptes concernés de donner ou de retirer leur approbation concernant cette transaction. Cela simplifie le problème de coordination des signatures, permet aux utilisateurs de changer d’avis avant que la limite de poids d’approbation ne soit atteinte et valide la transaction dès que l’approbation décisive a été accordée.

L'exécution d’une transaction soumise à une approbation par multi-sig se déroule comme ceci:

# Quelqu’un propose une transaction et l’approuve avec son compte.
# Les autres comptes transmettent la transaction en ajoutant leur OUI ou leur NON à la proposition.
Quand la transaction obtient le vote de chaque compte, elle est confirmée.


Clés propriétaires et clés actives

Chaque compte se voit assigner deux autorités: Propriétaire et Active

# Une autorité est un groupe de clés et/ou de comptes où chacun se voit assigner un poids.
# Chaque autorité est soumise à un seuil de poids qui doit être dépassé avant qu’une action requérant cette autorité puisse être exécutée.
# L’autorité Propriétaire est conçue pour le cold-storage, sont rôle principal est de changer l’autorité Active ou l’autorité Propriétaire.
# L’autorité Active est conçue pour servir de hot-key (raccourci) et peut effectuer n’importe quelle action, à l'exception de changer l’autorité Propriétaire.
Le cas d’utilisation qui a inspiré cette fonctionnalité est pour un service fournissant une authentification à 2 facteurs comme co-signataire du côté de l’autorité Active mais pas du côté de l’autorité Propriétaire.

Avec cette approche, l’utilisateur peut à la fois utiliser son compte quand il le souhaite et garder la propriété de ce compte en cold-storage où personne ne peut la pirater. Cela signifie que, par exemple, le compte d’une entreprise peut nécessiter l’approbation d’une transaction par son conseil d’administration et ensuite, chaque membre du conseil d’administration devra se servir d’une authentification à 2 facteurs afin d’approuver ou non la transaction.

N’importe qui peut changer de clé fréquemment sans perturber la hiérarchie de permission des comptes.


Rassembler les signatures

L’une des principales barrières à l’adoption de la technologie de multi-signatures est que la collecte des signatures se faisait manuellement ou demandait une infrastructure spécialisée. Une fois qu’une transaction est signée, il n’y a aucun moyen de revenir en arrière, donc le dernier à signer une transaction a un avantage non négligable sur les autres participants. Avec des hiérarchies plus ramifiées, le rassemblement des signatures devient encore plus complexe.

Afin de simplifier cette procédure, la blockchain doit gérer la procédure de rassemblement des signatures en suivant l’état des propositions de transactions partiellement approuvées. Durant cette procédure, chacun des intervenants a l’occasion d’ajouter ou de retirer son approbation sans dépendre d’un tiers fournissant le service de multi-sig.

Pour réussir à garder les différentes opérations liées dans la base de donnée, une transaction à approuver peut descendre jusqu’à 2 niveaux dans la hiérarchie. Si plus de deux niveaux de hiérarchie sont présent, il faudra demander l’approbation d’une première transaction qui autorisera l’approbation de la seconde transaction plus haut dans la hiérarchie. Quand la première transaction est approuvée, l’approbation est ajouté pour la seconde transaction.

Grâce à cette approche, chaque individu ne paye qu’un seul frais de transaction chaque fois qu’ils approuvent une transaction, chaque action demande au maximum la vérification d’une signature pas le réseau. Ce procédé permet de créer des hiérarchies complexes sans pour autant exposer le système à la fraude.


Adaptabilité

En théorie, les comptes peuvent créer un système hiérarchique arbitrairement ramifié, le temps nécessaire au respect de la hiérarchie est également arbitraire. Dans la pratique, il est rare qu’une transaction isolée doive descendre plus de 2 niveaux de hiérarchie, cela lui permet de rester simple à approuver. Si la transaction demande de descendre plus de niveaux de hiérarchie, il y a de grande chance qu’elle implique un grand nombre de participants, cette transaction ne sera probablement pas signée en une fois. Cette transaction devra utiliser le système de suivi des transactions partiellement approuvées.

# Avec cette approche, un gestionnaire peut demander l’approbation d’une transaction par sa compagnie
# Cela peut aller jusqu’à demander l’approbation de chaque compte pour chaque proposition.
# Ce procédé permet de collecter les frais de transaction au fur et à mesure que les approbations s’ajoutent à la proposition, tout en gardant le tout comme étant une seule transaction à approuver.

Il est possible pour deux comptes de nécessiter l’approbation l’un de l’autre pour une transaction.

A -> X <-> Y
B -> Y <-> X

A propose une transaction qui envoie 1 BTS à X et attend l’approbation de Y. B propose que Y approuve la proposition de A et attend l’approbation de X.

Il n’y a aucun moyen de résoudre ce problème avec une seule approbation d’un participant car:

# Aucun des comptes ne peut agir sans les autres, de ce fait, rien ne peut être accompli
# Les Cycles ne sont pas obligatoirement aussi évidents que celui-ci, il peuvent impliquer une chaîne hiérarchique arbitrairement longue
# Si un utilisateur créer un Cycle d’approbation dans l'autorité Active alors l’autorité Propriétaire peut être utilisée pour rompre le Cycle; cependant si un Cycle se forme dans l’autorité Active et dans l’autorité Propriétaire alors les comptes pris dans ce Cycle seront verrouillés.
# Dans la pratique, le software peut détecter la formation de Cycle et empêcher leurs formation.


Conclusion

La permission dynamique des comptes ainsi que le procédé de multi-sig sont une représentation plus naturelle des règles de propriétés et de contrôle.


Crédits

Le wiki de Ripple contient une proposition similaire de multi-sig qui est documentée mais pas implémentée et qui fût découverte indépendamment de celle ci.