Oubliez ce que vous pensez savoir sur la blockchain. Pod Network vient de publier une innovation révolutionnaire qui casse les codes établis.
Ce Layer 1 repense le mécanisme de consensus d’un réseau décentralisé pour valider les transactions à la vitesse de la lumière.
Mais pour bien comprendre la promesse, reprenons d’abord les bases.
Sommaire
- L’organisation des transactions dans une blockchain
- Un système différent de validation
- Mais alors pourquoi a-t-on besoin de consensus ?
- L’innovation Consensus-less
- Pod-core, le coeur du réacteur
- Une chaine modulaire pour des possibilités infinies
- Interopérabilité avec les réseaux blockchains
- Une team sérieuse à l’origine de cette idée
- Liens utiles
L’organisation des transactions dans une blockchain
La blockchain est une technologie conçue pour ordonner et valider des transactions par un mécanisme de consensus, afin d’en assurer l’intégrité. Toute la confiance repose sur cet aspect.
Elle empêche qu’on puisse dépenser deux fois la même pièce numérique (protection contre la double dépense). Si quelqu’un voulait donner la même pièce à la fois à monsieur A et à monsieur B, il lui faudrait tromper suffisamment de validateurs pour leur faire croire qu’il existe une pièce différente pour chacun. Dans un grand réseau décentralisé, où tout le monde vérifie les transactions, c’est quasiment impossible.
Comme nous le disions, les transactions sont envoyées à tous les validateurs, qui vont chacun proposer un ordre. Un validateur — choisi au hasard (pour le PoS) ou en fonction de sa puissance de calcul (pour le PoW) — imposera ensuite sa vision. La liste est alors diffusée à l’ensemble du réseau, qui acte cet ordre dans la chaîne, avant de recommencer à zéro pour le bloc suivant.
Ça fonctionne, mais c’est lent : les validateurs doivent d’abord s’accorder, puis attendre le bloc suivant pour traiter de nouvelles transactions.
Un système différent de validation
Imaginons un système où l’utilisateur envoie, comme d’habitude, sa transaction à chaque validateur. Sans avoir besoin de communiquer entre eux, les validateurs approuvent ou rejettent immédiatement la transaction en répondant directement à l’utilisateur.
Comment ce réseau se comporterait-il face à notre problème de double dépense si, pour ne rien arranger, un tiers des validateurs étaient peu scrupuleux ?
On obtient donc :
- 2/3 qui valident la transaction b et annulent la transaction a
- 2/3 qui valident la transaction a et annulent la transaction b
- 1/3 malveillant qui valident la double dépense
Pour qu’une transaction soit acceptée par l’ensemble du réseau, elle doit récolter 60 % de confirmations. Il devient donc impossible de valider la double dépense. La tentative frauduleuse pourrait rester en attente indéfiniment, sans jamais atteindre les 60 % de “oui”.
Dans cet exemple, nous avons pu réaliser une transaction de manière décentralisée, sans qu’aucun validateur n’ait besoin de communiquer avec un autre.
Mais alors pourquoi a-t-on besoin de consensus ?
En réalité, nous n’en avons pas besoin dans bien des cas : la plupart des transactions peuvent être exécutées indépendamment les unes des autres.
Les blockchains classiques fonctionnent selon le principe de State-Machine Replication : elles prennent les transactions, les appliquent une à une dans un ordre précis, et mettent à jour l’état global du système à chaque étape. Cela signifie que chaque lot de transactions doit être complètement traité avant de passer au suivant, ce qui bloque tout le reste et ralentit inutilement l’ensemble du système.
Pour être plus efficace, Pod Network adopte une architecture continue qui ne verrouille que ce qui est nécessaire. En d’autres termes, si vous envoyez un ETH à votre voisin et que la boulangère effectue un dépôt sur un CEX, les deux transactions ne se contredisent pas. Elles peuvent donc être confirmées en parallèle, et leur ordre importe peu.
L’innovation Consensus-less
Nous l’avons vu, dans la blockchain, un validateur organise les transactions avant de les figer dans un bloc et de les transmettre aux autres validateurs. La vitesse d’exécution est donc limitée par le délai entre deux blocs. Ce bloc time impose une lenteur préjudiciable pour l’utilisateur.
Pod Network n’a pas de bloc, ce qui lui offre une vitesse et une flexibilité inégalées. Grâce à cette architecture, Pod Network atteint une latence de confirmation des transactions équivalente à un aller-retour réseau (~200 ms), comparable à la rapidité d’une recherche sur Google.
Comme sur une blockchain, les validateurs reçoivent les transactions, mais ils les traitent chacun de leur côté et les intègrent à leur registre personnel. Si la transaction est conforme, ils la signent avec leur clé et un horodatage avant de la renvoyer au client. À aucun moment, les validateurs n’ont besoin de communiquer ou de se mettre d’accord, ce qui permet d’aller beaucoup plus vite.
Le client a seulement besoin d’un minimum de confirmations pour que sa transaction soit validée.
L’ensemble des registres reste consultable par tout le monde, comme dans tout système de registre distribué.
Pod-core, le coeur du réacteur
Toute l’ingéniosité de Pod Network tient en une centaine de lignes de code en Rust. Basé sur des jeux de hash, le code est facilement auditable, un point essentiel pour garantir la sécurité du réseau.
Cette simplicité le rend modulaire : les builders peuvent facilement construire sur le réseau, sans être limités par celui-ci, en créant les briques technologiques adaptées à leurs propres besoins.
Validité des transactions
La vitesse de Pod Network repose sur l’absence de consensus entre les validateurs. Une même transaction pourra donc recevoir plusieurs validations à des moments différents.
Pour être considérée comme valide, une transaction doit se situer dans un intervalle de temps acceptable, défini par les paramètres de sécurité du protocole.
Sécurité
Pour répondre au problème des généraux byzantins malgré l’absence de consensus, la sécurité du Pod-core se base sur deux paramètres : α et β.
α (Taille du Quorum)
Nombre minimum de validations nécessaires pour qu’une transaction soit acceptée.
Ce paramètre détermine la vivacité (n – α, où n est le nombre de validateurs), c’est-à-dire la capacité du système à continuer de finaliser des transactions, même en présence de défaillances ou d’actions malveillantes de certains nœuds du réseau.
Ex : Il faut obtenir 66 % de signatures de validateurs pour qu’une transaction soit valide.
β (Résilience de sécurité)
Nombre maximum de validateurs malveillants que le système peut tolérer sans compromettre la sécurité des transactions.
Ex : À partir de 33 % de validateurs malveillants sur le réseau, les confirmations ne sont plus fiables.
Calcul de l’intervalle acceptable
Lorsque qu’une transaction est envoyée, l’intervalle acceptable d’horodatage est calculé en fonction de ces deux paramètres (α et β), en excluant les validateurs qui se trouvent hors des limites définies.
Une approche optimiste
Ce système repose sur une approche optimiste. On suppose qu’il y aura une majorité d’acteurs bienveillants et que les acteurs malveillants seront repérés par leur écart de temps. Ce seuil de détection est variable en fonction de α et β.
On pourrait être tenté de fixer les paramètres au maximum, mais cela rendrait le réseau inopérant, car il est impossible d’obtenir 100 % de confirmation. Un validateur indisponible ou en panne empêcherait les transactions d’avoir lieu.
Un β trop faible permettrait à peu d’acteurs malveillants de prendre le contrôle du réseau, tandis qu’avec un β trop élevé, il n’y aurait plus assez d’acteurs considérés comme bienveillants pour atteindre le seuil α.
Il va donc falloir composer avec α et β pour trouver le bon équilibre entre efficacité et sécurité.
Récompenses et token
Jusqu’à présent, leur documentation ne mentionne nulle part de mécanisme de récompense pour les validateurs participant au réseau. Pour des raisons évidentes, il est très peu probable que le réseau fonctionne sur la base du bénévolat. Nous pouvons nous attendre à ce que le projet communique davantage sur ce sujet lors de la mise en place du devnet d’ici quelques semaines.
Dans ce réseau, où aucun validateur n’est désigné comme vainqueur récoltant les frais de bloc, il sera intéressant de voir comment Pod Network adaptera son mécanisme pour maintenir les validateurs motivés. Aucun token n’a été annoncé à ce stade du projet, qui reste encore très théorique.
Une chaine modulaire pour des possibilités infinies
Derrière son apparente simplicité, Pod Network révèle une grande capacité d’adaptation. Le protocole a été conçu comme une base extensible, à laquelle viennent se greffer des briques modulaires selon les besoins des projets, sans jamais compromettre la sécurité du cœur de réseau.
Plutôt que de surcharger les validateurs avec des lectures incessantes, comme consulter un solde ou interroger un smart contract, Pod délègue cette tâche à des nœuds spécialisés appelés secondaires. Ces derniers mettent en cache les données validées et les restituent rapidement, allégeant ainsi considérablement la charge du réseau.
Pour simplifier l’envoi de transactions, Pod déploie des gateways. Ces passerelles, qui maintiennent une connexion ouverte avec tous les validateurs, agissent comme des agrégateurs pour faciliter la communication entre les utilisateurs et les validateurs. D’une certaine manière, les gateways sont les équivalents des RPC sur EVM. L’utilisateur peut en changer s’il estime que la gateway (passerelle) ne fait pas correctement son travail.
Dernier exemple, pour favoriser la décentralisation, Pod introduit des validateurs allégés, qui conservent uniquement une trace minimale de l’historique grâce à des structures de type Merkle Mountain Range, réduisant considérablement les exigences de stockage. Enfin, les clients légers bénéficient d’un accès autonome et vérifiable aux informations du réseau, sans dépendre d’un tiers. Grâce à une combinaison astucieuse de filtres et d’arbres cryptographiques, ils peuvent s’assurer qu’aucune donnée ne leur a été cachée.
Pod ne cherche pas à tout réinventer, mais à proposer un socle simple et modulable, prêt à accueillir toutes les innovations.
Interopérabilité avec les réseaux blockchains
On l’a vu, Pod Network adopte une approche modulaire à l’instar de Celestia, permettant d’ajouter facilement les briques technologiques nécessaires en fonction des besoins. Pour assurer l’interopérabilité avec d’autres réseaux, des extensions ont été développées. C’est notamment le cas de EVMx, une extension dédiée à l’écosystème Ethereum. Une autre extension permet de garantir un ordre strict d’exécution des transactions, indispensable pour certains cas d’usage comme la DeFi.
Le choix du langage Rust, à la fois moderne et très populaire, facilite également le développement de nouvelles extensions par la communauté ou par des équipes externes.
Une team sérieuse à l’origine de cette idée
Le projet est porté par une équipe spécialisée en blockchain appartenant à Common ⎵ Prefix, qui a publié des articles sur les nouvelles méthodes de validation en cryptographie, telles que le consensusless. Ces recherches les ont poussés à fonder, début 2025, Pod Network pour apporter un vent d’innovation sur un aspect de la blockchain rarement remis en cause.
Cette rupture technologique a en tout cas su convaincre de célèbres fonds d’investissement, comme a16z, de les suivre dans cette aventure à hauteur de 10M$.
Il faudra donc suivre de près ce projet qui tente une nouvelle approche consensusless de la blockchain pour résoudre le problème de scalabilité que rencontrent toutes les L1. Accompagné d’un soutien financier solide, Pod Network se positionne comme une alternative crédible et performante aux blockchains classiques, promettant un avenir plus fluide et accessible pour les transactions décentralisées.
Le projet est encore en phase de développement, le lancement du testnet prévu pour le troisième trimestre 2025, le mainnet lui est prévu pour le début d’année 2026, au minimum.