Ted Yin | Quelle sera l'infrastructure de la blockchain en 2021 ?
TechFlow SélectionTechFlow Sélection
Ted Yin | Quelle sera l'infrastructure de la blockchain en 2021 ?
Ted Yin, architecte principal du protocole Avalanche et cofondateur, lors de son intervention à la BeWater DevCon 2021, conférence mondiale des développeurs.
Dédié à des analyses Web3 approfondies
Le 4 septembre 2021, lors de la conférence mondiale BeWater DevCon 2021 pour développeurs, Ted Yin, architecte principal du protocole et co-fondateur du protocole Avalanche (Snow Protocol), également auteur du papier sur le consensus HotStuff du projet Libra/Diem de Facebook, a participé en visioconférence depuis l'autre côté de l'océan pour présenter « Réflexions et applications pratiques autour d’Avalanche ».
Cette présentation approfondie et systématique a suscité une vive réflexion parmi tous les participants. Voici les points clés :
1. Quelle est l’infrastructure blockchain en 2021 ?
2. Évolution des deux premières générations de protocoles blockchain
3. Troisième génération de blockchains : le protocole Snow / Avalanche (« Neige »)
• La performance d'une blockchain ne doit pas se mesurer uniquement par son débit ; seul le couple « débit + latence » permet une évaluation complète ;
• Le concept de « sharding » (partitionnement), trop surestimé, n’est pas une solution universelle et reste lié aux cas d’utilisation concrets ;
• Nous pouvons utiliser un réseau de rumeurs comme mécanisme de consensus lui-même !
4. Conception d’une plateforme métavers et de chaînes secondaires (subnets)
Texte complet : 7011 mots, lecture de 12 minutes
I. Quelle est l’infrastructure blockchain en 2021 ?
Bonjour à tous ! Diplômé de l’Université Jiaotong de Shanghai, je suis co-fondateur d’Avalanche et architecte principal du protocole.
La diapositive suivante a déjà été utilisée en 2020. Certains pensent que je fais preuve de paresse, mais en réalité, certaines choses restent inchangées. Depuis nos recherches académiques jusqu’au lancement de notre mainnet l’année dernière, j’ai pu observer assez tôt, sous un angle académique, que bien qu’il y ait chaque année de nouveaux projets, l’infrastructure blockchain n’évolue pas aussi vite qu’on pourrait le croire. Cela peut vous surprendre, mais il n’existe pas tant de technologies fondamentalement différentes que cela.
Nous pouvons donc nous demander ce qu’est véritablement l’infrastructure blockchain ?
En combinant tous les éléments actuels — sharding, montée en charge, DAG, contrats intelligents, etc. — on obtient un « monstre hybride ultime », illustré par l'image ci-dessous.
Il ne s’agit pas ici d’une seule chaîne, mais de plusieurs chaînes agissant comme des sous-systèmes.
Par exemple, une chaîne linéaire servant de grand livre. Une fois qu’un ordre séquentiel est établi, on peut coder les calculs et opérations dans ce journal (log) ou ce registre (ledger), permettant ainsi de mettre en œuvre des dApps ou des contrats intelligents standards, comme ceux présents sur Ethereum, dont les opérations forment justement une séquence.
Autre exemple : une chaîne utilisant un graphe orienté acyclique (DAG). Dans certains systèmes, le DAG constitue une optimisation utile, permettant d'exécuter en parallèle des opérations indépendantes dans le temps. Par exemple, si A envoie de l'argent à B puis à C, tant que le solde d'A est suffisant, peu importe l'ordre des transactions entre B et C.
L’essentiel ici est que les structures de données isolées ont peu d’utilité ; elles doivent être mises en œuvre via un algorithme de consensus ou un protocole de cohérence afin d’assurer non seulement que le réseau soit distribué, mais aussi véritablement décentralisé. Chaque machine partage le même journal, et ces journaux sont compatibles entre eux, sans divergence.
La technologie blockchain a permis bien des avancées. On ne peut imaginer Alibaba ou Tencent exécuter leur système de paiement sur nos ordinateurs personnels, car leurs bases de données peuvent modifier arbitrairement les soldes. À qui faire confiance alors ? En revanche, avec les systèmes blockchain, nous pouvons tous exécuter un nœud.
Entre la chaîne et les dApps, il existe des agents intermédiaires comme Infura. Les développeurs n’exécutent généralement pas eux-mêmes un nœud complet ; ils testent localement, puis déploient via un nœud complet tiers.
II. Évolution des deux premières générations de protocoles blockchain
1. Première génération blockchain : l’ère Nakamoto
La première génération, représentée par Bitcoin, peut être comparée à une chaîne de commits Git, chaque commit ayant un hachage — Git étant donc, en un sens, une forme primitive de blockchain.
On pourrait même imaginer une preuve de travail dans Git : par exemple, imposer que chaque bloc de code ait exigé un certain nombre d’heures de développement, impossible à tricher. Ce serait alors la chaîne de commits la plus longue qui l’emporterait — exactement comme la règle de la chaîne la plus longue dans Bitcoin.
La preuve de travail ne peut être falsifiée, est facile à vérifier, et nécessite beaucoup de temps pour être produite dans tout le système. C’est ainsi que naît le consensus Nakamoto, où le grand livre finit par converger vers une seule chaîne principale, selon le principe de la chaîne la plus longue.
Avantage 1 : La preuve de travail sert aussi de mécanisme d’accès — « Permissionless »
Un aspect remarquable est que la preuve de travail joue aussi le rôle de mécanisme d’entrée, ce qui n’est pas toujours bien compris.
Quand on parle souvent de blockchains privées vs publiques, on fait en réalité référence au mécanisme d'accès : qui peut participer ? N'importe qui peut-il exécuter un nœud ? Pourtant, le mécanisme d'accès et le consensus ne sont pas directement liés. Mais Nakamoto a conçu un protocole utilisant justement la preuve de travail, qui double naturellement comme mécanisme d'accès : pas besoin de comité spécial ni d'approbation préalable. Toute personne disposant de puissance de calcul peut miner, et personne ne peut contrôler le réseau simplement en multipliant les nœuds, car les nœuds ne représentent pas la puissance de calcul. Cette conception est particulièrement ingénieuse.
Avantage 2 : Dégénérescence élégante de la sécurité
Le système Bitcoin présente une dégradation élégante de la sécurité. Dans ce protocole, la sécurité est probabiliste : même si un acteur malveillant contrôle une partie significative de la puissance de calcul, la sécurité du protocole diminue progressivement, sans effondrement brutal. Bien que l’attaque à 51 % soit connue, la transition de 1‰ à 51 % représente une courbe continue et fluide.
Avantage 3 : Informations membres floues
Bitcoin n’a pas besoin d’informations précises sur ses membres. Miner, c’est entrer. Inutile de connaître à l’avance combien de participants il y a, ni de s’enregistrer pour rejoindre ou quitter le réseau.
Inconvénients : gaspillage de ressources, faible capacité, temps de confirmation long, efficacité de sécurité médiocre.
Voilà pour les avantages. Les inconvénients sont également évidents :
1. La preuve de travail gaspille des ressources : Selon des données datant de 2018, la consommation électrique totale du réseau équivaut à celle d’un pays comme l’Autriche, voire deux Irlandes réunies ;
2. Faible capacité de charge : environ 3 transactions par seconde ;
3. Temps de confirmation très long : Avec la règle des 6 blocs confirmés, cela prend environ une heure, ce qui est excessif pour de petites transactions.
De plus, comparé à la deuxième génération, le système Bitcoin a une efficacité de sécurité très médiocre. Pourquoi ?
Deuxième génération blockchain : PBFT — la renaissance du pharaon
Pourquoi « la renaissance du pharaon » ? Ce sujet a été étudié depuis longtemps, mais n’était pas encore entré dans le grand public. Dans les grandes entreprises traditionnelles, ceux ayant manipulé des systèmes redondants comme Paxos ou Raft ont déjà entendu parler du BFT. En réalité, dès l’an 2000, cette technologie était déjà utilisée commercialement dans des scénarios de redondance en cas de panne ou de crash de machine.
Si f machines tombent en panne, le système reste fonctionnel avec 2f+1 machines opérationnelles — Google utilise typiquement 5 machines. Ces systèmes sont efficaces et hautement disponibles, donnant l’illusion que les services cloud sont accessibles 24 heures sur 24, 7 jours sur 7.
Au début des années 2000, de nombreux sites devaient s’arrêter chaque mois ou chaque semaine pour maintenance. Aujourd’hui, les interruptions sont inutiles, grâce aux systèmes tolérants aux pannes qui masquent les erreurs. L’ensemble du système agit comme un centre de données géant : avec tellement de machines, certaines tombent en panne chaque seconde, mais sont continuellement remplacées. D’un certain point de vue, c’est un bon système — presque comme une blockchain, mais centralisée, car entièrement contrôlée par une seule entité.
Avantage 1 : Réseau très rapide
À l’époque, des idées plus radicales émergeaient : si plusieurs entreprises exploitaient ensemble le système, aucune ne pouvant contrôler directement les machines, comment assurer la stabilité du système dans un cadre plus faible — où les erreurs ne seraient pas dues à une panne d’électricité ou un disque dur endommagé, mais à une entreprise malveillante modifiant délibérément les données ?
De nombreuses recherches ont été menées, notamment le papier de 1999 sur le PBFT (Practical Byzantine Fault Tolerance), un protocole correct et le premier considéré comme vraiment pratique. Il corrige les défauts de la première génération : quand le réseau est petit, il est extrêmement rapide, rivalisant même avec des services centralisés. Le TPS peut atteindre des centaines, voire des milliers, avec une latence en millisecondes.
Avantage 2 : Sécurité déterministe
Dans de bonnes conditions réseau, la sécurité des protocoles PBFT est déterministe : tant que moins d’un tiers des nœuds sont malveillants, le réseau reste sécurisé. Pas besoin d’attendre 6 blocs — une fois validé, c’est définitif, contrairement au caractère probabiliste des protocoles de première génération.
Le problème du protocole de deuxième génération est qu’une fois le seuil franchi (plus d’un tiers de mauvais acteurs), la sécurité s’effondre immédiatement, rendant le système vulnérable et inutilisable.
Avantage 3 : Histoire scientifique ancienne
Un autre atout est sa longue histoire académique. En y réfléchissant, les choix de Nakamoto n’étaient pas motivés par la recherche académique, mais par la volonté de créer un système monétaire anarchiste. Le système Bitcoin en découle. Ce n’est qu’après coup que nous avons analysé qu’il utilisait la puissance de calcul comme unité mesurant la capacité des mauvais acteurs dans le réseau.
Problème 1 : Difficulté à monter en échelle
Dans de nombreux protocoles, on utilise des identités, ce qui peut conduire à une personne possédant plusieurs identités. Comment éviter cela ?
C’est là qu’intervient le mécanisme d’accès, d’où le nom souvent donné de Proof of Stake (preuve d’enjeu), basé sur des garanties. Le staking n’est pas le cœur du fonctionnement du protocole, mais une condition nécessaire à son bon fonctionnement. Les problèmes de ces protocoles sont d’une part la difficulté à monter en échelle, d’autre part l’inefficacité d’un vote collectif généralisé : explorer une proposition commune coûte cher en temps et en bande passante, surtout sans proposition unifiée.
Si un leader propose d’abord une transaction, et que les autres votent pour ou contre, ou peuvent destituer le leader, le processus est bien plus rapide.
Un BFT avec leader ressemble au système présidentiel américain, tandis qu’un BFT sans leader rappelle le Congrès. Les deux souffrent d’inefficacité. Dans un réseau PBFT, tous les nœuds interrogent le leader, qui subit alors une attaque DDoS. Avec 1000 nœuds, cela revient à 1000 attaques simultanées. D’où le problème d’extensibilité : comment augmenter le nombre de nœuds sans voir les performances chuter de façon inversement proportionnelle ?
Les schémas BFT avec vote aléatoire et généralisé sont encore plus inefficaces que les versions avec leader.
Problème 2 : Exige des informations précises sur les participants
Le système PBFT doit connaître exactement qui participe — pas besoin d’identité réelle, mais d’un identifiant. Si cinq personnes participent (A, B, C, D, E), elles constituent la liste des membres. La tolérance aux pannes repose sur cette liste, qui doit être identique pour tous. Chaque participant doit avoir la même liste. Un problème d’implémentation apparaît alors : dans un réseau très décentralisé, il faut un mécanisme décisionnel pour établir cette liste — chose possible, mais complexe.
Problème 3 : Hypothèse stricte sur les mauvais acteurs
Le nombre de mauvais acteurs ne doit pas dépasser un tiers des nœuds de consensus. Même un seul de plus, et tout le système devient instable. Le papier théorique tient en quelques pages, mais l’implémentation est extrêmement difficile.
Ces protocoles sont très complexes. Le papier ne décrit que le cœur en quelques pages, mais de manière floue. En pratique, leur mise en œuvre est très ardue.
Problème 4 : Protocole central trop complexe
En 2013, quelqu’un se plaignait de ne pas comprendre ce protocole : on voit un client envoyer une requête, un serveur diffuser « hello » à tous les autres, puis chaque serveur envoie un vote, puis « maybe do some start », puis des symboles incompréhensibles, puis « definitely ». Peu d’académiques comprennent vraiment ces algorithmes.
Nous en tirons une conclusion : les diffusions un-à-plusieurs ou plusieurs-à-plusieurs sont très inefficaces.
III. Troisième génération blockchain : le protocole Snow / Avalanche (« Neige »)
Face à la troisième génération de blockchains, se pose la question : existe-t-il un mécanisme de consensus complètement différent ?
Le sharding résout-il le problème ?
Avant d’aller plus loin, clarifions une erreur courante :
Beaucoup pensent que le sharding est miraculeux, une sorte de sauveur : avec son développement, « le problème de montée en charge serait résolu ».
Le sharding est en réalité un concept classique dans les systèmes distribués ou les bases de données. Discutez-en avec quelqu’un hors du domaine blockchain, vous « découvrirez » peut-être avec surprise que vous avez été manipulé par le marketing.
Le concept de sharding n’est pas erroné en soi, mais il est surestimé — car il ne résout pas directement le problème de montée en charge au niveau du consensus, c’est un remède superficiel.
Pourquoi ? Si vous disposez déjà d’un protocole de base performant, appliquer le sharding comme optimisation est logique. Mais si le problème fondamental persiste, ajouter artificiellement du sharding est inverser les priorités. Une fois le problème résolu, on peut envisager d’autres optimisations comme le sharding.
Pourquoi dit-on que c’est superficiel ? Car cela se fait au détriment de la tolérance aux pannes. Faisons une expérience de pensée : si chaque nœud forme son propre shard, chacun fonctionne comme un système isolé, supprimant toute redondance. Plus il y a de shards, moins il y a de nœuds synchronisés sur le même état, moins il y a de consensus — c’est une loi : sharding et consensus sont les deux plateaux d’une balance.
Ainsi, le sharding fonctionne lorsque la cohérence entre shards n’est pas cruciale, par exemple : un système de paiement à Shanghai et un autre à Pékin. Généralement, les transferts se font entre banques locales à Shanghai ou à Pékin, avec rarement des transactions inter-régionales — dans ce cas, la synchronisation lente reste nécessaire.
Cet exemple montre que le sharding est lié aux cas d’usage concrets, pas une solution universelle.
Si le protocole est mauvais, c’est comme une soupe immangeable. Le sharding revient à y ajouter du chili — ça améliore le goût, mais une soupe immangeable reste immangeable, même avec du chili.
Mais si la soupe de base est bonne, comme un bouillon de fondue, on peut y ajouter du piquant — et elle devient encore meilleure.
Troisième génération : le protocole Avalanche
La troisième génération ne signifie pas qu’elle écrase les deux précédentes, mais qu’elle a ses spécificités. Ce protocole peut offrir de hautes performances et capacités métier dans certains cas d’usage.
Un article sur Avalanche a été publié sur IPFS en mai 2018. Fruit d’une collaboration entre chercheurs, il s’inspire des modèles épidémiques (epidemic models) et des réseaux de rumeurs (gossip networks).
Cette troisième génération combine les atouts des deux premières :
1) Dégénérescence élégante de la sécurité — pas de rupture brutale de sécurité dès qu’un seuil de mauvais acteurs est atteint.
2) Informations membres souples — les nœuds peuvent avoir des listes légèrement différentes sans impact global.
3) Suffisamment rapide — les performances ne baissent pas linéairement, encore moins de façon super-linéaire, avec la taille du réseau. Une baisse logarithmique serait idéale.
4) Respectueux de l’environnement
5) Intuitif — contrairement au vote PBFT, trop complexe, ou au consensus Nakamoto, trop lent mais intuitif.
Un autre concept mal compris — le débit (TPS)
D’autres protocoles affirment aussi être rapides, avec un fort débit (TPS : transactions par seconde). Mais comme on n’achète pas un téléphone juste sur la base des benchmarks, le débit est un concept mal compris.
Dans les articles informatiques, surtout sur les systèmes distribués, on ne mesure jamais la performance uniquement par le débit — ce serait malhonnête. Car le « débit » reflète seulement la capacité tampon du système, tandis que la « latence » mesure la vitesse réelle de réponse aux utilisateurs.
En tant qu'utilisateur, vous ne vous souciez pas du débit — combien de personnes le système peut-il servir par seconde. Ce qui compte, c'est le moment où votre transaction est confirmée : une seconde ou une heure ? C’est ce qu’on appelle la « latence ».
Évaluer un système ne peut se limiter à la latence ; débit et latence sont tous deux indispensables. Un système peut avoir une faible latence, comme une banque vide avec un ou dix clients, mais cela vient d’une faible charge. Si la file d’attente grossit, la banque ne peut plus faire face. Donc, à latence égale, examinez le débit.
Ignorer la latence et ne regarder que le débit conduit à une autre impasse scientifique.
Le débit comparable à Internet est celui des sociétés logistiques. Par exemple, expédier un camion de cartes mémoire de Pékin à Shanghai peut prendre trois jours, mais le débit par seconde est impressionnant. Pourtant, on ne peut pas l'utiliser comme réseau ni prendre des décisions dessus. Ignorer la latence et parler seulement de débit, c’est tricher.
Il faut donc examiner à la fois débit et latence.
L’image ci-dessus montre la performance du débit d’Avalanche quand le nombre de nœuds double. Même avec un doublement des nœuds, l’impact sur le débit reste modéré, grâce à d'autres techniques comme le DAG pour exécuter des transactions en parallèle.
L’image ci-dessus montre la latence de base du protocole, simulée avec 2000 nœuds, sans tenir compte des retards réseau additionnels. Même avec 2000 nœuds votant simultanément, la latence reste inférieure à une seconde — la distribution est visible à gauche.
Dans un scénario réel, avec des nœuds répartis dans 20 villes mondiales, signatures numériques complètes, et modèle UTXO standard de Bitcoin, les résultats restent excellents : plusieurs milliers de transactions par seconde avec un temps de confirmation d’environ une seconde.
Comment y parvenir ? — Le réseau de rumeurs comme consensus lui-même
Le temps étant limité, je ne peux pas tout détailler. Je vais vous expliquer brièvement l’intuition derrière cette approche, et pourquoi elle fonctionne.
Imaginons N personnes discutant d’un potin sur une star. Considérons « vrai » ou « faux » comme une décision, analogue à une transaction inscrite ou non sur la chaîne. Chaque personne choisit aléatoirement k autres (par exemple k = 10), même si le réseau compte des millions de personnes, et demande leur avis : le potin est-il confirmé ou faux ?
Zhang San ajuste sa conviction selon les k personnes interrogées. Son opinion influencera à son tour ceux qui l’interrogeront. Grâce à ces sondages aléatoires, la crédibilité de l’information monte progressivement dans tout le réseau.
L’avantage du protocole de troisième génération par rapport au deuxième est qu’il n’est pas nécessaire d’interroger tout le monde, mais seulement un échantillon aléatoire, dont la taille dépend de la sécurité, pas de l’échelle du réseau. Avec un million de nœuds, k peut rester à 10 ou 20.
Exemple :
Bienvenue dans la communauté officielle TechFlow Groupe Telegram :https://t.me/TechFlowDaily Compte Twitter officiel :https://x.com/TechFlowPost Compte Twitter anglais :https://x.com/BlockFlow_News
![Axe Compute [NASDAQ : AGPU] finalise sa restructuration d'entreprise (anciennement POAI), la puissance GPU décentralisée d'entreprise Aethir fait officiellement son entrée sur le marché principal](https://upload.techflowpost.com/upload/images/20251212/2025121221124297058230.png?x-oss-process=image/resize,p_50/quality,q_80)
