← Derniers articles
💻 computer science

Perils of Parallelism: Transaction Fee Mechanisms under Execution Uncertainty

Cet article analyse comment le parallélisme d'exécution et la contingence dans les blockchains modernes créent des compromis inhérents entre les incitations des utilisateurs et celles des ordonnanceurs, prouvant un résultat d'impossibilité pour les mécanismes de frais existants et proposant un nouveau cadre qui atteint des limites optimales de l'équité et de la performance dans des systèmes tels que Sui et Monad.

Auteurs originaux : Sarisht Wadhwa, Aviv Yaish, Fan Zhang, Kartik Nayak

Publié 2026-06-15
📖 6 min de lecture🧠 Analyse approfondie

Auteurs originaux : Sarisht Wadhwa, Aviv Yaish, Fan Zhang, Kartik Nayak

Article original sous licence CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). Ceci est une explication générée par l'IA de l'article ci-dessous. Elle n'a pas été rédigée ni approuvée par les auteurs. Pour une précision technique, consultez l'article original. Lire la clause de non-responsabilité complète

Imaginez une autoroute très fréquentée où, au lieu que les voitures circulent une par une dans une seule voie, le trafic est désormais autorisé à circuler simultanément sur plusieurs voies. C'est l'exécution parallèle dans les blockchains modernes : un moyen de traiter de nombreuses transactions à la fois pour rendre le système plus rapide.

Cependant, cet article soutient que, bien que les autoroutes parallèles soient plus rapides, les systèmes actuels de « péages » (mécanismes de frais) sont défaillants. Ils ne savent pas comment facturer équitablement lorsque les conducteurs peuvent emprunter des itinéraires différents, ou lorsque de faux conducteurs tentent de manipuler le système.

Voici la décomposition des conclusions de l'article en utilisant des analogies simples.

1. Les deux grands problèmes

Les auteurs identient deux « périls » (dangers) qui surviennent lorsque vous essayez de facturer des frais pour le traitement parallèle.

Péril A : Le conducteur du « peut-être » (Transactions contingentes)

Imaginez que vous commandez une pizza personnalisée. Vous dites à la cuisine : « Je veux une pizza avec du pepperoni, des champignons et des olives. »

  • La réalité : Vous ne mangez réellement que le pepperoni. La cuisine a préparé les champignons et les olives, mais vous n'y avez pas touché.
  • Le problème : Dans une blockchain parallèle, une transaction (la commande de pizza) dit souvent : « Je pourrais avoir besoin de ces 5 ingrédients. » Mais selon l'état actuel du monde (le prix du pepperoni), elle pourrait finir par n'utiliser qu'un seul ingrédient.
    • Si vous facturez ce qui est utilisé : La cuisine (l'ordonnanceur) perd de l'argent parce qu'elle a préparé des ingrédients qui ont été gaspillés.
    • Si vous facturez ce qui a été annoncé comme utilisé : Vous (l'utilisateur) payez trop cher pour des ingrédients que vous n'avez jamais touchés.

La grande découverte de l'article : On ne peut pas avoir le beurre et l'argent du beurre. Vous ne pouvez pas concevoir un système où l'utilisateur ne paie jamais trop cher ET où la cuisine ne perd jamais d'argent sur le travail de préparation inutilisé. C'est une impossibilité mathématique. Vous devez choisir qui supporte le risque : l'utilisateur ou le système.

Péril B : Les « faux » conducteurs (Attaques de type Shill)

Imaginez maintenant un péage qui facture en fonction du trafic sur la route.

  • L'astuce de l'utilisateur : Un conducteur veut payer un péage bas. Il envoie un tas de voitures fausses et inutiles (transactions de shill) sur la route. Ces voitures fausses prennent de la place mais ne vont nulle part. Le péage voit un « trafic intense » et répartit le coût, de sorte que le vrai conducteur paie moins.
  • L'astuce du péage : La personne qui gère le péage veut gagner plus d'argent. Elle envoie ses propres voitures fausses sur la route pour faire croire que les vrais conducteurs provoquent un embouteillage massif. Le péage facture ensuite les vrais conducteurs un supplément pour la « congestion ».

La découverte de l'article : Les systèmes actuels sont vulnérables à ces ruses. Si le système facture en fonction de la quantité de « travail parallèle » qui a lieu, les acteurs malveillants peuvent manipuler les calculs en ajoutant des transactions fausses pour abaisser ou augmenter les frais.

2. Les trois façons de partager l'addition

Puisqu'on ne peut pas éliminer le risque d'ingrédients inutilisés (Péril A), l'article suggère trois façons de répartir la facture entre l'Utilisateur et le Système :

  1. L'approche « Orientée Utilisateur » : Vous ne payez que pour le pepperoni que vous avez réellement mangé.
    • Résultat : L'utilisateur est content (pas de surpaiement), mais la cuisine (le système) perd de l'argent sur les champignons et les olives gaspillés.
  2. L'approche « Orientée Ordonnanceur » : Vous payez pour toute la pizza que vous avez commandée, même si vous n'avez mangé que le pepperoni.
    • Résultat : La cuisine est contente (revenu garanti), mais l'utilisateur peut payer trop cher.
  3. L'approche « Égalité des chances » : On partage le coût des ingrédients gaspillés à 50/50.
    • Résultat : Un compromis où les deux parties partagent le risque des ingrédients « peut-être ».

3. La solution : Le péage « Pondéré par Objet »

Pour résoudre le problème du « Faux Conducteur » (Péril B) tout en gérant le problème du « Peut-être » (Péril A), les auteurs proposent un nouveau système appelé OW-TFM (Mécanisme de Frais de Transaction Pondéré par Objet).

L'analogie :
Au lieu de facturer en fonction du nombre de voitures sur la route en ce moment même (ce qui peut être falsifié), imaginez un système de péage qui facture en fonction de la popularité d'une voie spécifique hier.

  • Si un objet spécifique (comme une garniture de pizza populaire) a été beaucoup utilisé lors du dernier bloc, son prix augmente légèrement pour le bloc suivant.
  • S'il n'a pas été utilisé, le prix reste bas.

Pourquoi cela stoppe les ruses :

  • Pour les utilisateurs : Si vous essayez d'ajouter des transactions fausses pour baisser vos frais, vous ne pouvez pas. Ajouter une transaction fausse ne fait qu'augmenter le compte d'utilisation d'un objet, ce qui peut augmenter le prix pour tout le monde, y compris pour vous. Vous ne pouvez pas baisser le prix en ajoutant plus de voitures.
  • Pour le système : Le système fixe les prix en se basant sur des données passées, il n'a donc pas besoin de deviner ce qui se passera dans le futur.

4. L'essentiel

L'article conclut que construire une blockchain parallèle qui soit à la fois juste, rapide et sécurisée est difficile en raison d'un arbitrage fondamental :

  • Vitesse vs Équité : Vous ne pouvez pas prédire parfaitement quels « ingrédients » une transaction utilisera sans l'exécuter d'abord (ce qui prend du temps et contredit l'intérêt du parallélisme).
  • Sécurité vs Efficacité : Vous ne pouvez pas avoir un système qui soit parfaitement efficace (facturant exactement ce qui est utilisé) et parfaitement sécurisé (immunisé contre les transactions fausses) en même temps.

Les auteurs suggèrent que les concepteurs de blockchains (comme ceux qui construisent Sui, Solana ou Monad) doivent explicitement décider qui supporte le risque des ressources inutilisées (Utilisateur ou Système) et utiliser un modèle de tarification basé sur l'utilisation historique des objets pour empêcher les gens de manipuler le système avec des transactions frauduleuses.

En bref : Les blockchains parallèles sont comme une cuisine très occupée. Vous ne pouvez pas facturer parfaitement un repas avant de savoir ce que le client va réellement manger, et vous ne pouvez pas empêcher les gens de prétendre commander de la nourriture pour manipuler la facture. La solution consiste à se mettre d'accord sur qui paie pour la nourriture gaspillée et à baser les prix sur ce que les gens commandent habituellement, et non sur ce qu'ils disent commander en ce moment.

Noyé(e) sous les articles dans votre domaine ?

Recevez des digests quotidiens des articles les plus récents correspondant à vos mots-clés de recherche — avec des résumés techniques, dans votre langue.

Essayer Digest →