Les délégués

Les clés et les comptes

Dans Tezos, les tokens sont contrôlés grâce à une clé privée (private key), appelée la clé de gestion (manager key). Tezos laisse le manager, le détenteur de cette clé, choisir son délégué en spécifiant sa clé publique. Cette clé de délégation peut être contrôlée par le manager lui-même (être son propre Baker) ou par un tiers (lors du choix d’un service tiers de délégation).

La responsabilité du délégué est double. D’une part, le délégué prend part à l’algorithme de consensus de la preuve d’enjeu (Proof of Stake) via la création de bloc (Baking) et leur approbation (Endorsment). D’autre part, il prend part et à la gouvernance du protocole Tezos par la proposition d’amendements sur les évolutions du protocole.

Le manager peut changer de délégué à tout moment, même s’il est possible de créer un contrat pour spécifier un délégué de manière immuable. En cas de changement de délégué, celui-ci deviendra effectif après quelques cycles¹.

Il existe aussi deux autres comptes : les comptes par défauts et les comptes délégués. Les comptes par défaut correspondent simplement au hash de la clé publique. Ces comptes ne disposent pas de clé de délégation et ne participent pas au consensus de PoS. Les comptes délégués sont utilisés pour placer des dépôts de garantie. Ils sont automatiquement délégués au délégataire lui-même.

Délégué : Tiers à qui l’on délègue ses votes (par exemple un service de délégation), pour participer au consensus (processus de création et de validation des blocs, via baking et endorsment), ou soi-même si l’on souhaite faire valoir ses droits au consensus.

Les états passif et actif

Un délégué peut-être passif ou actif. S’il est passif, le délégué ne peut être sélectionné pour le processus de création ou d’approbation des blocs (baking et endorsement). Un délégué devient passif pour un cycle « n », quand il ne parvient pas à créer (baking) ou à approuver (endorsement) un bloc, durant les 5 derniers cycles² , ou à changer son dépôt de garantie (security deposit). Ainsi, un petit délégué craignant d’être désactivé car il n’a pas eu la possibilité ni de créer ni d’approuver un bloc, peut s’assurer de ne pas être désactivé en effectuant une transaction d’un montant insignifiant avec son dépôt de garantie, une fois tous les deux cycles.

Le processus de désactivation des délégués n’affecte en aucun cas les droits de vote associés aux changements de protocole. Les droits de vote associés au consensus sur la création et la validation des blocs et des transactions, sont distincts des droits de vote associés au consensus de propositions d’amendements au protocole.

Les liasses (Rolls)

Théoriquement, il est possible de définir un ID pour chaque token. Ce qui permettrait de tracer parfaitement chaque token assigné à un délégué. Mais cette technique ne serait pas efficiente. En effet, cette méthode demanderait aux nœuds de stocker des informations d’une granularité tellement fine, que les ressources (notamment SSD et RAM) nécessaires pour stocker et communiquer ces informations seraient gigantesques. Les ressources seraient d’autant plus grandes, que l’adoption et l’utilisation du protocole conduirait à une croissance exponentielle des transactions. Dès lors, les nœuds ne seraient réservés qu’à une élite disposant de ces ressources rares et chères. La blockchain serait alors hébergée par un nombre restreint de nœuds, ce qui est contraire à la philosophie décentralisée.

Pour éviter cela, Tezos utilise le concept de Liasse. Une liasse « Roll », représente un ensemble de tokens, délégué à une clé donnée. Lorsque les tokens sont déplacés, ou qu’un délégué pour un contrat est modifié, la liasse change de délégué. Chaque délégué détient une pile de liasses ainsi qu’un peu de liquidités appelé « change », qui correspond à un montant bien moindre par rapport aux liasses.

Lorsque les tokens sont déplacés d’un délégué à un autre, c’est le « change » qui est utilisé pour subvenir aux frais de transactions. Si le change n’est pas suffisant, la liasse doit-être dissoute. Dans ce cas, les tokens sont déplacés d’une pile déléguée à une pile commune non-allouée. Et cela, tant que le montant nécessaire pour former une liasse n’est pas recouvert, en plus d’un peu de liquidités, le « change ».

Si le change est suffisant, l’autre délégué est crédité. En premier, le montant est ajouté au change. S’il devient plus grand que les tokens par liasse, alors les liasses sont désempilées de la pile commune non-allouée, et ré-allouées dans la pile déléguée. Si la pile commune est vide, une nouvelle liasse est alors créée.

Ce mécanisme préserve l’affectation de la liasse lorsqu’un délégué est changé après plusieurs transactions. Même si chaque opération déplace moins qu’une liasse complète. Traçer les tokens de cette façon est avantageuse. Notamment lorsqu’un délégué tente de créer un fork malveillant. Dans ce cas, il ne pourrait pas changer l’affectation des liasses en sa faveur. Même s’il contrôle les tokens sous-jacents.

Chaque liasse contient 10 000 tokens. Au total, 80 000 liasses sont prévues par Genesis Block, plus le nombre de liasse qui augmentera avec l’inflation et/ou la participation dans la délégation.

Les captures de liasses (Rolls Snapshot)

Il s’agit d’une photo des liasses à un instant « t ». Cela permet de sauvegarder l’état des liasses pour un bloc donné. Cette photo est prise tous les 256 blocs. C’est-à-dire 16 fois par cycle. C’est le meilleur compromis entre la consommation de mémoire et l’efficacité économique. Si les captures des liasses sont trop fréquentes, elles consommeront beaucoup de mémoire. Si elles sont trop rares, cela encouragera les tactiques opportunistes. En effet, certains participants pourraient acheter beaucoup de tokens par anticipation du Snapshot, et les revendre après. Ce qui introduirait un effet de « saisonnalité » sur le prix des tokens et une forme de déséquilibre économique.

Les Cycles

Dans la blockchain de Tezos, les blocs sont groupés au sein de cycles. Chaque cycle contient 4 096 blocs. Sachant que le temps entre la création de 2 blocs (blocktime) est d’1 minute, cela signifie qu’un cycle dure au moins 2 jours, 20h et 16 minutes.

Les dépôts de garantie

Le coût d’un dépôt de garantie est de 512 XTZ par bloc créé (baking) et de 64 XTZ par approbation (endorsement).

Chaque clé de délégation est associée à un compte de dépôt de garantie (security deposit). Lorsqu’un délégué créé (bakes) ou approuve (endorses) un bloc, le dépôt de garantie est automatiquement transféré au compte de dépôt (deposit account), où il est mis sous séquestre pendant un certain nombre de cycles. Ces cycles de gel des garanties, constituent les cycles de préservation. Une fois la période de séquestre écoulée, le dépôt de garantie retourne automatiquement au compte principal du délégué.

La présence de dépôt de garantie ainsi que d’une période de conservation, obligent les délégués à détenir un certain pourcentage de l’ensemble de leurs tokens. Plus de 8,25% de l’ensemble des tokens devraient constituer ce dépot de garantie.

Les droits de Baking

Le Baking est l’action de signer et de publier un bloc. Le protocole Bitcoin associe le droit de publier un bloc avec la résolution d’un algorithme de preuve de travail (Proof of Work). Dans le protocole Tezos, le droit de publier un bloc au sein d’un cycle « n » est associé à une sélection aléatoire d’une liasse, à partir d’une sélection aléatoire de snapshots depuis le cycle « n »- les cycles de préservation – 2.

Le protocole génère un « seed » aléatoire pour chaque cycle. A partir de ce seed aléatoire, il est possible de générer un CSPRNG (Cryptographically Secure Pseudo-Random Number Generator), qui est utilisé pour établir les droits de Baking pour un cycle.

Au sein du cycle, chaque emplacement est associé a une liste de délégués. La liste des délégués est établie  aléatoirement à partir du groupe de liasses actives. Il est donc possible que la même clé publique (le même délégué) apparaisse plusieurs fois dans cette liste. Cette liste est ordonnée. C’est-à-dire que le premier délégué dans la liste est le premier à pouvoir baker. Si le délégué est, pour une quelconque raison (par exemple, un dépôt de garantie insuffisant, ou bien offline à cause d’une coupure Internet), incapable de baker, alors le prochain délégué sur la liste prend le relais et bake le bloc. Ainsi, la priorité ayant une valeur de 1, prend dans ce cas la valeur 2. Cela signifie que le délégué de premier choix, est relayé par un délégué de second choix.

Le délégué ayant la plus haute priorité sur la liste, peut baker un bloc. Ce bloc doit respecter deux caractéristiques : avoir un horodatage (timestamp) plus grand que celui du bloc précédent, auquel est ajouté le blocktime (durée qui sépare la création des deux blocs successifs, correspondant à 1 minute dans le protocole Tezos).

Baker un bloc donne une récompense de 16 XTZ, plus l’ensemble des fees payées par les transactions au sein de ce bloc.

L’approbation (Endorsment)

Chaque emplacement de baking, est associé à une liste de 32 approbateurs (endorsers). Les endorsers sont établi à partir du groupe de délégués, en sélectionnant aléatoirement 32 liasses (avec les liasses de rechange).

Chaque endorser vérifie que le dernier bloc « n » a bien été baké, en émettant leur approbation. L’opération d’approbation, qui regroupe l’ensemble des 32 approbations, devient une caractéristique du bloc « n », et est baké dans le bloc suivant. Une fois que le bloc suivant est baké, aucune autre approbation pour le bloc « n » sera prise en compte.

Les approbateurs reçoivent une récompense, de la même manière que les créateurs de blocs. La récompense est calculée par la formule : Récompense d’approbation = 2 / Priorité du bloc. La priorité du bloc prend la valeur minimale de 1. Car cette valeur désigne l’emplacement du baker, au sein de la liste.

Le même endorser peut-être séléctionné plusieurs fois pour le même bloc. Dans ce cas, plusieurs dépôts sont nécessaire et plusieurs récompenses sont remportées. Cependant, une seule opération doit être envoyée au réseau pour approuver plusieurs fois le même bloc. Il y a plusieurs approbations, mais une seule opération d’approbations.

Le critère (fitness)

Un critère est associé à chaque bloc. Celui-ci permet de déterminer la qualité de la chaîne conduisant ce bloc. Dans le protocole Bitcoin, ce critère correspond simplement à la longueur de la chaîne. Effectivement, lorsque deux suites de blocs sont proposées pour s’ajouter à la chaîne principale, elles entre en compétition. Dans ce cas, le choix d’une suite par rapport à l’autre s’effectue sur le critère de la longueur de la suite proposée. Si au bout d’un certain temps, la suite A est plus grande que la suite B, alors la suite A est ajoutée à la chaîne principale. Dans le protocole Tezos, la  longueur est aussi un critère de mesure. Mais il est complétée par le nombre d’approbation pour chaque bloc. Prenons un bloc n ayant un critère f. Lorsque le bloc « n » reçoit un nouvel entête contenant « e » d’approbations, la caractéristique « f » du nouvel entête est de « f+1+e ».

L’inflation

L’inflation provenant des récompenses de blocs et d’approbations, est au plus de 80 XTZ, soit au plus de 5,51% par an. L’inflation est calculée selon la formule suivante : Nb approbateurs par bloc * récompense d’approbation + récompense de création du bloc. Ce qui donne : 32 * 2 + 16 = 80 XTZ au maximum, par bloc créé et approuvé.

La suite aléatoire (random seed)

Le cycle « n » est associé à une suite aléatoire. Cette suite correspond à un nombre 256 bits. Elle est générée à la fin du cycle (n – cycles de préservations – 1), en utilisant les exigences données pendant le cycle précédent (n – cycles de préservation – 2), en une sortie chaque bloc par obligation = 32 blocs.

Les exigences sont révélées par le baker pendant le cycle précédent (n – cycles de préservations – 1). Si celles-ci ne sont pas respectées, les récompenses et les commissions de transactions du bloc incluant cette suite, sont confisqués. Le dépôt de garantie n’est pas concerné par ces sanctions.

La révélation est une opération. Plusieurs révélations peuvent-être inclues dans un bloc. Un baker reçoit une suite correspondant à une récompense d’1/8 XTZ pour introduire une révélation. Les révélations ne requiert pas d’espace bloc. Autrement dit, ces opérations n’entrent pas en compétition avec les transactions. C’est pourquoi elles sont gratuites. Un maximum de 32 révélations peuvent-être contenu par un bloc. Ainsi, 1 / (maximum de révélation * bloc par obligation) = 1/1024 des blocs dans le cycle sont suffisant pour inclure toutes les révélations.

Les révélations sont hashées ensemble pour générer une suite aléatoire à la fin d’un cycle. La suite du cycle précédent est d’abord hashée avec une constante, puis avec chaque révélation du cycle actuel. Une fois calculée, la nouvelle suite est stockée et utilisée pour le prochain cycle.

Les dénonciations

Si deux approbations sont données pour le même emplacement, ou deux blocs de la même taille par un délégué, ces actions peuvent-être dénoncées. La dénonciation sera faite par le baker, qui l’inclue comme une opération spéciale. Dans un premier temps, la dénonciation entraînera seulement la perte du dépôt de garantie pour une opération doublement signée (double dépense). Cependant, avec le temps, comme le risque de double signature deviendra assez faible, la dénonciation entraînera la perte de la totalité des dépôts de garantie. La première moitié de ces dépôts sera brûlée, l’autre moitié sera ajoutée à la récompense de bloc.

¹ Aucune valeur spécifique n’est mentionnée dans le document officiel.
² La valeur mentionnée dans le document officielle est de 5 cycles. Mais il n’est pas précisé si c’est une valeur d’exemple ou une valeur standard. A priori, il s’agit d’une valeur standard, ouverte au débat.

Cette article traduit les éléments du Whitedoc de Tezos sur le Proof of Stake.


0 commentaire

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *