De frais de transaction à MEV : analyse approfondie de la conception monétarisée des Rollup
TechFlow SélectionTechFlow Sélection
De frais de transaction à MEV : analyse approfondie de la conception monétarisée des Rollup
Les frais de transaction constituent un modèle économique simple et efficace, et l'un des principaux arguments de vente du Rollup pour la mise à l'échelle d'Ethereum est précisément ses faibles frais.
Dédié à des analyses Web3 approfondiesAuteur : Jiawei, IOSG Ventures
Rollup constitue-t-il une bonne catégorie d'investissement parmi les nombreuses infrastructures ?
La logique d’investissement autour des Rollups a évolué depuis les débats initiaux entre ZK et OP, puis s’est tournée vers la comparaison pratique du TPS et de l’expérience utilisateur, avant de se concentrer sur les douves défensives construites autour d’outils dérivés comme OP Stack. Selon les différentes phases du développement industriel, les réponses à cette question peuvent varier.
Finalement, la question essentielle reste la suivante : le Rollup est-il un modèle économique rentable ? Quelle est l’économie sous-jacente au Rollup ? Cet article cherche à explorer le modèle commercial des Rollups ainsi que les possibilités de monétisation.
Barry Whitehat a été le premier à proposer le concept de Rollup sur le forum Ethereum Research. Lorsque le concept était encore embryonnaire, on désignait collectivement sous le terme Relayer ou Operator l’entité chargée de son fonctionnement. Avec la spécialisation croissante des infrastructures, ce rôle s’est scindé en plusieurs entités distinctes : le Sequencer, chargé de l’ordonnancement des transactions et de leur écriture dans la couche DA (Data Availability) ; le Challenger, qui relève les défis ; et le Prover, responsable de la génération des preuves. Lorsqu’on étudie l’économie du Rollup, il est pertinent de partir de ces différentes entités.
Source : IOSG
Cet article examine principalement plusieurs aspects de la monétisation des Rollups :
-
L’origine et la composition des frais de transaction (Transaction Fee), ainsi que la situation bénéficiaire ou déficitaire des Rollups ;
-
Les formes de MEV (valeur extractible par minage) et leur monétisation dans le contexte d’un Sequencer décentralisé ;
-
Les possibilités de monétisation basées sur les preuves de faute (Fault Proof) et les preuves de validité (Validity Proof).
Frais de transaction (Transaction Fee)
Comme sur d'autres chaînes, les utilisateurs doivent payer des frais de transaction pour envoyer une transaction sur un Rollup.
Du point de vue du Sequencer, ce coût de transaction comprend principalement deux composantes : le coût d'exécution et le coût de sécurité.
Coût d’exécution (Execution Cost)
Source : John Adler
Le coût d’exécution des Rollups reprend le modèle d’Ethereum. De manière abstraite, chaque nœud Ethereum exécute une machine à états répliquée. Comme illustré ci-dessus, les nœuds téléchargent et stockent les données des transactions, effectuent des calculs, lisent et écrivent en mémoire et sur le stockage — toutes opérations consommant des ressources physiques. Le gaz, unité de mesure unifiée des ressources, permet de quantifier ces coûts implicites.
Ce principe s’étend aux Rollups : exploiter un nœud Rollup engendre un certain coût d’exécution, qui justifie les frais de transaction payés par les utilisateurs. En raison de légères différences avec l’équivalence EVM et des variations de conception, chaque Rollup peut légèrement ajuster sa tarification (par exemple, zkSync Era propose un abstract account natif, dont certaines opérations peuvent coûter plus cher en gaz qu’un compte EOA). Néanmoins, ils adoptent globalement le modèle de gaz d’Ethereum.
Source : Dune Analytics @springzhang
Outre ce coût d’exécution, il convient de prendre en compte les frais de congestion et le minimum de frais de transaction.
-
Frais de congestion. Ils reflètent l’équilibre dynamique entre le prix du gaz et le trafic réseau. Par exemple, durant l’Arbitrum Odyssey, l’augmentation du trafic a provoqué une forte hausse du prix du gaz.
-
Frais de transaction minimum. Afin d’éviter les attaques par spam ou DoS sur les blockchains à très bas coût, il est nécessaire de fixer un seuil minimal. Actuellement, Arbitrum One fixe ce seuil à 0,1 gwei, Arbitrum Nova à 0,01 gwei. Ce montant varie selon la conception du réseau (sur Optimism, il est de 0,001 gwei).
Coût de sécurité (Security Cost)
Source : Celestia Forum @adeets_22
Le coût de sécurité correspond au coût de disponibilité des données (DA), garantissant que le Rollup bénéficie de la même sécurité qu’Ethereum. Il assure que toute personne peut reconstruire l’état du Rollup à partir des données publiées sur Ethereum L1 (ici, nous parlons d’Ethereum L1, bien qu’il existe d’autres solutions DA). Ces coûts DA supportés par Ethereum L1 représentent la majeure partie du coût total du Rollup. En mai dernier, Arbitrum a soumis environ 3 927 Mo de données à Ethereum, pour un coût de 4 856 ETH, soit environ 1,24 ETH/MB. (En comparant avec S3 Standard à 0,023 $/Go et un prix de l’ETH à 1 800 $, le coût de stockage DA sur Ethereum est environ cent millions de fois supérieur à celui d’AWS).
Étant donné que la DA on-chain est extrêmement coûteuse, tous les Rollups ont recours à des méthodes de compression des données. Arbitrum et Optimism Bedrock utilisent respectivement les bibliothèques open source Brotli et zlib pour compresser les données envoyées à Ethereum L1. StarkNet et zkSync Era compressent les données en publiant uniquement le State Diff (différence entre l’état précédent et le nouvel état), plutôt que l’intégralité des données. (P.S. : La mise à jour Optimism Bedrock utilise également plusieurs autres méthodes pour réduire les coûts de transaction ; davantage de métriques sont disponibles ici).
Source : IOSG
À noter que le coût élevé de la DA sur Ethereum L1 devrait être considérablement atténué après l’adoption de l’EIP-4844 lors de la mise à niveau Dencun. Par ailleurs, le « coût de sécurité » discuté ici implique différents niveaux de sécurité. Outre la DA assurée par Ethereum L1, des solutions comme DAC, Celestia ou EigenDA offrent divers compromis entre « sécurité » et « coût », donnant aux applications une large palette de choix. Les applications DeFi peu fréquentes mais à haute valeur privilégieront la sécurité, tandis que celles à haut débit mais à valeur relative plus faible (comme les jeux) opteront davantage pour la réduction des coûts. Chacun peut ainsi choisir selon ses besoins.
Source : Dune Analytics @optimismfnd
En résumé, du point de vue simplifié du Sequencer : le Sequencer perçoit les frais de transaction auprès des utilisateurs et paie les frais DA à Ethereum. Son profit peut donc être calculé selon cette méthode. Actuellement, la plupart des Sequencers sont exploités par les équipes des Rollups. Si l’on fait abstraction des revenus liés à l’émission de jetons, de l’inflation, etc., le revenu du Rollup peut être approximativement mesuré de cette façon.
Source : Token Terminal
Source : IOSG
Prenons Optimism comme exemple : au cours des 30 derniers jours, Optimism a généré un bénéfice journalier d’environ 20 000 dollars. Selon les données de Token Terminal, le bénéfice cumulé depuis son lancement atteint environ 10,9 millions de dollars.
MEV
Le MEV représente un mode de monétisation important pour les Rollups. Toutefois, parler de MEV dans un contexte de Sequencer centralisé unique n’a guère de sens. Nous commencerons donc par examiner le cas du Sequencer décentralisé (DS), avant d’explorer l’économie du MEV sur les Rollups.
Sequencer Décentralisé (DS)
À ce jour, Arbitrum (5,87 Md$), Optimism (2,14 Md$) et zkSync Era (649 M$) reposent sur des Sequencers/Operators centralisés pour ordonnancer les transactions et soumettre les lots.
La décentralisation est un processus complexe nécessitant une mise au point minutieuse. Une transition immédiate n’est pas indispensable. Du point de vue de la sécurité, de la concurrence et des ressources développeurs, l’utilisation d’un Sequencer centralisé au début du projet est compréhensible. Pourtant, un Sequencer centralisé présente au moins deux défauts évidents (comme souvent avec les systèmes centralisés).
-
Censure des transactions : certains utilisateurs peuvent voir leurs transactions censurées, voire victimes d’attaques par rançon. Pour y remédier, Arbitrum et Optimism offrent une option d’inclusion forcée : tout utilisateur d’Arbitrum peut appeler la méthode forceInclusion pour imposer l’inclusion de sa transaction ; StarkEx met en œuvre un mécanisme d’évacuation (« Escape Hatch »), assurant une résistance partielle à la censure.
-
Garantie de disponibilité : le Sequencer doit rester continuellement en ligne. En cas de panne du service centralisé (panne matérielle ou erreur de configuration logicielle), tout le réseau s’arrête. Bien que rare, un tel événement aurait des conséquences graves.
Source : Taiko
Actuellement, le Sequencer joue à la fois le rôle du Builder et du Proposer sur Ethereum L1 : il ordonne les transactions et soumet les lots. Mettre en œuvre un DS revient donc à refaire le chemin déjà parcouru par Ethereum avec PBS.
Pour implémenter un DS, les Rollups disposent généralement de plusieurs options.
-
Mécanisme d’élection ou de rotation du leader, combiné à une construction locale de blocs, similaire à Ethereum L1 sans PBS. Vitalik, dans son article An Incomplete Guide to Rollups, propose plusieurs méthodes : enchères du Sequencer, sélection aléatoire basée sur PoS, vote DPoS, etc. D’après l’expérience d’Ethereum, PBS s’avère clairement la meilleure solution.
-
Mécanisme d’élection/rotation du leader, associé à un marché ouvert de construction de blocs, comparable à PBS intégré à Ethereum L1 ou à l’usage de MEV-Boost par les Proposers.
-
Certains mécanismes spécifiques, comme FCFS (First Come First Serve). FCFS conduit inévitablement à une course à la latence, semblable à la colocation dans le trading haute fréquence traditionnel. Arbitrum utilise actuellement FCFS et étudie des variantes comme Time-Boost. Ce dernier introduit des frais prioritaires, permettant d’accélérer une transaction jusqu’à 0,5 seconde. Il s’agit d’un compromis bidimensionnel entre latence et coût.
Les équipes de Rollups peuvent choisir de construire internement le DS, ou envisager de déléguer le Séquençage :
-
Des projets comme Espresso/Astria proposent leurs propres services DS/SS ;
-
Flashbots construit SUAVE, un mempool cryptographique inter-domaines ;
-
Justin Drake propose le Based Rollup, qui s’appuie directement sur le consensus L1 : les Proposers d’Ethereum L1 incluent les blocs Rollup dans les blocs L1, héritant ainsi du même niveau de décentralisation et de disponibilité.
Chaque choix (interne ou externalisé) comporte des avantages et inconvénients, que nous approfondirons plus loin dans cet article.
Le MEV dans le contexte d’un DS
Source : odos.xyz/arbitrage
Si nous disposons d’un marché DS à construction de blocs ouverte, alors la chaîne d’approvisionnement du MEV observée aujourd’hui sur Ethereum se reproduira sur les Rollups. Le MEV intradomaine (Intradomain MEV) désigne le MEV généré à l’intérieur d’un seul Rollup, sans grande différence avec le MEV sur Ethereum L1 : attaques sandwich, arbitrages entre DEX, etc. Étant donné que les Rollups n’ont pas encore mis en place de DS, l’illustration ci-dessus utilise un exemple d’arbitrage inter-DEX sur Ethereum L1.
Le MEV inter-domaines (Cross-domain MEV) est potentiellement plus intéressant. Nous distinguons deux types : le MEV inter-domaines classique, et le MEV dans le cadre d’un Shared Sequencer (SS).
-
MEV inter-domaines classique
Source : odos.xyz/arbitrage
Le MEV inter-domaines classique se produit entre Ethereum L1 et un Rollup, ou entre deux Rollups. Dans un contexte DS, chaque domaine possède son propre pipeline MEV, impliquant différents rôles. L’image ci-dessus illustre un cas d’arbitrage inter-domaines.
Au niveau du Searcher, le MEV inter-domaines implique des risques d’exécution complexes, car chaque domaine a des temps de confirmation et de finalité différents, rendant incertain l’inclusion des transactions. Pour y remédier, Primev construit un réseau de communication permettant aux Searchers de soumettre leurs offres à plusieurs Builders sur plusieurs domaines, obtenant ainsi une garantie de pré-confirmation (pre-confirmation). Cela permet aux Searchers de quantifier et contrôler leurs risques d’exécution.
Le MEV inter-domaines tend à la centralisation. Comme le souligne Flashbots, un Builder capable de construire des blocs sur plusieurs chaînes dispose d’un avantage significatif sur ceux limités à une seule chaîne, favorisant ainsi la centralisation. Dans le cadre de la feuille de route centrée sur les Rollups, ce sera un enjeu majeur dans les années à venir.
-
MEV dans le cadre d’un SS
La situation change si plusieurs Rollups partagent un même SS.
Source : IOSG
L’une des caractéristiques du SS est sa capacité à permettre des arbitrages atomiques entre Rollups. Avant, lorsque le Searcher soumettait séparément les transactions 1 et 2, il ne pouvait pas garantir qu’elles soient incluses comme souhaité (par exemple, dans le bloc suivant). Avec un SS, le Searcher peut soumettre un Bundle comme illustré ci-dessus : les deux transactions ne s’exécutent que si elles peuvent être satisfaites simultanément ; sinon, aucune ne s’exécute (à condition que les transactions ne soient pas invalides). Cette approche réduit fortement le risque d’exécution pour le Searcher.
Dans un scénario idéal, le SS produirait un effet « global supérieur à la somme de ses parties ». Par exemple, une information isolée sur un seul Rollup peut sembler sans valeur, mais combinée avec d’autres transactions sur d’autres Rollups via un ordonnancement partagé, elle pourrait être exploitée efficacement, transformant des « informations inutilisables » en gains mutuels.
Malgré ces avantages, le séquençage touche à des questions commerciales complexes. À court terme, je pense que les principaux Rollups n’adopteront pas le SS, qui pourrait plutôt être testé d’abord sur des Rollups spécifiques de niche (long tail), ou proposé comme option dans des projets de type Rollup-as-a-Service.
L’économie du Rollup centrée sur le MEV
Source : IOSG
Une fois le DS implémenté, la question revient à savoir comment construire un modèle économique et capturer de la valeur autour du MEV.
Nous avons vu précédemment les coûts du Rollup. Ces coûts proviennent des ressources DA et des ressources physiques nécessaires à l’exploitation du Rollup. Ces ressources limitées créent une rareté de l’espace-bloc. Le MEV reflète le droit de contrôle sur cette rareté. Le Rollup peut donc tarifer ce droit.
Fuel Network estime qu’un modèle de jeton optimisé devrait correctement capter la valeur de l’espace-bloc. Faire payer les frais de transaction en jeton du Rollup est une manière de capter de la valeur (donner de l’utilité au jeton). Mais cela ajoute une friction pour l’utilisateur final. L’idée de Fuel consiste à tokeniser non pas l’espace-bloc lui-même, mais le « droit de percevoir les frais générés dans l’espace-bloc ». Cette approche part du producteur de blocs et du MEV, sans impacter l’utilisateur final.
En lien avec les options DS mentionnées plus haut, voici quelques pistes possibles :
-
Enchère de MEV (MEVA). Les Sequencers participent à une enchère pour obtenir le droit d’ordonnancer les transactions d’un bloc ou d’une période donnée. L’enchère devient un revenu pour le Rollup.
-
PoS. Les participants mettent en jeu le jeton du Rollup, et un Sequencer est choisi aléatoirement ; plus la mise est élevée, plus la probabilité d’être sélectionné augmente. Notons que la sécurité du Rollup repose toujours sur les preuves de validité/faute et Ethereum, et non sur la sécurité économique du PoS. Le PoS sert uniquement à désigner le leader. Le verrouillage de jetons crée un mécanisme de capture de valeur, reflétant fondamentalement la rareté de l’espace-bloc.
-
SS. Comparé aux deux points précédents, le SS est un sujet nouveau et fascinant, sans réponse définitive. Supposons qu’un Rollup délègue son séquençage à un SS : cela signifie qu’il renonce à capter le MEV de son propre domaine — bien que cela puisse créer des effets de réseau multi-domaines, conduisant à des gains mutuels. En revanche, le Rollup pourrait aussi choisir de garder son MEV en interne, soit en le capturant directement, soit en le tokenisant.
Par conséquent, je pense que le SS devrait redistribuer d’une manière ou d’une autre le MEV capturé entre ses différents domaines. Face à la concurrence entre plusieurs SS pour attirer des clients Rollup, cet incitatif à la redistribution devient crucial. Dans ce cas, le MEV redistribué pourrait constituer une source de revenu pour le Rollup.
Preuve de faute (Fault Proof)
(La communauté propose de remplacer « Fraud Proof » par « Fault Proof », car même un acteur honnête peut soumettre une mauvaise transition d’état à cause d’une erreur de configuration logicielle. Le terme « fraude » suppose une intention malveillante, ce qui est inexact.)
La conception classique de la preuve de faute prévoit qu’en période de challenge, toute personne (le challenger) puisse contester une transition d’état. Si la contestation est validée, le fraudeur est puni, et le challenger reçoit une partie de la sanction comme récompense. Le reste des fonds sanctionnés peut être brûlé. Si les sanctions concernent le jeton du Rollup, cela compense tous les détenteurs (plutôt que les victimes de l’attaque). Arbitrum et Optimism Cannon utilisent actuellement des preuves interactives de faute.
Sur Arbitrum, celui qui surveille les transitions d’état et lance un défi est appelé validateur (Validator), tandis que celui qui observe seulement est un watcher (Watchtower Validator). La différence principale est que seul le premier peut lancer un défi, tandis que le second peut simplement alerter (via la communauté ou les médias sociaux). Être validateur requiert une autorisation préalable (liste blanche). Être watcher est permis à tous.
Arbitrum pourrait à l’avenir décentraliser le rôle de validateur (c’est-à-dire de challenger). Pourtant, le système ne nécessite qu’un seul challenger honnête sur N (hypothèse de confiance 1-of-N), ce qui suffit à sécuriser le réseau. Ainsi, je pense que la décentralisation du challenger vise surtout à satisfaire aux exigences de décentralisation. Hormis la récompense financière mentionnée, il y a peu d’espace de conception économique, et cela relève davantage d’une redondance de conception.
Réseau/marché de prouveurs (Prover Network/Market)
Source : Figment Capital
Figment Capital distingue dans son article le Prover Network du Prover Market : le premier désigne un ensemble de proveurs servant une seule application (ex. Scroll), tandis que le second est un marché ouvert où plusieurs applications (ex. Scroll, Succinct) peuvent soumettre des demandes de preuve. Cet article couvre déjà largement les aspects du Prover décentralisé, donc nous n’y reviendrons pas longuement.
Réseau de prouveurs (Prover Network)
Scroll a proposé il y a deux ans l’idée d’un Prover décentralisé.
Source : Scroll
Le Prover (appelé Roller par Scroll) doit staker un jeton pour acquérir une réputation initiale, proportionnelle au montant stake. Lorsque le réseau doit générer une preuve, le Sequencer choisit aléatoirement plusieurs Provers selon leur réputation, et leur demande de produire la preuve dans un délai T. S’il produit une preuve invalide, il est pénalisé ; s’il est valide mais en retard, sa réputation baisse ; s’il est valide et à temps, il peut recevoir une récompense.
L’introduction d’un délai T, plutôt que de simplement récompenser le plus rapide, vise à éviter que le Prover le plus rapide ne monopolise toutes les récompenses. En effet, tant que la preuve est fournie dans le délai T, le Prover le plus rapide et ceux légèrement plus lents ont la même chance de récompense. Ce mécanisme encourage le Prover le plus rapide à paralléliser la génération de preuves pour d’autres blocs afin de maximiser ses profits.
Marché de prouveurs (Prover Market)
Source : =nil;
=nil; propose un service généralisé pour la construction de circuits et un marché de preuves. Les développeurs de circuits et les Provers qui génèrent les preuves reçoivent chacun une part des revenus.
En tant que marché ouvert, =nil; fonctionne comme un marché au comptant, avec deux rôles : le demandeur de preuve et le producteur de preuve. Le premier publie des ordres d’achat, le second des ordres de vente. Les paramètres incluent l’énoncé (ex. circuit de preuve d’état pour Mina ou Solana), le coût, le délai d’expiration et le temps de génération.
=nil; utilise également un système de réputation similaire : les Provers qui ne produisent pas à temps ou génèrent des preuves erronées voient leur note baisser, voire subissent des sanctions.
Tant Scroll que =nil; utilisent un système de staking/slashing et de réputation, mais ciblent des marchés différents : le premier sert le Rollup ZK lui-même, le second dessert plusieurs applications ZK. Ces deux exemples illustrent respectivement les modèles « interne » et « externalisé » du Prover.
Conclusion
En synthèse, voici quelques points clés :
-
Les frais de transaction constituent un modèle simple et efficace. Or, l’un des principaux arguments de vente des Rollups est précisément leur faible coût. Ils n’auront donc probablement pas tendance à trop s’appuyer sur cette source de revenus. Avec l’adoption de l’EIP-4844 et la maturation des solutions DA (Celestia, EigenDA, etc.), les frais de transaction des Rollups devraient encore baisser — une excellente nouvelle pour les utilisateurs.
-
Concernant les Rollups, je pense que les grands projets adopteront progressivement le DS d’ici deux à trois ans, tandis que certains Rollups de niche pourraient aller plus vite. Le MEV, bien que discret, deviendra le principal moteur de croissance des revenus. S’il est construit en interne, cela touche à la conception de l’économie des jetons ; s’il est externalisé via DS & SS, la redistribution équitable du MEV deviendra un enjeu central pour les Rollups et les fournisseurs de service. Actuellement, l’importance du MEV sur les Rollups est gravement sous-estimée.
-
La décentralisation est un processus graduel, avec différents degrés possibles. Que ce soit pour le Sequencer ou le Prover, deux options principales s’offrent : construire en interne ou externaliser. La première offre un large espace de conception, reposant sur des primitives économiques comme le staking-slashing, avec déjà des mécanismes matures disponibles. Je pense que la seconde s’appuiera plutôt sur un modèle de paiement similaire à celui de la DA.
Le DS est probablement plus complexe à concevoir que le Prover, car il est difficile de juger objectivement si une séquence de transactions est correcte ou non. En revanche, une preuve mathématique est déterministe et peut être mesurée quantitativement (temps, coût, etc.). Le DS doit donc être pensé principalement sous l’angle de l’économie du MEV.
Le choix entre ces deux options dépend de la phase du projet, et notamment de l’efficacité du capital et des ressources développeurs. Pour les Rollups en phase initiale, y compris les Rollups spécifiques à une application, externaliser la décentralisation (via DS & SS ou EigenLayer) pour amorcer rapidement le projet peut être la meilleure stratégie. En revanche, les Rollups plus matures disposent de plus de ressources et de capitaux, et s’intéresseront davantage à la capture de valeur par le jeton et à la création de synergies, afin de construire une douve défensive et un effet de réseau auto-renforçant.
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
IOSG Ventures
