DEV Community: Bertrand Presles

Le web décentralisé par la pratique

Bertrand Presles — Wed, 03 Nov 2021 15:18:25 +0000

Histoire

Le web d'aujourd'hui est basé sur le protocole HTTP, qui fonctionne en mode client/serveur de façon centralisé. Il y a d'un côté un point d'entrée unique qui va ensuite aiguiller les requêtes vers des ordinateurs qui hébergent le site web ; et de l'autre des clients, les fameux navigateurs, qui permettent de le consulter.

Ce mode de fonctionnement est très simple et rapide à mettre en place. Il nécessite cependant d'investir dans des équipements qui peuvent être coûteux si le nombre de visiteurs et/ou la quantité de données échangée entre les navigateurs et le site, sont très importants. De plus, l'hébergeur peut constituer un point unique de panne (single point of failure) si le site et ses sauvegardes sont hébergés que dans un data center donné. Certains auront peut-être à l'esprit l'incendie chez OVH en mars 2021.

Le web a commencé à se décentraliser grâce aux frameworks JavaScript tel que ReactJS, Angular ou VueJS qui permettent de déporter le travail de génération de l'interface utilisateur du côté du navigateur. Cependant, le serveur reste en charge des traitements métiers et des données.

Récemment, des technologies exploitant à la fois la cryptographie et les réseaux peer2peer (P2P) sont apparues pour offrir des solutions permettant également de décentraliser le stockage des fichiers et des données, ainsi que les traitements métier. Nous allons voir quelques unes de ces technologies dans cet article.

La blockchain

La blockchain a été théorisée dès 1991 par les chercheurs Stuart Haber et W. Scott Stornett, puis en 1992 avec l'introduction de la structure de données "Arbre de Merkle".

En 2004, les premières briques concrètes ont été lancées par l'informaticien Hal Finney en proposant un premier prototype d'algorithme de consensus, nommé la RPOW (Reusable Proof of Work).

Mais il faut attendre 2008 pour que la blockchain commence à véritablement sortir de l'ombre, avec la publication du livre blanc du BitCoin, première crypto-monnaie de l'histoire. C'est en janvier 2009 que le premier bloc de la blockchain BitCoin sera généré.

Toutefois, limiter cette technologie aux crypto-monnaies serait ne pas lui faire honneur. La blockchain est avant tout une base de données décentralisée, historisée (horodatée) et infalsifiable. Elle exploite la structure de l'arbre de Merkle et une génération régulière des blocs de données pour permettre de garantir à la fois l'intégrité des données et leur historisation.

On peut donc stocker dans une blockchain n'importe quelles données, que cela soit des données de transactions financières d'une crypto-monnaie, ou les caractéristiques de votre chat (cf CryptoKitties).

Qu'est-ce qu'un arbre de Merkle ?

Une structure d'arbre de Merkle consiste à relier tous les éléments entre eux de sorte que si on modifie n'importe lequel de ces éléments, tous les autres sont aussi impactés et les liaisons doivent être recalculées.

Les données ont chacune leur hash basé sur leur contenu, puis on remonte jusqu'à la racine qui aura un hash dépendant de l'ensemble des données enfants. De ce fait, dès lors qu'une seule donnée est modifié, il faut recalculer les hash parents et le hash racine. Cela permet de garantir l'intégrité des données.

Synchronisation P2P

En plus de sa sécurité apportée par la structure en arbre de Merkle, la blockchain fonctionne sur un réseau P2P où les données sont répliquées dans un grand nombre d'ordinateurs à travers le monde, qui se maintiennent synchronisés. Chaque ordinateur, aussi bien que n'importe quel autre dans le réseau, peut répondre à des demandes de clients frontaux.

Smart contracts

De plus, des implémentations plus récentes introduisent en plus la possibilité d'intégrer du code dans la blockchain, dans ce qui est appelé des smart contracts (contrats intelligents). Cela permet donc d'intégrer du code métier, infalsifiable, travaillant sur les données de la blockchain.

Une blockchain pionnière dans ce domaine est celle d'Ethereum, et c'est encore aujourd'hui la blockchain la plus utilisée pour les smart contracts.
Cependant, d'autres frameworks pour créer des applications utilisant une blockchain, tel que Substrate ou ARK, implémentent également des solutions de smart contracts, permettant d'embarquer du code métier interagissant avec les données de la blockchain et exposant une API pouvant être consommée par un site web ou une application mobile.

IPFS

Si la blockchain permet de résoudre la problématique côté serveur, et même si les frameworks JavaScript modernes permettent de faire en sorte que l'interface utilisateur soit rendue côté navigateur et donc de façon décentralisé, un problème demeure. En effet, les fichiers de cette interface devaient toujours être récupérés depuis un hébergement spécifique.

IPFS apporte une réponse comparable à la blockchain, mais en étant optimisé pour servir des fichiers. Comme la blockchain, il va stocker les fichiers en utilisant une structure d'arbre de Merkle pour les rendre très difficiles à falsifier. Il implémente également un système de réseau P2P, mais à la différence de la blockchain, tous les fichiers du réseaux ne sont pas systématiquement dupliqués.

IPFS est exécuté sur la machine cliente. Certains navigateurs comme Brave intègrent d'ailleurs directement le support d'IPFS.

Chaque utilisateur va enregistrer une copie des fichiers qu'il consulte sur le réseau. Ce qui diffère par rapport au cache traditionnel de votre navigateur, c'est que votre ordinateur peut servir de relai pour les fichiers que vous avez consulté. Autrement dit tout ordinateur connecté sur le réseau IPFS peut être serveur des fichiers qu'il dispose dans son dépôt IPFS local. Ainsi, chaque utilisateur est à la fois client et serveur.

C'est ce mécanisme qui permet à IPFS d'offrir une réelle décentralisation. Si une machine ayant le fichier que vous recherchez tombe en panne, il est fort à parier que d'autres machines auront une copie et pourront vous fournir ce fichier.

Créer et héberger un site en 100% décentralisé

En combinant les technologies des frameworks front JavaScript, de la blockchain, et IPFS, il est donc possible de créer et héberger un site web entièrement de façon décentralisé, sans avoir besoin de recourir à un hébergeur centralisé. Plus de crainte que votre site deviennent inaccessible à cause d'une panne, un incendie, ou autre incident.

Voyons concrètement ce que cela donne avec une application écrite en AngularJS et se connectant à un réseau d'ordinateurs utilisant la blockchain Duniter.

Application pratique: Césium

Pré-requis

Installer IPFS: https://docs.ipfs.io/install/
Récupérer le code source de Césium: https://github.com/duniter/cesium/releases/download/v1.6.12/cesium-v1.6.12-web.zip

Ajout du code source de l'application dans IPFS

Assurez vous d'abord d'avoir le démon IPFS démarré : ipfs daemon

Pour héberger un site en JavaScript sur IPFS, il suffit d’exécuter la commande suivante: ipfs add <répertoire_ou_fichier>

Ici, nous allons ajouter le répertoire de Césium:

mkdir cesium
cd cesium
unzip cesium-v1.6.12-web.zip
ipfs add -r ./cesium-v1.6.12-web

A la fin de l'ajout, vous devriez voir le hash du répertoire Césium sur la dernière ligne, qui ressemblera à celui-ci:

added QmesyTwkSYfLFrXMk4gHG5W6DwpBuv5hatUd8D3DVXxY4n cesium

Accéder au site

Maintenant que le site est ajouté, vous pouvez y accéder depuis n'importe quel navigateur : http://dweb.link/ipfs/<hash>

Exemple pour Césium avec le hash ci-dessus : http://dweb.link/ipfs/QmesyTwkSYfLFrXMk4gHG5W6DwpBuv5hatUd8D3DVXxY4n

Si vous êtes sur un navigateur intégrant IPFS, tel que Brave, vous pouvez aussi accéder au site en tapant: ipfs://<hash>

Exemple (toujours avec Césium) : ipfs://QmesyTwkSYfLFrXMk4gHG5W6DwpBuv5hatUd8D3DVXxY4n

Si votre navigateur dispose de l'extension IPFS Companion, le site se charge directement depuis votre ordinateur. Sinon, il devra d'abord se propager dans le réseau pour pouvoir être chargé.

Elle est moche cette adresse !

Évidemment, une telle adresse n'est pas facile à retenir. Fort heureusement, il est possible d'affecter un nom de domaine, tout comme pour n'importe quel site.

Pour cela, il faut avoir un service de DNS, et ajouter les entrées suivantes:

sous_domaine              IN CNAME dweb.link.
_dnslink.mon_sous_domaine IN TXT "dnslink=/ipfs/QmesyTwkSYfLFrXMk4gHG5W6DwpBuv5hatUd8D3DVXxY4n"

Par la suite, vous pourrez accéder à votre site avec l'adresse https://sous_domaine.domaine.ext, comme n'importe quel site.

Le backend

Lorsque vous accédez à cette application, vous verrez qu'elle se connecte automatiquement à un ordinateur du réseau Duniter qui utilise la technologie de la blockchain pour stocker les données (transactions, certifications, ...) de la crypto-monnaie Ğ1.

Vous pouvez voir la liste des ordinateurs du réseau de la blockchain dans la section Réseau de l'application.

De même, vous pouvez consulter le contenu de la blockchain dans la section Dernier blocs.

En bref

Si le web décentralisé n'est pas encore une réalité au quotidien, les briques de bases pour sa concrétisation existent déjà. Il est donc d'ores et déjà possible de mettre en place une site web totalement décentralisé avec les technologies de la blockchain, IPFS et les frameworks front JavaScript tel que Angular, React ou Vue.

Cependant, ces technologies sont encore jeunes et avant que le web décentralisé supplante le web que nous connaissons aujourd'hui, il se passera certainement encore plusieurs années.

En attendant ce jour, veillez à choisir un hébergeur ou une solution de cloud qui ne perdra pas vos données et votre site en cas d'incendie ;)

Une blockchain est-elle forcément énergivore ?

Bertrand Presles — Thu, 01 Apr 2021 10:02:37 +0000

La consommation énergétique est un reproche souvent entendu lorsque l’on parle de blockchain.
En réalité, le niveau de consommation d’une blockchain est lié à plusieurs facteurs souvent méconnus.

Nous allons voir comment une Blockchain fonctionne, pourquoi elle peut être énergivore, et quelques solutions permettant de limiter très fortement la consommation énergétique d'une Blockchain.

Nous nous attarderons en particulier sur l’une d’entre elles, la preuve de travail à difficulté personnalisée, qui est intéressante sur de nombreux aspects.

Qu'est-ce qu'une blockchain ?

C'est une solution de stockage de données très sécurisée et chronologique. Voyons comment fonctionne une blockchain pour assurer un fort niveau de sécurité et une historisation des données.

Une partie de la réponse est inscrite dans son nom "Blockchain" ou chaîne de blocs en français. Les données sont donc enregistrées dans des blocs reliés les uns aux autres.

Historisation des données

Chaque bloc est enregistré à un intervalle régulier (toutes les 10 minutes pour Bitcoin par exemple) et ils sont reliés entre eux dans l’ordre chronologique à intervalles réguliers, permet d’avoir l’historique des données stockées dans la blockchain.

Pour éviter que cette chronologie soit altérée, des mécanismes permettant de garantir l’intégrité des données sont mis en place.

Intégrité des données

Chaque bloc dispose d'un identifiant unique, appelé Hash, qui est calculé à partir non seulement de chacune des données stockées dans le bloc, mais aussi de l'identifiant (Hash) du précédent bloc.
Chaque donnée du bloc est liée à d’autres données dans une structure appelée Arbre de Merkel :

Ceci permet à la fois de garantir l'intégrité des données, puisque toutes les données étant liées les unes aux autres et les blocs liés aussi les uns aux autres, modifier la moindre donnée dans un bloc oblige à non seulement de recalculer les hashs des données du bloc, le hash du bloc et les hashs des blocs suivants.

Cette liaison permet aussi de garder un historique puisque, dans chaque bloc nous retrouvons en entête l'identifiant (Hash) du bloc précédent. Nous verrons aussi qu'il y a une régularité entre l'enregistrement de chaque bloc permettant d'avoir une chronologie régulière dans une horloge commune appelée « temps blockchain ».

Ce mécanisme permet de garantir l'intégrité et la chronologie des données, mais ce n'est pas le seul mécanisme entrant en jeu pour assurer la sécurité des données de cette solution de stockage qu'est la Blockchain.

Redondance des données

Un autre élément entrant en jeu dans la sécurisation des données dans une blockchain est la redondance de ces données entre les ordinateurs (appelés nœuds) du réseau permettant de s'assurer que si certains d'entre eux ont une défaillance quelconque, d'autres ont une copie identique des données et peuvent donc continuer à assurer le service.

C'est l'entièreté de la chaîne de bloc qui est stockée dans chacun des nœuds du réseau. De ce fait chaque nœud dispose d'une sauvegarde complète.

Les nœuds doivent donc rester synchronisés entre eux en permanence. Pour cela, il faut déterminer d'une part quel participant au réseau sera celui qui signe le prochain bloc et d'autre part, un protocole permettant de propager le nouveau bloc.

Pour déterminer quel nœud signera le prochain bloc, on utilise ce qu'on appelle un algorithme de "Consensus". Il a deux missions :

Permettre de déterminer un nœud pour signer et écrire le prochain bloc.
S'assurer qu'aucun nœud en particulier ne puisse prendre seul le contrôle du réseau et des données.

C'est cet algorithme qui peut être plus ou moins énergivore, et nous allons voir les différents algorithmes de "Consensus" existants, leurs avantages et inconvénients non seulement en termes de consommation énergétique, mais aussi par rapport aux missions citées ci-dessus, en particulier concernant la gouvernance du réseau.

Les algorithmes de consensus : le nerf de la guerre énergétique

Nous allons voir quelques algorithmes de consensus les plus courants et détaillerons plus précisément un algorithme qui allie à la fois les avantages d’un consensus ne favorisant aucun membre du réseau au départ et une consommation énergétique contrôlée.

À l'origine : la preuve de travail

Le premier algorithme de consensus utilisé dans l'histoire des blockchains est celui adopté pour le Bitcoin, à savoir la preuve de travail.

Son principe est de faire participer l'ensemble du réseau à un exercice cryptographique visant à trouver un Hash respectant un certain schéma.
Sur Bitcoin, le schéma à respecter est un certain nombre de zéro au début du Hash.

L'algorithme de hashage utilisé par la blockchain Bitcoin est le SHA256. Avec cet algorithme, plus il y a de zéros à trouver au début du Hash, plus cela est difficile et plus cela requiert de la puissance machine pour y arriver dans un temps donné.
C'est pourquoi on appelle cette contrainte : la difficulté.

Dans le cadre de Bitcoin, le délai pour trouver une solution respectant le nombre de zéros, est de 10 minutes. Pour que cette durée reste régulière, car elle sert aussi à l'horloge du réseau, la difficulté, c'est à dire le nombre de zéros à respecter, est réévaluée régulièrement pour tenir compte de l'évolution de la puissance globale du réseau.

Pour trouver la solution, chaque nœud va hasher le bloc, à partir non seulement des données du bloc, du hash du bloc précédent, mais aussi d'une variable appelée "Nonce", incrémentée de 1 à chaque nouvel essai. C'est cette variable qui permet de jouer sur le résultat du hashage et ainsi essayer de trouver un Hash respectant le schéma.

Les algorithmes de consensus alternatifs les plus courants

La preuve de travail est une première solution, et elle a l'avantage principale de ne favoriser aucun noeud initialement au niveau de l'algorithme, mais elle a l'inconvénient d'être énergivore, en particulier si la puissance du réseau est importante, car il faut que le rythme de validation d'un bloc toutes les 10 minutes soit conservé.

Concernant le Bitcoin, le réseau est constitué de plus de 11300 noeuds actifs à l'heure où sont écrites ces lignes (https://bitnodes.io/dashboard/), dont un certain nombre sont des fermes de machines très puissantes et consommatrices. Le fait qu'un mineur récupère 6,25 BTC (soit 88500 € à l'heure où sont écrites ces lignes) par bloc validé n'est pas étranger à cela.

Afin de résoudre cette problématique, d'autres algorithmes de consensus ont été imaginés, voyons les principaux.

Preuve d'enjeu ou preuve de détention (Proof of Stake)

La preuve d'enjeu est le deuxième algorithme de consensus le plus populaire dans les blockchain publiques. A la différence de la preuve de travail, il ne nécessite pas d'effectuer un calcul mathématique pour déterminer le prochain nœud signant le bloc.

Pour éviter de faire un calcul, il demande aux participants du réseaux de mettre en réserve (sorte de caution) une certaine quantité de tokens (unités de la blockchain).
L'algorithme prend ensuite successivement les X nœuds (X étant paramétrable) qui ont le plus de tokens en réserve pour signer les blocs.

Une variante de cet algorithme est la Delegated Proof-of-Stake, qui se différencie par le fait que les participants doivent recevoir des "votes" sous forme d'une quantité de tokens, de la part d'autres utilisateurs ayant déjà des tokens, pour participer à la validation des blocs. On pourrait presque dire que les noeuds pouvant signer les blocs sont "élus".

Vous avez peut être déjà identifié l'inconvénient principal de cette approche. Les personnes ayant le plus de tokens et donc qui peuvent en mettre davantage en réserve (PoS) et/ou recevant le plus de votes (DPoS), sont favorisés par rapport aux autres. Et évidement, puisqu'il y a très souvent une récompense à la validation d'un bloc, les premiers arrivés sont avantagés par rapport aux autres.

Par contre, cet algorithme consomme très peu d'énergie, puisqu'il n'a pas besoin de faire calculer les noeuds pour déterminer le prochain noeud validant.

Preuve d'autorité (Proof-of-Authority)

La preuve d'autorité est apparue plus tard, et s’appuie non plus sur une quantité de token mise en réserve, mais l'identité.
Pour pouvoir valider des blocs, chaque participant doit être élu par les participants existants et publier son identité.

Cela se rapproche donc d'un fonctionnement centralisé, où il y a un groupe d’ordinateurs sélectionnés à l’avance qui sont les seuls à pouvoir valider les blocs. Cette approche est donc non adaptée aux blockchains publiques qui se veulent être ouvertes à tous.

Comme la Proof-of-Stake, les noeuds n'ont pas à faire de calcul pour être sélectionnés, et donc la consommation énergétique reste faible. Mais on voit par contre qu’on perd en grande partie l’approche décentralisée initiale des blockchains.

Une approche originale : La preuve de travail à difficulté personnalisée (Personalized Proof-of-Work)

Plus récemment, en 2017, est apparue la preuve de travail à difficulté personnalisée. Elle tente de combiner les avantages de la preuve de travail (pas de présélection des nœuds) tout en réduisant ses inconvénients en terme de consommation énergétique.

Une solution d’identification décentralisée : La toile de confiance (Web of Trust)

Tout comme dans la preuve d'autorité, les participants sont identifiés, mais à l'aide de leur clé publique. Ils peuvent donc librement choisir de pas publier leur identité réelle.
Pour éviter d'utiliser un mécanisme d’identification centralisé, un système d’identification décentralisé appelé "Toile de confiance" (Web of Trust), a été conçu et implémenté.

Celui-ci fonctionne par un mécanisme de parrainage (certification), qui, contrairement à la preuve d'autorité, n'est pas seulement réservé à ceux qui participent au réseau mais est ouvert à tous les utilisateurs qu'ils valident ou pas des blocs (i.e : qu’ils soient mineurs/forgeurs ou non).

Pour être membre, un utilisateur doit se faire certifier par 5 autres utilisateurs minimum (pour faire simple, car il y a des conditions plus complexes en réalité, pour protéger d’une éventuelle attaque Sybille (prise de contrôle de la toile de confiance)).

Les nouveaux tokens ne sont pas créés en récompense du minage, mais par tous les utilisateurs

Les validateurs de blocs (mineurs/forgeurs) ne reçoivent pas automatiquement une récompense, c'est tous les utilisateurs identifiés qui voient leur compte crédité tous les jours d'un montant identique entre tous, appelé Dividende Universel (DU). C'est par ce mécanisme que sont créés les nouveaux tokens de la blockchain.

Le calcul de ce DU se fait selon une équation établie dans une théorie monétaire appelée la Théorie Relative de la Monnaie de Stéphane Laborde.

Elle est la suivante lorsque le nombre d'utilisateur est globalement stable (varie peu) :
.
avec et ev = Espérance de vie moyenne (~80 ans en Europe).

Dans le cas d’un nombre d’utilisateurs plus variable, comme c’est bien souvent le cas dans les crypto-monnaies décentralisées, le calcul du DU est plus fin pour lisser les effets des entrants et sortants, et répond à l’équation suivante :

Le montant du DU est recalculé tous les 6 mois pour tenir compte de l'évolution du nombre d'utilisateurs et de la quantité de tokens en circulation pour faire en sorte que chacun crée une quantité de token convergeant vers la moyenne du total de token en circulation au bout de 40 ans (du fait que le coefficient c est calculé selon la demi espérance de vie moyenne en Europe).

Ceci permet de faire en sorte que les participants au réseau ne le fassent pas par intérêt de la récompense. Ce qui évite la course à la puissance entre les participants au réseau.

Une consommation énergétique contrôlée

Vous l’aurez compris, cette toile de confiance permet d’identifier, anonymement et de façon décentralisée, les utilisateurs, et donc également les propriétaires de nœuds mettant à disposition des ordinateurs pour valider les blocs.

Ceci permet alors d’appliquer une difficulté personnalisée à chaque propriétaire de nœuds et permet ainsi d'ajuster la consommation énergétique du calcul de la preuve de travail.

Par ailleurs une limite haute est mise en place pour exclure du calcul les noeuds ayant une difficulté supérieure à celle-ci.

Pour faire varier la difficulté deux mécanismes sont mis en place :

Le facteur d'exclusion

Le facteur d'exclusion est appliqué sur le nœud ayant validé le dernier bloc, il fait en sorte d'exclure du calcul, pendant un nombre de blocs, les noeuds des membres ayant récemment validé un bloc.

L’intérêt est double, il permet non seulement de limiter la consommation énergétique, puisque ces nœuds ne participent plus du tout au jeu mathématique de la preuve de travail, mais aussi d’éviter que des super-calculateurs ou fermes de calcul puissent prendre le contrôle de la blockchain.

Voici comment il est calculé :

Avec nbNoeudsCalculants, le nombre de noeuds ayant participé au calcul pour la validation du dernier bloc trouvé par le membre, et nbBlocsValideesParLesAutres le nombre de blocs signés par le reste du réseau depuis que le membre considéré a trouvé son dernier bloc.

Si le membre est l’auteur du dernier bloc, alors la variable nbBlocsValideesParLesAutres sera égale à 0, puisqu’il vient de valider un bloc et donc aucun autre membre n’a validé de bloc depuis. Et de ce fait le facteur d’exclusion résultant sera d’autant plus élevé qu’il y aura de noeuds (0,67*nbNoeudsCalculants).

Les membres du réseaux ayant calculés moins récemment des blocs, auront eu des facteurs d’exclusion plus faible puisque le dénominateur viendra diviser le numérateur d’autant plus qu’il y a de blocs validés par les autres depuis qu’ils ont validés leur derniers blocs.

Mais le facteur d’exclusion seul n’est pas suffisant car si la difficulté personnalisée se limitait à cela, ce serait toujours le tiers des membres calculant les plus puissants qui écriraient des blocs, les deux tiers restants seraient presque toujours exclus.

C’est pourquoi, en plus de ce facteur d’exclusion, un autre paramètre intervient : le handicap.

Le handicap

Le handicap est appliqué sur les nœuds ayant validé notablement plus de blocs notablement que la médiane du réseau (nbMedianBlocsEcritsParNoeudsFenetreCourante) sur les X derniers blocs (fenêtre courante) : nbBlocsNoeudFenetreCourante.

Il permet donc de fortement défavoriser les nœuds les plus performants, afin de donner leur chance aux appareils les plus économes (ex : Raspberry Pi 3).

Et comme souvent la performance est liée à une consommation énergétique élevée, l’application de ce handicap permet de réduire l’impact énergétique du réseau.

Une approche respectant la décentralisation tout en réduisant la consommation énergétique

Le choix de se baser tout de même sur un mécanisme de preuve de travail permet de ne pas favoriser un sous ensemble de nœuds en particulier au départ, et la difficulté personnalisée permet de ne pas favoriser les appareils les plus performant et au contraire laisser une chance y compris aux appareils peu performants mais beaucoup moins consommateurs en énergie.

La consommation énergétique est donc mécaniquement bien plus faible par rapport à la preuve de travail classique. Les participants n’ayant aucun intérêt à investir dans des centres de calculs ultra-puissants.

Il y’a t’il une application pratique de la preuve de travail à difficulté personnalisée ?

Cette approche est utilisée par la crypto-monnaie Ğ1 et le logiciel gérant sa blockchain, et donc implémentant l’algorithme de preuve de travail à difficulté personnalisée, s’appelle Duniter. Ce dernier est écrit actuellement en TypeScript, mais une oxydation en Rust est en cours (appelée Dunitrust). La crypto-monnaie Ğ1 n’est pas mise en vente sur les plateformes d’échanges de crypto-monnaie, ce qui permet d’éviter la forte volatilité qu’ont de nombreuses autres crypto-monnaie.

Elle est utilisée par une communauté de plus de 2857 utilisateurs dans le monde, principalement en France, comme moyen d’échange lors d’événements concrets où les utilisateurs se rencontrent et l’utilisent pour s’échanger des biens et des services entre eux. Quelques commerçants l'acceptent également, comme le restaurant l'Etrillum à Nantes.

Bilan

Comme nous avons pu le voir, la blockchain n'est pas forcément énergivore, cela dépend de l'algorithme de consensus choisi. Nous avons vu que le choix de cet algorithme joue non seulement sur la consommation énergétique, mais aussi sur la gouvernance du réseau. Il est donc la clé de voute de la blockchain, et son choix n'est pas anodin.

En effet, nous avons vu avec la preuve de travail, que si la gouvernance du réseau est parfaitement décentralisée sans favoriser aucun membre du réseau à priori, la difficulté du jeu cryptographique étant identique pour tous, les membres peuvent jouer sur la puissance de leurs machines pour obtenir un avantage par rapport aux autres, au détriment de la consommation énergétique.

A l'inverse, nous avons vu que les preuves de détention (PoS/DPoS) et d'autorité (PoA), si elles permettent une consommations énergétique très faible, elles ont une gouvernance bien moins décentralisée et favorisant les personnes ayant le plus de tokens (PoS) ou de votes (DPoS) ou étant choisis par les participants existants (PoA).

Enfin, nous avons vu qu'en utilisant une preuve de travail en faisant varier la difficulté de façon personnalisé (PPoW) pour chaque membre en fonction de sa rapidité de calcul et de son différentiel de blocs validés par rapport aux autres, alors nous arrivons à allier une bonne gouvernance décentralisée avec une consommation énergique davantage maitrisée.

Déboguer comme un chef en PHP avec XDebug

Bertrand Presles — Thu, 17 Dec 2020 08:55:12 +0000

On retrouve encore trop souvent des développeurs PHP qui déboguent à l’ancienne avec des var_dump(), kint() ou dump().

Souvent, cela vient de la complexité à mettre en place XDebug et de la méconnaissance de son mode de fonctionnement.

Qu’est-ce qu’XDebug ?

XDebug est un outil de débogage pas à pas, qui permet de placer des points d’arrêt (breakpoints) et de suivre l’exécution en temps réel en consultant les variables ainsi qu’en pouvant évaluer et modifier leurs valeurs.

Maîtriser un tel outil fait gagner énormément de temps dans l’analyse d’un bogue.

Pourquoi choisir le débogage avec XDebug ?

Le débogage avec XDebug est certes plus complexe à mettre en place initialement car il demande de configurer votre environnement d’exécution (extension PHP XDebug + paramétrage) et votre IDE. Mais cette opération n’est à faire qu’une fois sur votre poste par projet. Ensuite, vous n’avez qu’à lancer la session de débogage sans rien avoir à configurer de plus.

Par rapport à du débogage à l’ancienne, c’est-à-dire avec des traces de log, vous gagnerez énormément de temps du fait de pouvoir visualiser et manipuler les variables (expression, définition de valeur), aussi bien dans le contexte du code où sont posés les points d’arrêt qu'en remontant la pile d’exécution.

Comment fonctionne XDebug ?

XDebug va se connecter à votre IDE. Il faut donc s’assurer que l’environnement d’exécution de votre application écrite en PHP ait accès à votre IDE.

Si comme beaucoup vous utilisez Docker, cela veut dire passer par l’interface docker0 de votre conteneur, qui est l'interface qui permet de faire le pont entre votre conteneur et le système d'exploitation principal de votre machine.

Pour trouver l'IP de l'interface docker0, taper la commande suivante :

macOS et Linux : ifconfig



  docker0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
          inet 172.17.0.1  netmask 255.255.0.0  broadcast 172.17.255.255
          inet6 fe80::42:a3ff:febc:7ab4  prefixlen 64  scopeid 0x20<link>
          ether 02:42:a3:bc:7a:b4  txqueuelen 0  (Ethernet)
          RX packets 0  bytes 0 (0.0 B)
          RX errors 0  dropped 0  overruns 0  frame 0
          TX packets 13430  bytes 1949419 (1.9 MB)
          TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

Windows : ipconfig (chercher l'interface DockerNAT)

Installation de XDebug

XDebug est disponible sous la forme d’une extension PHP. Bien souvent pour l’installer, il suffit d’installer le paquet de cette extension sur votre machine de développement ou dans votre conteneur.

Je vais donner la commande pour une Ubuntu 20.04 LTS, mais je vous invite à vous référer à la documentation de votre image Docker ou de votre distribution pour trouver les instructions d’installation :



apt install php-xdebug

Configuration de XDebug

C’est la partie la plus délicate, il est impératif de bien comprendre chacun des paramètres pour pouvoir ensuite identifier les éventuels problèmes de configuration qui pourront expliquer les dysfonctionnements potentiels.

Les paramètres importants pour déboguer en distant, c’est-à-dire d’un conteneur vers votre IDE sur l’hôte, sont les suivants :

xdebug.remote_enable => A valoriser à 1 pour activer.
xdebug.remote_host => Mettre l’IP de l’interface docker0 du conteneur ou host.docker.internal sous Docker for Mac ou Docker for Windows.
xdebug.remote_port => En général 9000, mais pourra être changé dans l’IDE.
xdebug.idekey (optionnel) => Un identifiant unique (utile si vous voulez exécuter plusieurs sessions de débogage en même temps sur des applications différentes).

Exemple de configuration :



/etc/php/7.4/fpm/conf.d/20-xdebug.ini
zend_extension=xdebug.so

xdebug.remote_enable=1
xdebug.remote_host="host.docker.internal"
xdebug.remote_port=9000

Activation dans votre IDE

Visual Studio Code

Sous VSCode, il vous faudra installer l’extension "PHP Debug" de Félix Fbecker puis créer un launch.json dans le répertoire .vscode avec le contenu suivant :



{
    "version": "0.2.0",
    "configurations": [
        {
            "name": "Listen to XDebug",
            "type": "php",
            "request": "launch",
            "port": 9000,
            // server -> local
            "pathMappings": {
                "/var/www/docroot": "${workspaceRoot}/docroot"
            },
            "xdebugSettings": {
                "max_children": 128,
                "max_data": 512,
                "max_depth": 5
             }
        }
    ]
}

La clé pathMappings est utile si vous utilisez des conteneurs ou que votre application s’exécute sur un serveur distant, il permet d'indiquer la correspondance entre le chemin dans le conteneur, ou sur le serveur, et le chemin sur votre environnement local (hors conteneur).

Une fois cela fait, vous lancez le profile "Listen to XDebug" et vous pouvez commencer à déboguer.

PHPStorm

Vous devez vous assurer que le port d'écoute pour XDebug dans PHPStorm est configuré en accord avec votre configuration PHP (9000 par défaut) :

Puis ajouter une configuration de lancement :

Si vous utilisez un conteneur ou que votre application s’exécute sur un serveur, cochez l'option "Use path mappings" pour définir la correspondance entre le chemin dans le conteneur, ou sur le serveur, avec vos fichiers sur votre machine locale.

Ensuite il suffira de lancer le debug en mode écoute :

Si vous avez plusieurs applications qui tournent et que vous voulez déboguer l’une d’entre elles en particulier, vous pouvez utiliser la clé de session (idekey).

Dans ce cas, il faut désactiver l’écoute (avec l'icône en forme de téléphone), et appeler l’URL à déboguer avec le paramètre XDEBUG_SESSION_START valorisé avec la clé de session configuré dans votre IDE (ex : XDEBUG_SESSION_START=PHPSTORM).

Cela peut être simplifié en utilisant l’extension navigateur XDebug Helper :

Pour Firefox: https://addons.mozilla.org/en-US/firefox/addon/xdebug-helper-for-firefox/
Pour Chrome/Chromium/Brave/Opera: https://chrome.google.com/webstore/detail/xdebug-helper/eadndfjplgieldjbigjakmdgkmoaaaoc

Ligne de commande

Il est également possible de lancer le débogage pour une application PHP en ligne de commande.

Pour cela, il suffit de définir les paramètres XDebug via la variable d’environnement XDEBUG_CONFIG :



export XDEBUG_CONFIG="remote_enable=1 remote_host=<ip_docker0_ou_localhost> remote_port=9000 idekey=<vscode ou PHPSTORM>"

Si votre IDE est PHPStorm, il faudra en plus définir la variable PHP_IDE_CONFIG pour spécifier le nom de la configuration serveur ayant le path mapping correspondant à votre conteneur Docker ou à votre serveur :



export PHP_IDE_CONFIG="serverName=<nom_config_serveur>"

Ensuite, lancez votre script PHP CLI.

Fonctionnalités de débogage

Les points d’arrêt

L’élément principal dans un débogage pas à pas sont les points d’arrêt. Ils vous permettent d’indiquer à votre IDE à quel endroit vous souhaitez que l’exécution s’arrête pour inspecter le contexte de l’application à ce moment-là.

Il existe deux types de points d’arrêt :

les points d'arrêt inconditionnels,
les points d'arrêt conditionnels.

Comme vous l’avez certainement deviné, les points d’arrêts inconditionnels arrêteront l’exécution de l’application aux endroits où ils sont positionnés, quoiqu’il arrive, alors que les points d’arrêt conditionnels le feront que si les conditions définies sont remplies.

Ces derniers sont très pratiques pour déboguer des cas précis, en particulier sans avoir à passer ceux qui ne nous intéressent pas.

Pour placer un point d'arrêt, il suffit de cliquer devant une ligne sur la colonne à gauche de l'éditeur.

Pour définir une condition sur le point d'arrêt, il suffit de cliquer droit sur un point d'arrêt existant (ou clic-droit puis sélectionner Edit breakpoint sous VSCode).

L’inspecteur de variables

L’autre outil à disposition est l’inspecteur de variables. Vous aurez peut-être remarqué, dans la configuration de VSCode, nous avons mis des paramètres de profondeurs d’inspection (max_children, max_data, max_depth), ils permettent de définir la profondeur d'inspection des variables, comme, par exemple, dans des tableaux ou objets, directement depuis cet inspecteur. Nous n’avons pas eu à définir ces paramètres sous PHPStorm parce que dans son cas ils sont déjà assez importants par défaut.

Voyons à quoi ressemble cet inspecteur sous PHPStorm :

Et sous VSCode :

En plus d’inspecter les variables déclarées dans le contexte du point d’arrêt courant, il est possible de sélectionner une ligne de la pile d’exécution pour visualiser les variables des éléments appelants, ce qui est très pratique quand le bogue provient en réalité d’un élément plus en amont dans la pile d’exécution.

Sous PHPStorm, cet inspecteur de variables permet également de modifier dynamiquement la valeur d’une variable :

L’inspecteur d’expressions

Un autre outil très puissant dans le débogage pas à pas est l’inspecteur d’expressions.

Celui-ci vous permet de définir des expressions complexes, ce qui peut s'avérer très utile, par exemple pour cibler un élément particulier d’un tableau, ou visualiser la taille d’une chaîne de caractère ou d’un tableau, sans modifier le code :

Avancer dans le code

Si cela s'appelle un débogueur pas à pas, c'est parce qu'il permet, une fois arrêté à un endroit du code, d'ensuite le parcourir ligne par ligne ou jusqu'au prochain point d'arrêt.

Dans les captures d'écran ci-dessus, vous aurez peut-être remarqué les barres d'outils :

Barres d'outils des IDEs
PHPStorm
VSCode

Elle servent à parcourir le code:

	Commandes de progression dans le code
	Avancer jusqu’au prochain point d'arrêt
	Passer à la ligne suivante sans entrer dans la fonction
	Entrer dans la fonction
	Sortir de la fonction
	Reprendre l’exécution au début
	Interrompre la session de débogage

Les autres capacités de XDebug

En plus de proposer une fonctionnalité débogage pas à pas, XDebug est également capable de faire du profilage, afin de mesurer précisément les performances de votre code.

Le profilage mérite un article à lui seul, nous approfondirons ce sujet dans un autre billet.

Notre première conférence DevFest

Bertrand Presles — Tue, 02 Jun 2020 11:06:27 +0000

Lors de l'édition 2019 du DevFest, nous avons eu l'occasion pour la première fois de faire une présentation à un événement de cette envergure.

Nous prenons la plume pour vous partager notre expérience.

Avant tout, qui sommes-nous ?

Bertrand PRESLES : Architecte et expert technique web et mobile chez Younup, sur les technologies PHP, Javascript, Ionic, Angular. Avant cette expérience de talk au DevFest, j'avais fait quelques talks en interne dans les entreprises dans lesquelles j'ai travaillé, ainsi que lors de MeetUps publiques à Nantes. Je suis également adhérent de l'association Blockchain et Société depuis 2019.

Adrien LASSELLE : Développeur fullstack et passionné par mon métier, je suis également adhérent organisateur du meetup Nantais Blockchain & Société depuis 2018. Je suis intéressé par les cas d'usage autours de la techno Blockchain et Bertrand m'a fait découvrir Duniter et la monnaie libre début 2019.

De l'idée au CFP (Call For Papers)

Nous nous intéressons depuis plusieurs années aux technologies et applications autour de la Blockchain, et étant tous les deux membres de l'association Blockchain et Société de Nantes, nous participions déjà régulièrement à des MeetUps autour de la Blockchain, ce qui nous a permis de découvrir de nombreuses initiatives et projets autour de cette solution technologique.

Comme vous le savez probablement, dans le monde des blockchains, une problématique revient régulièrement : la consommation énergétique. Il existe plusieurs solutions pour résoudre cette problématique, et nous avons été particulièrement séduits par l'approche qu'a adoptée la blockchain Duniter.

En approfondissant l'étude de cette blockchain, nous avions décidé de faire une présentation de celle-ci et de la crypto-monnaie associée lors d'un MeetUp de Blockchain et Société à Nantes, dans un format assez court et synthétique. Suite à cette première expérience nous avons eu de bons retours de la part de l'auditoire.

La date des CFPs du DevFest 2019 approchant, nous avons pris la décision de proposer une conférence plus technique et détaillée présentant l'approche de cette solution au DevFest.

Nous avons donc soumis notre candidature. Pour nous aider, nous avons consulté des personnes qui ont déjà eu l'expérience du DevFest, notamment pour faire relire notre soumission (titre, description, références), car il est important d'avoir un titre accrocheur et une description claire et concise.

Dans l'attente de la sélection

Entre la soumission du sujet sur la plateforme de CFP du DevFest et la validation, il se passe environ 3 mois au minimum.

Pendant ce temps, nous avions déjà commencé à travailler sur le talk, tablant sur le fait que même si nous n'étions pas sélectionnés, nous pourrions le proposer dans d'autres événements.

3 mois après, nous avons reçu un mail nous informant que nous étions mis sur liste d'attente, si jamais d'autres conférenciers se désistaient. Sur le moment un peu déçu, mais nous gardions espoir... et nous avions eu raison d'y croire car quelques jours après nous apprenions que nous étions mis au programme du DevFest 2019 ! Les choses sérieuses commençaient !

À l'approche du DevFest...

Durant cette période nous avons travaillé sur le contenu et la forme de notre présentation, et nous avons fait deux répétitions ensemble.

Plus le DevFest s'approchait, plus le stress se faisait ressentir, même si ce dernier a été atténué lorsque nous avons appris que notre conférence se déroulerait le premier jour en début d'après midi.

Peu avant le DevFest, nous avons fait une répétition de notre conférence avec d'autres personnes, ce qui nous a permis d'avoir un regard extérieur sur notre présentation.

La veille du DevFest

La veille, nous avons été invités à participer à une soirée entre speakers, sous le signe du rock, thème du DevFest 2019, où nous avons pu accéder à une exposition sur le rock au Château des Ducs de Bretagne de Nantes, suivie d'un apéro dînatoire.

Cette soirée très enrichissante et sympathique nous a permis de discuter et échanger avec les autres speakers et les organisateurs.

Le jour J

En attendant notre conférence, nous avons profité des autres conférences du DevFest, et un peu avant l'heure, nous nous sommes isolés dans l'espace privatif dédié aux speakers.

En effet, les speakers du DevFest bénéficient d'un espace à part, au calme, leur permettant de répéter et faire les derniers ajustements. Étant donné l'affluence dans les couloirs du DevFest, ce petit havre de paix est particulièrement bienvenu.

L'heure H

Un petit quart d'heure avant le talk, nous nous rendons dans la salle qui nous a été attribuée. Plus habitués aux petites salles des MeetUp locaux, nous sommes impressionnés par la taille de la salle, qui comportait plus de 300 places.

En arrivant sur l'estrade, nous sommes bien accueillis. En effet pour chaque présentation, une personne est affectée pour accueillir les speakers et introduire le talk (le "MC"). Celui-ci nous met à l'aise, nous installe nos micros cravates et fait un dernier point avec nous sur nos profils et l'introduction de la présentation.

Nous voyons petit à petit la salle se remplir, et le sentiment de stress monte proportionnellement. Puis vient l'introduction de la conférence, on ne peut donc plus reculer, il va falloir se jeter dans le grand bain.

Le talk

Une fois lancés dans le talk, le stress redescend, et pris par la passion du sujet que nous présentons, l'effet de stress, que les 300 personnes qui sont devant nous faisait, est en grande partie retombé.

Évidemment, ce serait vous mentir de dire que tout s'est déroulé sans la moindre hésitation, le moindre bafouillage ou la moindre erreur, nous en avons eu mais, finalement, pas tellement plus que devant 20 à 30 personnes lors d'un MeetUp.

Les questions

Vient ensuite le temps des questions, et là le stress remonte d'un cran, d'innombrables interrogations traversent nos esprits : A t'on été suffisamment clair ? Avons-nous dit des bêtises ? Avons-nous respecté la promesse de départ ? Qu'en ont pensé les personnes du public ?

Mais les regards rassurants de nos collègues et les applaudissements du public nous rassurent, ce qui fait un peu retomber le stress.

Cette période de questions a été pleine d'enseignements, et nous a permis, par la suite, de compléter notre présentation.

Bilan et conseils

On pourrait croire que, dans un événement de la taille du DevFest, c'est le nombre de spectateurs qui est le plus impressionnant. Ca l'est en effet les premières minutes avant de démarrer, mais cela retombe très rapidement, et ce n'est finalement pas tellement plus stressant que lors d'un MeetUp.

Si vous êtes intéressés pour participer à un événement de cette taille, mais que vous n'avez pas fait de présentation dans des événements de cette taille, n'hésitez surtout pas, lancez-vous ! Le plus important est que vous fassiez une présentation qui vous plaît, que vous y preniez du plaisir !

Évidemment, mieux vaut tout de même vous préparer avant en faisant des talks en interne dans votre entreprise et dans des MeetUps. Aussi, n'hésitez surtout pas à présenter votre talk à des personnes autour de vous, pour récolter leurs retours. Enfin, si c'est votre premier talk dans un événement de cette taille, nous vous recommandons de le faire au moins à deux plutôt que tout seul.