Notre nœud Tezos

La technologie blockchain a apporté un réel changement de paradigme en 2009 avec l'apparition de Bitcoin.

Depuis, les développeurs et la communauté n’ont cessé d’innover en faisant passer la blockchain d’une technologie permettant l’exécution de transactions relativement simples moyennant un fort coût énergétique, à une technologie puissante autorisant les transactions programmables et à faible coût énergétique.

Les protocoles dits de 1ère génération :

À l’image de Bitcoin, les protocoles de 1ère génération utilisent un consensus par preuve de travail (PoW). Cette 1ère génération de protocole a permis de démocratiser la technologie mais souffre de nombreuses lacunes :

1. Avec ≈ 8 transactions par seconde et une attente de 30 minutes en moyenne (1 bloc + 2 blocs afin de limiter les risques de fork ou de « stale blocks ») pour valider une transaction, le réseau Bitcoin peut s’avérer limité pour certains cas d’usages,
2. Avec une technologie de smart contract limitée, le Bitcoin ne permet pas de développer des cas d’usage très avancés,
3. Le mécanisme de consensus par preuve de travail assure une sécurité forte mais est très énergivore et donc difficilement compatible avec les enjeux environnementaux.

Les protocoles dits de 2ème génération :

À l’image de l’Ethereum, les protocoles de 2ème génération apportent un environnement de développement stable (l’Ethereum Virtual Machine) qui permet l’apparition de cas d’usage étendus. Cependant, ces protocoles ne résolvent pas les points suivants :

1. L’interopérabilité entre les blockchains,
2. L’empreinte carbone du réseau qui est toujours un consensus par preuve de travail.
3. L’évolutivité du protocole 

Les protocoles dits de 3ème génération :

À l’image de Tezos, les protocoles de 3ème génération cherchent à répondre à l’ensemble des enjeux soulevés par les protocoles de 1ère et 2ème génération.

Le problème de la consommation énergétique est notamment résolu par le choix d'un consensus par preuve d'enjeu (PoS). Celui-ci limite en effet les calculs à effectuer pour valider un bloc : la sécurité du réseau repose désormais sur la détention de tokens et non sur la puissance de calcul. En effet, pour valider un bloc et sécuriser le réseau, les participants doivent mettre en gage une partie de leurs tokens et, dans le cas de Tezos par exemple, ils peuvent les perdre (« slashing ») s'ils se comportent de manière hostile envers le réseau.
Avec son protocole de Liquid Proof-of-Stake et son système d’ajouts et de validation de blocs appelé baking (voir « En quoi consiste le baking ? »), la blockchain Tezos réduit significativement l’énergie nécessaire pour délivrer un service hautement performant.

Les ressources nécessaires au fonctionnement d'un nœud Tezos sont limitées, l'enjeu ne se trouvant plus dans la puissance de calcul (CPU, GPU ou puce spécialisée) mais dans la stabilité de l'infrastructure.

Le choix de la technologie Tezos s'est fait naturellement afin d’accompagner nos clients qui souhaitaient avoir accès à un nœud pour leurs applications. Exaion suivait de près l'évolution du protocole.

Exaion a été sensible à la philosophie de la gouvernance « on-chain » de Tezos limitant le recours à des forks pour les mises à jour et laissant la possibilité à la communauté de prendre part à l'évolution du protocole.

De plus, le choix d'un langage qui facilite les validations par preuve formelle apporte une sécurité supplémentaire et vise directement les métiers ayant de fortes contraintes de fiabilité du code comme le secteur bancaire ou l'industrie de pointe.

Les concepteurs de la blockchain Tezos et de ses outils ont su faciliter la vie des développeurs grâce aux kits de développement qui font le pont entre les langages les plus répandus (Python, etc.) et Michelson (langage de Tezos pour les smart contracts). Michelson étant un langage à pile, sans variable, les développeurs de smart contracts préfèrent écrire leurs contrats dans un langage de plus haut niveau (via des librairies comme SmartPy ou Ligo), laissant le soin au compilateur de produire le code Michelson correspondant.

La vocation d’Exaion est de rendre accessible la blockchain aux grands groupes en se plaçant comme partenaire privilégié. Exaion accompagne les entreprises de la phase d'idéation à la phase de développement applicatif puis à l'hébergement sur ses propres infrastructures.

Ainsi, dans un premier temps, Exaion met à disposition de ses clients un nœud stable hébergé sur une infrastructure dédiée de niveau industriel. Le nœud a en outre été construit pour assurer une stabilité maximale à nos clients et aux personnes qui souhaitent participer au consensus en déléguant leurs jetons XTZ (voir : « Comment participer au consensus via le nœud Exaion ? »).

Dans un second temps, Exaion utilise le nœud comme porte d'entrée pour ses applications internes et pour les applications de ses clients. Au-delà du « baking », le nœud permet également de déployer des applications sur la blockchain.

Des services sur-mesure à destination de nos clients viendront s'adosser progressivement au nœud (custody, financement de gas pour les smart contracts, développement sur-mesure de smart contracts, etc.)

Vous pouvez déléguer depuis l'interface de votre wallet habituel (ex : Ledger) en spécifiant l’adresse de délégation suivante : tz1gcna2xxZj2eNp1LaMyAhVJ49mEFj4FH26

Exaion a souhaité trouver un équilibre entre la croissance du nœud et la rétribution aux délégataires. Ainsi, la politique de rétribution se fera en trois étapes :

1. Phase de préparation : frais de 4 % sur une période réduite de 2 semaines correspondant à la stabilisation et à la densification du nœud.
2. Phase de consolidation : frais de 7 %. Les XTZ issus des frais appliqués seront automatiquement réinvestis dans le nœud afin d'augmenter le nombre de rolls et, ainsi, d'augmenter le poids du nœud dans le réseau – et donc, à terme, la rentabilité globale du nœud. Dans cette phase, Exaion ajoutera régulièrement de nouveaux rolls au nœud pour lui permettre de suivre la croissance du nombre de délégataires.
3. Phase de production : frais réduit de 5 %. Les XTZ issus des frais seront utilisés pour financer le gas des transactions des applications/DApp des utilisateurs du nœud.

Le « baking » est le processus par lequel le réseau assure sa sécurité et sa stabilité. Il permet également de mettre en œuvre le modèle économique du protocole en créant de nouveaux XTZ à chaque nouveau bloc.

Concrètement, le processus de sécurisation se déroule comme ci-après :

• Toutes les périodes, un « baker » est choisi comme « maître » et 32 autres « bakers » sont choisis comme « appuis ».
• Un bloc prend environ 60 secondes dans la plupart des cas pour être proposé par le « baker », obtenir le soutien des « appuis » et être ancré dans la chaine de blocs.
• À chaque bloc, le « baker » met en garantie une partie de son « roll » de 8 000 XTZ et le récupère à la fin si le bloc est validé. C’est une mesure visant à sanctionner les tentatives de corruption de la blockchain Tezos qui consistent à volontairement introduire des blocs faux ou corrompus dans la chaîne de blocs.
• À la fin de la validation, le « baker » récupère les XTZ qu’il a mis en garantie et obtient une récompense qu’il partage avec les « appuis ».
• Le cycle recommence avec 1 nouveau « baker » et 32 nouveaux « appuis ».

Afin d’être sélectionné plus régulièrement et obtenir plus de récompenses, le « baker » peut « immobiliser » davantage de XTZ ou augmenter le nombre de XTZ qui lui sont délégués – dans la limite d’avoir au moins 8,25 % des XTZ qui lui sont délégués en propre (immobilisés). Ainsi, pour 8 000 XTZ (1 roll), un nœud peut accueillir environs 96 969 XTZ (ce chiffre varie également avec le nombre total de XTZ disponibles ou bloqués sur le réseau).

Non, chaque individu peut « déléguer » ses tokens (XTZ) en les prêtant à un « baker ». Le prêt s’effectue de manière automatique et sécurisée. Les tokens « délégués » restent la propriété de l’individu qui peut les récupérer à tout moment. De plus, le « baker » ne peut effectuer aucune action sur ces tokens « délégués », ils n’apparaissent pas non plus sur ses comptes. Ainsi, en cas de vol de la clé privée du « baker », les tokens délégués ne sont pas compromis et restent la propriété de l’individu.