Depuis des décennies, la recherche sur les systèmes distribués, notamment Consensus byzantin et réplication de machine à états (SMR)s’est concentré sur deux objectifs principaux : la cohérence et la vivacité. La cohérence signifie que tous les nœuds s’accordent sur la même séquence de transactions, tandis que la vivacité garantit que le système continue d’en ajouter de nouvelles. Néanmoins, ces propriétés n’empêchent pas les mauvais acteurs de modifier l’ordre des transactions après leur réception.
Dans les blockchains publiques, cette lacune dans les garanties consensuelles traditionnelles est devenue un problème sérieux. Validateurs, constructeurs de blocs ou séquenceurs peuvent exploiter leur rôle privilégié dans la commande de blocs pour obtenir un gain financier, une pratique connue sous le nom de valeur extractible maximale (MEV). Cette manipulation comprend le frontrunning, le backrunning et le sandwiching rentables des transactions. Étant donné que l’ordre d’exécution des transactions détermine la validité ou la rentabilité des applications DeFi, l’intégrité de l’ordre des transactions est vitale pour maintenir l’équité et la confiance.
Pour combler cette lacune critique en matière de sécurité, l’équité des ordres de transaction a été proposée comme troisième propriété essentielle du consensus. Protocoles de commande équitables garantir que l’ordre final des transactions dépend de facteurs externes objectifs, tels que les heures d’arrivée (ou l’ordre de réception) et qu’il résiste à une réorganisation contradictoire. En limitant le pouvoir dont dispose un proposant de bloc pour réorganiser les transactions, ces protocoles rapprochent les blockchains de la transparence, de la prévisibilité et de la résistance au MEV.
Le paradoxe de Condorcet et l’impossibilité d’une équité idéale
La notion d’équité la plus intuitive et la plus forte est Réception-Ordre-Équité (ROF). Défini de manière informelle comme « premier reçu, premier résultat », le ROF stipule que si un nombre suffisant de transactions (tx) arriver à une majorité de nœuds plus tôt qu’une autre transaction (tx’)alors le système doit commander impôt avant tx’ pour l’exécution.
Cependant, parvenir à cette « équité des ordres » universellement acceptée est fondamentalement impossible à moins de supposer que tous les nœuds peuvent communiquer instantanément (c’est-à-dire fonctionner dans un réseau externe synchrone instantané). Ce résultat d’impossibilité découle d’un lien surprenant avec la théorie du choix social, en particulier le paradoxe de Condorcet.
Le paradoxe de Condorcet illustre comment, même lorsque chaque nœud individuel maintient un ordre interne transitif des transactions, la préférence collective à travers le système peut aboutir à ce que l’on appelle des cycles non transitifs. Par exemple, il est possible qu’une majorité de nœuds reçoivent des transactions UN avant Bune majorité reçoit B avant Cet une majorité reçoit C avant UN. Ainsi, les trois préférences majoritaires forment une boucle (UN→B→C→UN). Cela signifie qu’aucun ordre unique et cohérent des transactions A, B et C ne pourra jamais satisfaire simultanément toutes les préférences de la majorité.
Ce paradoxe démontre pourquoi l’objectif d’atteindre parfaitement l’équité de la réception des commandes est impossible dans réseaux asynchronesou même dans réseaux synchrones qui partagent une horloge commune si les délais du réseau externe sont trop longs. Cette impossibilité nécessite l’adoption de définitions d’équité plus faibles, telles que l’équité des commandes par lots.
Hedera Hashgraph et défaut d’horodatage médian
Hedera, qui utilise l’algorithme de consensus Hashgraph, cherche à se rapprocher d’une notion forte d’équité des ordres de réception (ROF). Pour ce faire, il attribue à chaque transaction un horodatage final calculé comme la médiane des horodatages locaux de tous les nœuds pour cette transaction.
Cependant, cela est intrinsèquement sujet à la manipulation. Un seul nœud adverse peut délibérément fausser ses horodatages locaux et inverser l’ordre final de deux transactions, même si tous les participants honnêtes les ont reçues dans le bon ordre.
Prenons un exemple simple avec cinq nœuds de consensus (A, B, C, D et E) où le nœud E agit de manière malveillante. Deux transactions, tx₁ et tx₂, sont diffusées sur le réseau. Tous les nœuds honnêtes reçoivent tx₁ avant tx₂, donc l’ordre final attendu devrait être tx₁ → tx₂.
Dans cet exemple, l’adversaire attribue à tx₁ un horodatage ultérieur (3) et à tx₂ un horodatage antérieur (2) pour fausser la médiane.
Lorsque le protocole calcule les médianes :
-
Pour tx₁, les horodatages (1, 1, 4, 4, 3) donnent une médiane de 3.
-
Pour tx₂, les horodatages (2, 2, 5, 5, 2) donnent une médiane de 2.
Étant donné que l’horodatage final de tx₁ (3) est supérieur à celui de tx₂ (2), le protocole génère tx₂ → tx₁, inversant ainsi le véritable ordre observé par tous les nœuds honnêtes.
Cet exemple de jouet démontre un défaut critique : la fonction médiane, bien qu’apparaissant neutre, est paradoxalement la cause réelle de l’injustice car elle peut être exploitée même par un seul participant malhonnête pour biaiser l’ordre final des transactions.
En conséquence, l’« horodatage équitable » souvent vanté de Hashgraph est une notion d’équité étonnamment faible. Le consensus Hashgraph ne parvient pas à garantir l’équité des ordres de réception et dépend plutôt d’un ensemble de validateurs autorisés plutôt que de garanties cryptographiques.
Obtenir des garanties pratiques
Cependant, pour contourner l’impossibilité théorique démontrée par Condorcet, les systèmes pratiques d’ordonnancement équitable doivent assouplir d’une manière ou d’une autre la définition de l’équité.
Le Protocoles Aequitas introduit le critère de Blocage des commandes équitables (BOF)ou équité des commandes par lots. BOF stipule que si suffisamment de nœuds reçoivent une transaction tx avant une autre transaction tx’, alors tx doit être livré dans un bloc avant ou en même temps que tx’, ce qui signifie qu’aucun nœud honnête ne peut livrer tx’ dans un bloc après tx. Cela assouplit la règle de « doit être livré avant » (exigence du ROF) à « doit être livré au plus tard ».
Considérons trois nœuds de consensus (A, B et C) et trois transactions : tx₁, tx₂ et tx₃. Une transaction est considérée comme « reçue plus tôt » si au moins deux des trois nœuds (une majorité) l’observent en premier.
Si l’on applique le vote majoritaire pour déterminer un ordre global :
-
tx₁ → tx₂ (convenu par A et C)
-
tx₂ → tx₃ (convenu par A et B)
-
tx₃ → tx₁ (convenu par B et C)
Ces préférences créent une boucle : tx₁ → tx₂ → tx₃ → tx₁. Dans cette situation, il n’existe pas d’ordre unique qui puisse satisfaire l’opinion de tout le monde à la fois, ce qui signifie qu’un ROF strict est impossible à atteindre.
BOF résout ce problème en regroupant toutes les transactions en conflit dans le même lot ou bloc au lieu de forcer l’une à passer avant l’autre. Le protocole affiche simplement :
Bloc B₁ = {tx₁, tx₂, tx₃}
Cela signifie que, du point de vue du protocole, les trois transactions sont traitées comme si elles s’étaient produites en même temps. À l’intérieur du bloc, un facteur de départage déterministe (tel qu’une valeur de hachage) décide de l’ordre exact dans lequel ils seront exécutés. En faisant cela, BOF garantit l’équité pour chaque paire de transactions et maintient le journal des transactions final cohérent pour tout le monde. Chacun est traité au plus tard que celui qui le précède.
Cet ajustement petit mais important permet au protocole de gérer les situations où l’ordre des transactions est en conflit, en regroupant ces transactions en conflit dans le même bloc ou lot. Il est important de noter que cela n’entraîne pas un ordre partiel, car chaque nœud doit toujours s’accorder sur une séquence unique et linéaire de transactions. Les transactions à l’intérieur de chaque bloc sont toujours organisées dans un ordre d’exécution fixe. Dans les cas où de tels conflits ne se produisent pas, le protocole obtient toujours la propriété ROF la plus forte.
Bien qu’Aequitas ait réussi à atteindre le BOF, elle était confrontée à des limites importantes, notamment en raison de sa complexité de communication très élevée et de sa capacité à garantir une faible vivacité. Une faible vivacité implique que la livraison d’une transaction n’est garantie qu’une fois terminé l’ensemble du cycle Condorcet dont elle fait partie. Cela pourrait prendre un temps arbitrairement long si les cycles « s’enchaînent ».
Le Protocole Thémis a été introduit pour appliquer la même propriété BOF forte, mais avec une complexité de communication améliorée. Themis y parvient en utilisant trois techniques : le déroulement des lots, les commandes différées et des garanties intra-lot plus fortes.
Dans sa forme standard, Themis demande à chaque participant d’échanger des messages avec la plupart des autres nœuds du réseau. La quantité de communication requise augmente avec le carré du nombre de participants au réseau. Cependant, dans sa version optimisée, SNARK-Themis, les nœuds utilisent des preuves cryptographiques succinctes pour vérifier l’équité sans avoir besoin de communiquer directement avec tous les autres participants. Cela réduit la charge de communication de sorte qu’elle n’augmente que de manière linéaire, ce qui permet à Themis d’évoluer efficacement même dans les grands réseaux.
Supposons que cinq nœuds (A – E) participant au consensus reçoivent trois transactions : tx₁, tx₂ et tx₃. En raison de la latence du réseau, leurs ordres locaux diffèrent :
Comme dans Aequitas, ces préférences créent un cycle de Condorcet. Mais au lieu d’attendre que l’ensemble du cycle soit résolu, Themis maintient le système en mouvement en utilisant une méthode appelée batch unspooling. Il identifie toutes les transactions qui font partie du cycle et les regroupe en un seul ensemble, appelé composant fortement connecté (SCC). Dans ce cas, les trois transactions appartiennent au même SCC, que Themis génère sous la forme d’un lot en cours, étiqueté Batch B₁ = {tx₁, tx₂, tx₃}.
Ce faisant, Themis permet au réseau de continuer à traiter de nouvelles transactions même pendant que la commande interne du lot B₁ est encore en cours de finalisation. Cela garantit que le système reste sous tension et évite le blocage.
Aperçu:
Le concept d’équité parfaite dans l’ordre des transactions peut sembler simple. La transaction de celui qui atteint le réseau en premier doit être traitée en premier. Cependant, comme le démontre le paradoxe de Condorcet, cet idéal ne peut pas tenir dans les systèmes réels et distribués. Différents nœuds voient les transactions dans des ordres différents, et lorsque ces points de vue sont en conflit, aucun protocole ne peut construire une séquence unique, universellement « correcte » sans compromis.
Le Hashgraph de Hedera a tenté de se rapprocher de cet idéal avec des horodatages médians, mais cette approche repose davantage sur la confiance que sur la preuve. Un seul participant malhonnête peut fausser l’ordre médian et inverser l’ordre des transactions, révélant qu’un « horodatage équitable » n’est pas vraiment équitable.
Des protocoles comme Aequitas et Themis font avancer la discussion en reconnaissant ce qui peut et ne peut pas être réalisé. Au lieu de poursuivre l’impossible, ils redéfinissent l’équité de manière à préserver l’intégrité des ordres dans des conditions réelles de réseau. Ce qui émerge n’est pas un rejet de l’équité, mais son évolution. Cette évolution trace une ligne claire entre l’équité perçue et l’équité prouvable. Cela montre que la véritable intégrité des ordres de transactions dans les systèmes décentralisés ne peut pas dépendre de la réputation, de la confiance du validateur ou du contrôle autorisé. Elle doit provenir d’une vérification cryptographique intégrée au protocole lui-même.
Cet article ne contient pas de conseils ou de recommandations en investissement. Chaque mouvement d’investissement et de trading comporte des risques, et les lecteurs doivent effectuer leurs propres recherches avant de prendre une décision.
Cet article est destiné à des fins d’information générale et n’est pas destiné à être et ne doit pas être considéré comme un conseil juridique ou en investissement. Les points de vue, pensées et opinions exprimés ici appartiennent uniquement à l’auteur et ne reflètent pas ou ne représentent pas nécessairement les points de vue et opinions de Cointelegraph.
Cointelegraph n’approuve pas le contenu de cet article ni aucun produit mentionné ici. Les lecteurs doivent faire leurs propres recherches avant d’entreprendre toute action liée à un produit ou à une entreprise mentionnée et assumer l’entière responsabilité de leurs décisions.
