MEVconomics.wtf : Une conférence de 7 heures résumée en 80 minutes

La construction des blocs aujourd'hui (1:00)

1. Les utilisateurs envoient des transactions
2. Les chercheurs (searchers) regroupent les transactions et les envoient aux constructeurs de bloc (builders)
3. Les constructeurs créent des blocs et les proposent aux validateurs par l'intermédiaire des relais

La séparation entre les proposants et les constructeurs (alias PBS) permet aux validateurs d'avoir un accès permissionless à la MEV sans avoir besoin d'acteurs sophistiqués.

Tendances depuis le Merge (2:00)

Le marché des constructeurs est devenu plus diversifié avec de nombreux participants prenant des parts de marché (nous pouvons remercier Flashbots d'avoir rendu leur constructeur Open Source).

Certains constructeurs sont en mesure de faire des bénéfices, tandis que d'autres laissent tout passer. mais les constructeurs ont le potentiel d'ajouter des fonctionnalités supplémentaires à leur rôle.

Tendances centralisantes (3:00)

Bien qu'il y ait actuellement un bon niveau de décentralisation sur le marché des constructeurs, nous devons décentraliser davantage :

• Une meilleuretechnologie de confidentialité pour la coordination
• Moins de confiance
• Redistribuer plus de valeurs aux utilisateurs

Des efforts sont faits pour construire un réseau de construction de blocs entièrement décentralisé avec de multiples participants contribuant à la construction d'un seul bloc. C'est exactement ce que fait SUAVE

Marché des relais (4:00)

Les relais agissent comme des tuyaux entre les constructeurs et les validateurs, transmettant les blocs.

Initialement, les relais étaient centralisés avec flashbots qui était largement utilisés. Une diversification s'est opérée ces derniers mois, avec les relais Ultra Sound qui sont devenus plus importants que flashbots.

Ultrasound Relay offre un nouveau concept appelé "Optimistic Relays", où la latence est réduite en éliminant la nécessité pour les relais de valider les blocs avant de les envoyer aux proposants. Le problème est que les blocs ne sont plus entièrement vérifiés mais garantis par les constructeurs.

Que faut-il apporter au niveau du protocole ? (6:30)

Le protocole Ethereum est actuellement simple, et la plupart des acteurs opèrent en dehors de son cœur. Un exemple parfait de cela est la séparation Proposant-Constructeur (PBS). Les relais sont donc nécessaires en raison de l'absence de structure de marché et de mécanisme d'allocation pour le PBS dans le protocole lui-même.

Cependant, nous pouvons voir des mécanismes tels que les Protocol-Enforced Proposer Commitments (PEPC, "pepsi") et le Restaking pour rendre le protocole plus flexible.

Rendre le protocole plus flexible (8:00)

La séparation entre le constructeur de la proposition et le protocole (PBS) comporte deux éléments : la structure du marché et le mécanisme d'attribution.

L'idée de rendre le protocole conscient des engagements externes est explorée comme une alternative aux modèles spécifiques de séparation entre le proposant et le constructeur. C'est ce que PEPC vise à faire, et cela se rapporte beaucoup au Restaking, car les proposants peuvent potentiellement opter pour des engagements externes en dehors du protocole

Cela soulève une grande question : qu'est-ce que le protocole Ethereum doit réellement garantir ?

Vue d'ensemble des marchés

Marché des validateurs (9:30)

Une poignée d'opérateurs contrôlent un montant important en staking. Bien que nous ayons une grande sécurité économique, la décentralisation est nécessaire

Par exemple, Lido a créé le Lido Staking Router : tout le monde peut développer des rampes d'accès pour les nouveaux opérateurs de nœuds, allant des stakers solos aux DAO et à la technologie des validateurs distribués (DVT)

Valeur pour les utilisateur (10:30)

Il n'y a pas de processus compétitif où les gens offrent aux utilisateurs la valeur réelle de ce que leur ordre crée. C'est le concept de base des enchères de flux d'ordres (Order Flow Auctions ou OFA)

Les OFAs impliquent un processus concurrentiel dans lequel les chercheurs font des offres pour le droit d'exécuter des transactions. Les soumissionnaires peuvent capturer de la valeur en proposant des offres plus élevées lors de l'enchère. Le défi consiste à mettre en œuvre des mécanismes trustless pour les enchères de flux d'ordres.

Vue d'ensemble des wallets (11:45)

Les wallets doivent monétiser leur service. Ils regroupent les flux d'ordres des utilisateurs et les envoient à travers la chaîne d'approvisionnement, ce qui leur confère un pouvoir important dans le contrôle du lieu d'exécution des ordres.

Mais conclure des accords privés entre les fournisseurs de wallets et les constructeurs, n'est-ce pas de la TradFi ?

Une approche plus souhaitable est de créer un système permissionless qui évite les forces centralisatrices, en particulier avec les OFAs

Vue d'ensemble de la couche d'application (12:30)

Dans les environnements à usage général comme Uniswap, une part importante de la valeur générée profite aux validateurs Ethereum, aux chercheurs, aux constructeurs, etc. Les applications ont pour but d'internaliser la MEV afin de capturer une plus grande partie de cette valeur pour elles-mêmes :

• Osmosis implémente un module où leur validateur effectue automatiquement des arbitrages et capture des revenus pour l'application (ProtoRev).
• Une autre solution consiste à améliorer la sécurité économique de la preuve d'enjeu grâce à la redistribution de la MEV.

Vue d'ensemble des Layer 2 (13:15)

La MEV est déjà un problème avec les séquenceurs centralisés. Ce problème s'aggrave avec la décentralisation, car il introduit davantage de problèmes et de questions. Par exemple, un système "premier arrivé, premier servi" conduit à des jeux de latence et nous ne pouvons pas construire un jeu juste à partir de cela.

Certains séquenceurs partagés sont en cours de développement :

• Les séquenceurs partagés, tels que les Base Rollups proposés par Justin, permettent à un Layer 1 de séquencer plusieurs Rollups.
• D'autres chaînes, comme Espresso et Metro, proposent des couches de séquençage partagées pour plusieurs Rollups

Les séquenceurs partagés offrent des avantages intéressants mais soulèvent des questions complexes concernant l'économie et la confiance dans ces systèmes.

Taxonomie (0:45)

La MEV est une valeur théorique, alors que la REV est la valeur réalisée extraite des opportunités de MEV

Avant le Merge, la REV était collectée à partir du changement de solde du mineur. Après le Merge, la REV est collectée à partir du changement de solde du Proposer, ce qui est fondamentalement la même donnée. On utilise l'ETH envoyé aux Proposers comme approximation de la REV total.

La REV est divisée en plusieurs parts :

• REV sur les arbitrages atomiques et non-atomiques (MEV-Explore)
• REV sur Ethereum L1, les autres chaînes et le Cross-chain (EigenPhi)
• REV sur les exchanges (Odos)

Elaine mentionne que les sources fournissent des données liés aux activités MEV mais cela ne représente qu'une petite partie de cet ensemble

Répartition de la MEV (5:00)

En supposant que seuls les chercheurs et les proposers reçoivent le MEV (à l'exclusion des autres parties impliquées), environ 48% vont aux chercheurs et 52% aux proposers.

Il y a eu une augmentation de la concurrence chez les relais depuis le Merge, avec un nombre plus important de relais qu'avant. Au début, il n'y avait que Flashbots et Block relays, mais maintenant il y a de multiples options. La part d'utilisation des relais de Flashbots a diminué au fil du temps.

La MEV a accéléré le jeu de latence

Temps d'envoi du bloc du constructeur (7:15)

• Les validateurs demandent l'offre 400 millisecondes en moyenne après le début du slot
• Les blocs gagnants arrivent on-chain environ 149 millisecondes avant le début du slot

Impact de la latence d'envoi des blocs (8:00)

La plupart des blocs sont envoyés dans les 2 dernières secondes du slot, provoquant une latence élevée dans la soumission des blocs. Une latence élevée dans la soumission des blocs peut entraîner des retards dans l'attestation et la congestion du réseau.

Les événements de panique comme l'effondrement de FTX et le bankrun de SVB ont mis en évidence ces problèmes. Heureusement, le bank run de SVB s'est rétabli rapidement par rapport à l'événement précédent.

Analyse de latence (17:00)

Les événements de FTX et SVB ont tous deux montrés des phénomènes de latence similaires. Cependant, si nous comparons avec la latence avant le Merge, le gain de latence est plus sévère, avec la plupart des blocs soumis dans les 2 dernières secondes.

L'augmentation du gain de latence peut être due à la concurrence entre les relais et les constructeurs pour atterrir des blocs, et n'est pas nécessairement liée à la panique du marché.

La MEV en panique de marché

Records de MEV sur 24h (9:30)

La panique de FTX et de SVB a fait réaliser des nouveaux records de MEV sur 24h

• L'arbitrage représente une part considérable du MEV dans les deux événements (volatilité = opportunité d'arbitrage)
• Le bank run de SVB a conduit au depeg de l'USDC, ce qui a permis en plus de l'arbitrage de réaliser des attaques sandwich. Ainsi, le record de MEV était encore plus gros que celui de FTX

Comment examiner les activités de MEV (12:00)

Regarder les deux jours récents avec l'activité de MEV la plus élevée sur Ethereum :

• Total d'ETH payé aux proposers sur Ethereum
• Les ETH à destination des builders VS les ETH à destination des autres & nombre de blocs proposés
• Latence dans la soumission des blocs

Comparer aux stratégies MEV cross-chain :

• Tokens, chaînes et protocoles d'arbitrage
• Chemins employés pour les stratégies d'arbitrage
• Profits d'arbitrage

MEV dans Uniswap & Curve (15:00)

La plupart des arbitrages se sont produits sur Uniswap V2 et V3 pendant l'effondrement de FTX. Cependant, il y a eu une augmentation de l'arbitrage sur le pool de stablecoins Curve lors de la panique de SVB

L'augmentation de l'activité d'arbitrage du pool Curve était attendue car l'événement n'était pas fortement corrélé aux événements de liquidation.

Activités d'arbitrage cross-chain (18:15)

La plupart des opportunités d'arbitrage se produisent entre les stablecoins, BTC, ETH et des tokens majeurs

En novembre, Polygon et Abritrum ont été observés. Mais depuis mars, Ethereum et BSC sont les chaînes les plus fréquemment arbitrées

Sur les 10 principaux arbitrages les plus rentables, des inexactitudes peuvent exister en raison d'opportunités d'arbitrage non recensées ou de données manquantes

Résumé(20:45)

• L'estimation de la MEV est difficile, car les données sont limités dans les échanges CEX-DEX et CEX-CEX
• Il y a plus de relais et de builders qu'avant le Merge
• La part de marché du plus gros builder lors des périodes de MEV élevées a diminué
• Les stratégies d'arbitrage des Searchers se concentrent sur ETH, BTC et les stablecoins. Les stratégies de liquidation sont basées sur des événements
• Les arbitrages cross-chain connaissent des pics d'activité durant les crises, à une échelle bien plus importante que la moyenne sur 24h
• Les stratégies cross-chain des Searchers diffèrent en fonction des crises de marché
• Il faut encore améliorer les estimations de la MEV cross-chain

Comment marier l'information et la monnaie

Contexte (1:00)

• D'un côté, nous avons les domaines d'étude basés sur l'information (entropie, stockage, cryptographie, confidentialité...)
• De l'autre côté, nous avons l'économie qui tente de modéliser les interactions humaines (cryptomonnaie, enchères basées sur le MEV-time...)

Notre objectif est d'essayer de marier ces deux domaines disparates avec un ensemble unificateur d'abstractions qui permettra aux deux de mieux communiquer

Il y a des similitudes (2:15)

Entre l'information et l'argent, il y a des similitudes. Par exemple, la quantification joue un rôle crucial dans les deux domaines.

Phil suggère qu'une transformation mathématique propre est nécessaire pour unifier le raisonnement sur la théorie de l'information et la théorie monétaire. Cette idée n'est cependant pas originale, nous allons voir que de nombreuses personnes ont travaillé dessus

Du coup, quel est l'intérêt ? (4:00)

La clé pour unifier l'information et la monnaie réside dans la MEV et la confidentialité. Cela nous permettra d'utiliser à la fois l'information et l'argent pour créer les meilleurs systèmes pour les utilisateurs.

Leçons du passé

Conception de mécanismes (4:30)

La conception de mécanismes est un domaine de l'économie et de la théorie des jeux qui a débuté dans les années 1960, et qui adopte une approche axée sur les objectifs pour concevoir des mécanismes économiques ou des incitations, vers des objectifs souhaités, dans des paramètres stratégiques, où les joueurs agissent rationnellement. Elle visait déjà à résoudre la prise de décision basée sur des silos d'information.

Dans la conception de mécanismes, l'agrégation d'informations en une seule sortie est cruciale.

Le vote est biaisé (5:15)

Un théorème de 1973 et 1975 se concentre sur le problème de l'allocation et de la prise de décision basées sur les systèmes de vote. Ils mettent en évidence trois propriétés indésirables qui créent des tensions dans les systèmes de vote :

1. Règle dictatoriale: l'entrée d'un électeur détermine complètement le résultat du vote
2. Limiter les résultats possibles: restreindre les choix à seulement deux alternatives est considéré comme limitant
3. Vote tactique: les électeurs préfèrent jouer selon un modèle inspiré du comportement d'autres personnes (alias "Metagame") que leurs propres préférences

D'une manière ou d'une autre, tous les votes sont soumis à des incitations, par conséquent les votes ne seront jamais sincères...

La monnaie comme primitive (7:15)

...Mais en ajoutant la monnaie, des mécanismes plus complexes comme les enchères peuvent être construits, dépassant les résultats traditionnels de la théorie du choix social.

Ce résultat sous-tend les études fondamentales de conception de mécanismes : La monnaie sert de primitive puissante dans la conception de mécanismes, permettant des possibilités plus larges au-delà du simple vote ou de l'élicitation d'informations.

Il faut des alternatives à la monnaie (8:00)

Dans les années 80 et 90, nous avons commencé à remettre en question la monnaie comme primitive : dans de nombreux contextes, ces transferts monétaires ne sont tout simplement pas disponibles, mais nous voulons toujours résoudre les problèmes de conception de mécanismes.

Nous avons donc commencé à explorer d'autres modèles qui permettent d'obtenir des résultats similaires à la monnaie sans reposer uniquement sur des transferts monétaires.

Nous avons constaté que même en l'absence de transferts monétaires réels, ceux-ci peuvent être approximés par un "engagement" (information + action)

En amenant les agents à s'engager à respecter une règle et à fournir des informations privées qui s'alignent sur cet engagement, de nombreuses propriétés souhaitables peuvent encore être atteintes sans avoir besoin de monnaie

Confidentialité différentielle dans la conception de mécanismes (10:30)

En intégrant des sorties différentiellement correctes et des entrées différentiellement privées, il devient possible de réaliser une nouvelle classe de mécanismes qui n'étaient auparavant pas réalisables sans confidentialité différentielle.

La théorie de l'information sert de cadre reliant divers domaines tels que la conception de mécanismes, la confidentialité, l'économie et la monnaie.

Ainsi, selon la conception de mécanismes, le bon type d'engagement ou de confidentialité est indiscernable de la monnaie !

Une implication pratique : les smart contracts confidentiels (12:00)

Advantages

• Les smart contracts privés offrent plus d'options pour approximer les propriétés de l'argent
• Ils permettent la construction d'enchères et de mécanismes plus efficaces par rapport à ceux qui reposent uniquement sur des transferts publics.

Limitations

• Il est très difficile de construire ces derniers de manière sécurisée sans centralisation
• L'absence de confidentialité sans confiance entraîne des externalités

Résoudre les défis de la confidentialité

La crypto a déjà des transferts, les transferts sont sans confiance mais la confidentialité ne l'est pas, et de nombreux mécanismes nécessitent la confiance. Partant de là, nous sommes confrontés à une zone grise :

• Quelles sont les limites de la confiance décentralisée ?
• Comment pouvons-nous formuler une frontière d'abstraction pour la confiance ?
• Que gagnons-nous en résolvant la confidentialité ?

Scénario optimiste : nous résolvons les défis (15:00)

Si une solution pour la confidentialité privée universelle de confiance est trouvée, cela créerait un cas d'adoption clair qui rend la crypto meilleur pour les utilisateurs, et construire des dapps plus efficaces.

En fin de compte, la crypto domine le monde parce que la finance classique ne pourrait pas rivaliser avec la confidentialité privée universelle de confiance

Chaîne d'approvisionnement de la MEV (16:15)

MEV-share et MEV-boost reposent sur la confidentialité pour atteindre l'efficacité, et cela est possible grâce à des frontières d'abstraction.

Cependant, les solutions de confidentialité actuelles comme Flashbots sont centralisées et sous-optimales selon le point de vue de la théorie de l'information

Projet SUAVE (18:15)

L'objectif de SUAVE est d'atteindre une défense en profondeur à la frontière entre la conception de mécanisme idéale et la confidentialité contrôlée par l'utilisateur.

Bien que MEV-share et MEV-boost servent leur objectif, ils sont centralisés et sous-optimaux en termes de confidentialité. Il est nécessaire de remplacer ces solutions centralisées par des alternatives plus décentralisées, et SUAVE cherche à devenir l'une de ces alternatives.

F.A.Q avec Jon Charbonneau

En fonction de la progression du développement, quel est l'état pratique de la primitive de confidentialité ? (20:30)

La force de développement pour la confidentialité est incitée financièrement (donc très puissante), car les gens veulent construire des systèmes qui ne peuvent être réalisés qu'avec la confidentialité, c'est pourquoi MEV-boost et MEV-share existent

Les fonctionnalités et techniques de construction comme PBS et Danksharding sont explorées pour permettre de nouvelles classes de mécanismes grâce à la confidentialité et aux engagements

Mais fondamentalement, Phil ne pense pas que ce soit suffisant :

• Bien que les systèmes centralisés aient fonctionné de manière adéquate jusqu'à présent, ils posent une pression centralisatrice importante sur nos systèmes globaux
• L'ajout de technologies comme les SGX peut limiter les actions des acteurs mais ça revient à se reposer sur un acteur centralisé (SGX repose sur Intel)
• Les comités ont également leurs inconvénients pour atteindre une pleine décentralisation.

Phil insiste sur la nécessité d'une combinaison de techniques qui maximisent la décentralisation pour contrer les pressions économiques

Admettons qu'Ethereum n'implémente pas réellement PBS (ou d'autres fonctionnalités). Comment pourrait-on décentraliser autrement ? (23:00)

Il se peut qu'il ne soit pas essentiel pour la Fondation Ethereum (EF) de soutenir la mise en œuvre de certaines fonctionnalités si la communauté est suffisamment alignée vers la décentralisation.

Bien que l'EF ne soit pas le seul acteur pour réaliser la décentralisation, elle devrait disposer d'une « option nucléaire » si nécessaire.

Phil suggère d'explorer d'autres façons de décentraliser, comme la construction d'alternatives décentralisées et le partage de primitives pour les utilisateurs.

Vue d'ensemble

• À quoi ressemblent l'économie des protocoles en général
• Les changements qui se sont produits dans le protocole Ethereum et les applications
• Problématiques à venir

L'économie des protocoles

Questions d'économie politique (1:00)

Exemple sur le comportement de la chaîne : si la chaîne est soudainement attaquée, l'application a-t-elle des problèmes et cela affecte-t-il l'une des incitations ?

Comment la chaîne fonctionne

• L'utilisateur envoie des transactions à la chaîne et lit des données à partir de la chaîne
• Les applications sont la raison pour laquelle les utilisateurs envoient des transactions, et elles donnent des incitations aux utilisateurs
• Les acteurs du consensus maintiennent la stabilité de la chaîne grâce aux récompenses minées, aux récompenses de validation, aux pénalités et aux autres récompenses définies par le protocole pour s'en tenir à leurs rôles

En fin de compte, la MEV concerne les incitations de protocole supplémentaires qui surviennent principalement de façon accidentelle et la façon dont elles finissent par affecter certaines des incitations à exploiter la chaîne.

Les risques à surveiller (3:00)

Le risque principal concerne les incitations des validateurs. Nous devons nous assurer que les validateurs agissent correctement au lieu d'agir de manière incorrecte ou de tenter des attaques contre la chaîne. La bataille entre les incitations des utilisateurs (frais de transaction) et les pots-de-vin potentiels pour censurer la chaîne est une préoccupation.

Outre cela, les économies d'échelle peuvent conduire à la centralisation. Si les acteurs du consensus voient constamment des stratégies complexes et changeantes, en particulier avec des informations exclusives requises, cela conduit à la domination de grandes pools.

Les incitations à avoir une faible latence impliquent une concentration géographique et le cloud computing. Ces deux phénomènes contribuent aux risques juridiques, qui affectent la crédibilité neutre d'une blockchain, comme nous l'avons vu au cours de la dernière année (avec les blocs conformes à l'OFAC)

Les changements qui se sont produits

Montée de la DeFi (6:45)

Les opportunités pour les noeuds de profiter de la manipulation des blocs existent depuis 2017 avec les fameuses ICO, mais il n'y avait pas assez de valeur pour justifier les coûts d'infrastructure nécessaires pour les capturer.

Depuis 2020 et le DeFi Summer, il est devenu rentable d'investir les coûts d'infrastructure pour capturer la MEV, car il existe des opportunités MEV dans chaque bloc et des pics d'activité plus importants qu'en 2017.

Cela a créé la nécessité de choses comme la séparation Proposer-Builder (PBS), afin que les rôles restants ne dépendent pas autant des économies d'échelle.

Changements historiques (8:45)

L'EIP-1559 a apporté des améliorations significatives à l'expérience utilisateur. Quant au Merge, on ne sait pas encore clairement si cette mise à jour a été bénéfique ou néfaste à Ethereum, tellement les changements sont importants.

Les effets à long terme du Merge sont encore incertains mais auront probablement un impact durable sur Ethereum.

Changements à venir

Retraits (11:30)

Les retraits seront activés lors du prochain hard fork, qui va entraîner une réduction du montant total engagé. Mais les gens auront plus confiance pour s'engager car ils peuvent récupérer leur argent.

Vitalik pense que la principale conséquence pratique sera un changement dans le montant total des ETH stakés et, éventuellement, un changement dans la composition des validateurs.

Élections secrètes à un seul leader (12:30)

Les élections secrètes à un seul leader garantissent que l'identité du proposer n'est connue que d'eux-mêmes avant la production du bloc, réduisant le risque d'attaques par déni de service contre les propositions.

Les proposers peuvent révéler volontairement leur identité et prouver qu'ils seront le proposer.

Question de recherche : y a-t-il des effets involontaires et en particulier, en combinaison avec PBS, y aurait-il des incitations pour les proposers à pré-révéler leur identité à quiconque ?

Single Slot Finality (13:15)

Le Single Slot Finality (SSF) implique que les blocs sont immédiatement finalisés au lieu d'être finalisés après deux epochs (1 epoch = 32 blocs, donc 64 blocs)

Cela peut augmenter la sécurité contre les réorganisations et rendre Ethereum plus adapté aux bridges, sauf dans des cas particuliers comme les inactivity leaks.

Mais comme nous allons le voir avec les pré-confirmations des Layer 2, le Single Slot Finality ne sera pas de facto à un seul bloc pour de nombreux utilisateurs et Vitalik pense que ce sera une nuance intéressante.

Économie des protocoles et Layer 2

L'impact sur l'économie du Layer 1 dépend de la façon dont les Layer 2 sont implémentés :

• Séquençage: les "Based Rollups" sont les Layer 1 faisant le séquençage pour eux (Plus d'infos sur le post de Justin Drake), et "L2-controlled" signifie que le Layer 2 a son propre séquenceur
• Pourcentage de DeFi au Layer 1 qui transitionnent au Layer 2s : pas d'impact si toute la DeFi de Layer 1 ne bouge pas, impact important si toute la DeFi de Layer 1 bouge
• Les pré-confirmations de Layer 2, l'économie des protocoles et les effets de réseau sont également des considérations importantes.

Qui peut soumettre un lot (batch) ? (15:15)

Les Based-rollups impliquent des lots de transactions engagés dans le Layer 1. Il existe différentes approches pour séquencer les transactions dans les solutions de Based-rollups

Par exemple, l'approche "anarchie totale" permet à quiconque de soumettre un lot à tout moment. Le PBS réduit les coûts et rend l'approche d'anarchie totale viable, mais elle présente d'importants inconvénients, comme le gaspillage de gas.

D'autres approches incluent les séquenceurs centralisés, le vote DPoS et la sélection aléatoire. Il y a donc beaucoup d'options qui ne sont pas "based"... La question est : Faut-il que les Rollups soient basés ou non ?

Les Layer 2s peuvent-ils absorber la MEV "complexe" du Layer 1 ? (17:00)

Non si :

• Les rollups sont basés. Le système PBS fait simplement le séquençage pour le Layer 2, donc MEV du Layer 2 = MEV du Layer 1.
• Une grande partie de la DeFi L1 reste sur le L1
• L'inclusion rapide des transactions L1 aide l'arbitrage L2 d'autres manières.

À part ça...Peut-être ?

Fraude et censure (17:45)

Si vous pouvez censurer une chaîne pendant une semaine ET qu'elle ne se réorganise pas socialement, vous pouvez alors voler des rollups optimistes (Optimism 👀)

Cela dit, des attaques de censure beaucoup plus courtes existent également sur la DeFi. Nous pouvons faire une énorme attaque MEV sur toutes sortes de projets DeFi. On parle des Layer 2 mais c'est aussi un problème sur les Layer 1

Préconfirmations (18:30)

Les utilisateurs préfèrent généralement des confirmations plus rapides que les 12 secondes standard. Les pré-confirmations sont envisagées par de nombreux Rollups pour résoudre ce problème.

L'idée est d'avoir un protocole de préconfirmation off-chain qui confirme les blocs de Layer 2 avant de les soumettre au Layer 1. Ce processus implique la vérification d'une preuve compacte de la préconfirmation dans un bloc de Layer 1

Avec cette approche, les utilisateurs vivent un processus de confirmation en trois étapes :

1. Acceptation de la transaction
2. Préconfirmation du bloc de L2
3. Confirmation finale sur le L1

Le SSF sur le L1 devient plus réalisable lorsque la plupart des utilisateurs s'appuient sur les préconfirmations des L2. Cependant, il y aura toujours une distinction entre les vitesses de confirmation.

Confirmation gratuite (19:45)

Avoir deux niveaux de confirmation sera probablement inévitable en raison des attentes des utilisateurs concernant les délais de confirmation

Les préconfirmations en L2 sont incompatibles avec les Based-rollups, car le protocole de soumission doit respecter le mécanisme de préconfirmation. Si un ensemble de blocs de L2 n'adhère pas aux préconfirmations, il sera rejeté.

Conclusion (21:00)

L'espoir de Vitalik est que les Layer 1 deviennent plus chiants, mais ce n'est pas garanti

Tout dépend de la mesure dans laquelle la L2 absorbe les fonctionnalités et les risques, au lieu de créer des effets d'interaction nouveaux et plus compliqués avec leurs propres risques.

On a besoin d'une analyse plus poussée sur un monde Post-Layer 2 !

Chaque Rollup a une roadmap pour se décentraliser. Cependant, la façon dont le séquençage fonctionne en Layer 2 combine l'équivalent d'un proposer de Layer 1 et d'un Builder de Layer 1 à la fois.

La combinaison Proposer et Builder crée toute une série de problèmes, à moins que nous séparions ces deux rôles sur le Layer 2, tout comme nous l'avons fait sur le Layer 1 avec le Proposer-Builder Separation (PBS)

Même avec le PBS sur le Layer 2, nous sommes confrontés à des défis comme la confidentialité, le MEV cross-chain et la latence qui nécessitent de décentraliser le rôle du constructeur

Décentraliser les séquenceurs de rollup

Qu'est-ce qu'un séquenceur ? (1:30)

Il y a essentiellement 4 étapes impliquées dans un séquenceur, qui fonctionnent dans à peu près tous les Layer 2 :

1. Les utilisateurs envoient les transactions au séquenceur
2. Le séquenceur organise les transactions suivant l'ordre qui lui sied
3. Le séquenceur donne une préconfirmation à l'utilisateur
4. Le séquenceur envoie le lot de transactions à la couche de données

Selon le Layer 2, il peut y avoir de petites différences. Par exemple, dans Starknet, le séquenceur est également le prouveur donc ils ont encore plus de responsabilités, mais tout cela peut être déconstruit avec le temps.

Pourquoi décentraliser les séquenceurs L2 est-il important ? (2:30)

Nous n'avons même pas commencé à imaginer l'état final du scaling Ethereum. Actuellement, les fournisseurs de Rollups ne se concentrent pas seulement sur la construction de leurs propres rollups. Ils ont tous changé de plan pour faire une sorte de Rollups-as-a-Service.

Par conséquent, Hasu pense qu'il est possible de voir un avenir où le déploiement d'un Rollup ressemblera au déploiement d'un smart contract aujourd'hui, avec de nombreux Rollups fonctionnant comme des blockchains indépendantes. Le problème est que tous ces séquenceurs sont centralisés.

Comment décentraliser ? (4:15)

• La première proposition est les "Based Rollups" (séquencés sur le L1 ou une autre chaîne) comme l'a mentionné Vitalik juste avant
• Séquençage partagé, où une blockchain séquence plusieurs autres (style Espresso)
• Enchère séquenceur/bloc, où le droit de proposer le prochain bloc ou la prochaine série de blocs est mis aux enchères de temps en temps (comme Optimism)
• Sélection aléatoire à partir d'un réseau Proof-of-Stake, où on a un mécanisme de consensus par-dessus le Rollup où un proposer est sélectionné au hasard (comme Stargate)
• Diverses solutions basées sur des comités, la plus courante étant "premier arrivé, premier servi".

Séquenceur = L1 Proposer + L1 Builder

Si on regarde de plus près, on peut voir qu'il y a au moins 2 composantes dans le séquenceur :

1. Mécanisme de sélection des leaders (Proposing)
2. Mécanisme d'ordonnancement (building)

La décentralisation revisitée (6:00)

Les propositions mises en avant ont différents mécanismes de sélection des leaders, différents mécanismes d'ordonnancement. Mais nous voyons également que les propositions actuelles se concentrent principalement sur les mécanismes de sélection des leaders plutôt que sur les mécanismes d'ordonnancement.

C'est un problème, parce que si nous faisons des Layer 2 sans PBS, nous recréons le fonctionnement d'Ethereum L1 pré-PBS sur ces Rollups.

En d'autres termes, tous ces problèmes dont nous avons parlé il y a deux ans sur Ethereum reviendraient sur les Rollups, en pire parce que la MEV est une industrie à part entière aujourd'hui.

Hasu pense qu'il est plus précis de parler de Proposer-as-a-Service parce que c'est vraiment le terme approprié. Nous devons commencer à séparer les rôles de proposer et de Builder sur le Layer 2, tout comme nous l'avons fait sur le Layer 1.

Ce que fait le PBS (8:00)

Avant le PBS, nous étions seulement en mesure d'exprimer essentiellement ces deux dimensions à travers une seule unité, qui était le prix du gaz.

Avec le PBS, qu'il s'agisse d'un petit validateur solo ou d'un grand pool de staking comme Lido ou Coinbase, ils gagnent tous la même chose de la MEV et c'est un énorme avancée

Les nouveaux défis du PBS Layer 2

Confidentialité (9:45)

La confidentialité est probablement le plus grand défi lors de la décentralisation du séquenceur. Les séquenceurs centralisés rendent la confidentialité facile, mais la décentralisation est "difficile as fuck". Nous devons faire un choix très difficile : faut-il supprimer la confidentialité ou la décentraliser ?

Les deux voies sont très difficiles et on ne sait pas laquelle est la meilleure

1. Au moins, ces constructeurs de blocs centralisés sont en concurrence les uns avec les autres sur une sorte de marché concurrentiel, mais on doit décider à quel constructeur on fait confiance et quel constructeur ne la mérite pas
2. Le chiffrement à seuil (TSS) ou les modèles de "premier arrivé, premier servi (FCFS)" peuvent être utilisés mais peuvent toujours être centralisés.
3. Le partage du même type de confidentialité entre différentes parties peut fournir une confidentialité décentralisée.

MEV Cross-chain (13:00)

Le marché des constructeurs est déjà centralisant en raison des économies d'échelle. Mais la simple existence des Layer 2 aggrave le problème en raison de la fragmentation de la liquidité.

Latence (13:45)

Il s'est avéré que les utilisateurs aimaient tellement les confirmations plus rapides qu'ils ont dû passer à un séquenceur centralisé avec des pré-confirmations plus rapides. Cette latence inférieure est une grosse friction pour la décentralisation.

Nous avons besoin que nos systèmes soient insensibles à la latence. Si nous abaissons trop le temps de bloc, nous décourageons la participation de quiconque n'est pas en mesure de se localiser dans la même zone géographique.

Le PBS est essentiel mais ne suffit pas

SUAVE (14:30)

Nous devons également chercher à décentraliser le rôle du constructeur lui-même, et Hasu a présenté Suave comme une proposition visant à décentraliser le rôle du constructeur.

Dans le scénario final du rollup, nous allons avoir besoin :

• Du séquenceur décentralisé
• Avoir besoin du constructeur décentralisé
• Avoir besoin du mempool privé

Sinon la décentralisation ne marchera pas.

Conclusion (16:30)

À retenir : Sequencer = L1 Proposer + L1 Builder (constructeur). La séparation est excellente, mais nous ne devons pas ignorer la partie constructeur, car nous devons décentraliser les deux.

ETHconomics

Flux MEVconomiques (0:30)

La MEV n'est pas inhérente à la blockchain, elle provient des jeux économiques et des activités financières construites au dessus de la blockchain.

Cela dit, la MEV implique l'ensemble du système, nous devons donc réduire la MEV de 4 façons :

1. Réduire la MEV grâce à une conception lucide du protocole au niveau du jeu et de l'inclusion des transactions (la plupart des gens travaillant dans ce domaine se concentrent sur l'inclusion des transactions)
2. Méthodes efficientes pour extraire la MEV restante (aujourd'hui, il s'agit en grande partie de Searchers / Builders)
3. La MEV extraite doit être capturée de façon trustless (Order Flow Auctions ou autres protocoles sans tiers de confiance)
4. La MEV capturée doit être allouée correctement pour optimiser les incitations monétaires (nous devons essentiellement nous assurer qu'il revienne aux utilisateurs)

Quel devrait être l'objectif de l'allocation de la MEV ? (5:30)

Nous avons tendance à imaginer les flux de MEV comme une chaîne d'approvisionnement, mais il s'agit plus d'un réseau d'approvisionnement complexe.

Nous devons mesurer et définir des métriques autour des retards d'inclusion, des écarts des validateurs par rapport au comportement honnête, etc. Disposer de données sur ces propriétés complexes du réseau d'approvisionnement permettra de concevoir de meilleurs protocoles.

La meilleure façon d'allouer le MEV est comme l'imposition d'une taxe équitable basée sur les externalités que les différents acteurs imposent au système. Cela minimise les pertes pour les utilisateurs honnêtes.

Rig Open Problems (6:30)

Rig Open Problems (ROP) est une initiative de recherche et de mesure des propriétés et métriques complexes de l'industrie de la MEV.

Nous réunissons divers acteurs de l'écosystème pour collaborer à la compréhension des données MEV réelles, et l'objectif est d'utiliser les données pour concevoir de meilleurs protocoles et systèmes.

MEVconomics

Précédence de la MEV (7:45)

La précédence de la MEV (ou MEV Precedence) est l'ordre dans lequel la MEV doit être transmis aux différentes parties.

Deux parties prenantes devraient avoir la plus haute précédence pour la MEV, selon Justin :

1. La plus haute précédence pour les utilisateurs. Les utilisateurs initient la MEV par leurs activités on-chain, ils devraient donc capter la valeur qu'ils créent.
2. Les détenteurs de jetons devraient avoir la précédence suivante. La façon dont ils reçoivent des flux est par combustion, et nous avons déjà la combustion des frais de base avec l'EIP-1559. Mais nous pouvons mettre en œuvre d'autres mécanismes de « combustion de MEV (MEV Burn) » qui peuvent rediriger plus de MEV extrait vers les détenteurs.

Les proposers ont une précédence anormalement élevée (9:30)

Actuellement, les proposers choisissent simplement l'offre de MEV la plus élevée. Et cela conduit à des comportements qui nuisent aux utilisateurs :

• Incitations aux réorganisations. Les paiements élevés de MEV incitent les proposers à réorganiser la chaîne et à voler des blocs à forte valeur.
• Centralisation. Puisque la plupart des proposers perdent la « loterie », ils doivent mettre en commun la MEV, ce qui conduit à la centralisation.
• "Rug pulls". Les opérateurs de pool peuvent voler de gros paiements MEV au-delà de leur garantie / réputation en jeu.
• Payer trop cher pour la sécurité. La demande de staking excessive pendant les pics de MEV assèche l'offre d'ETH nécessaire aux stablecoins décentralisés, etc.

Tous ces comportements sont appelés « MEV toxique », et les proposers prennent une majeure partie de ces flux économiques, tandis que les utilisateurs sont pénalisés.

MEV Burn (13:30)

Afin d'éviter la MEV toxique, nous devons rediriger la MEV loin des proposers et les utilisateurs / détenteurs de jetons devraient avoir la plus haute précédence pour le MEV. Un moyen d'y parvenir est le "MEV Burn"

Bénéfices (17:40)

• Augmente la rareté d'ETH. Brûler la MEV augmente la rareté d'ETH, ce qui soutient Ethereum en tant que couche monétaire et de règlement (settlement)
• Récompenses plus équitables. Actuellement, la MEV fait perdre de l'argent à la plupart des utilisateurs au profit d'une stricte minorité. Avec le MEV Burn, tout le monde gagne à peu près les mêmes récompenses.
• Sécurité plus effciente, dans le sens où on n'a pas besoin d'autant d'émission pour payer la sécurité économique.
• Plus d'ETH à disposition en tant que liquidité. Avec moins d'ETH bloqué dans le staking, il y en a davantage pour les stablecoins décentralisés et autres besoins économiques.

Crédibilité du protocole & problèmes d'agent principal (PAP)

Protocole PEPC "Pepsi" (20:15)

PEPC (Protocol-enforced proposer commitments) est un mécanisme proposé pour permettre aux validateurs Ethereum de conclure des engagements avec des tiers de façon permissionless et trustless.

L'idée est de permettre aux validateurs de prendre des engagements qui sont appliqués par le protocole, de sorte que les validateurs ne puissent pas violer les engagements qu'ils prennent. Par exemple, un validateur pourrait s'engager à laisser un constructeur (builder) spécifique créer son bloc. Le protocole appliquerait cela en ne considérant comme valide qu'un bloc réalisé par ce constructeur spécifique.

Comment ça marcherait :

1. Les validateurs peuvent soumettre des engagements exprimés sous forme de code de smart contract lorsqu'ils proposent un bloc. Ce code définit les engagements pris par le validateur.
2. D'autres parties peuvent vérifier ce code pour vérifier les engagements du validateur avant d'interagir avec eux.
3. Le protocole applique les engagements en ne considérant les blocs comme valides que s'ils satisfont aux engagements pris par le proposant

PEPC vise à fournir l'infrastructure pour que les validateurs externalisent des tâches tout en conservant les garanties de sécurité du protocole. Cela pourrait permettre plus de décentralisation en permettant aux validateurs moins sophistiqués d'externaliser des tâches complexes.

Crédibilité du protocole (21:40)

Crédibilité du protocole = Introspection du protocole + Agence du protocole

Nous avons vu que les mises à jour itératives axées sur la communauté ont bien fonctionné jusqu'à présent. Le problème est que, à mesure que les économies deviennent plus complexes, de plus en plus de choses sont déléguées, conduisant à des incitations désalignées (voire contradictoires) entre des domaines de confiance fracturés. C'est ce qu'on appelle les problèmes d'agent principal (PAP), et ils conduisent à des risques de crédibilité.

PEPC introduit une "crédibilité de protocole programmable" pour traiter de manière flexible les problèmes d'agent principal. Il fournit des solutions pour que le protocole voie les PAP comme plus "crédibles" puisque l'ensemble des validateurs défendra les engagements.

Cependant, cela peut entrer en conflit avec l'objectif de minimiser les engagements du protocole que la communauté doit défendre sans relâche. Quoi qu'il en soit, des travaux sur la crédibilité et les engagements liés à cette théorie sont en cours.

Q&A

Optimiser l'allocation de MEV pour aligner les incitations (26:50)

L'allocation idéale de la MEV est comme une taxe équitable basée sur les externalités que les utilisateurs imposent au système, cela aligne les incitations et minimise les pertes.

Mais étant donné la complexité des problèmes, nous n'avons que des éléments de réponse :

• Séparer clairement la couche de consensus (émission) et la couche d'exécution (fiscale) lors de la gestion de la MEV. Une partie de la MEV devrait aller vers les validateurs pour maintenir les incitations, et une autre partie va vers les utilisateurs. Par exemple, dans le type d'allocation qu'un système OFA ferait, il y a un transfert direct vers l'utilisateur.
• Le lissage de la MEV (via MEV Burn) ne résout pas totalement les problèmes. Cela ne résout pas le manque de liquidité en ETH due à une demande excessive de staking, et les comités centralisés créent d'autres risques.
• La mise aux enchères des créneaux de validateurs internalise la MEV. Les validateurs paient plus s'ils bénéficient de la MEV au niveau de la couche d'exécution, et cela lie les incitations des couches de consensus et d'exécution.

La clé est d'utiliser les données pour calibrer dynamiquement des mécanismes d'allocation à plusieurs niveaux qui alignent les incitations des utilisateurs, validateurs et protocoles. Le MEV Burn et les enchères de validateurs pourraient fonctionner ensemble 👀

Layer 2s (32:20)

À propos des rollups

• Les équipes de Rollups sont déjà bien incitées financièrement avec de grandes capitalisations boursières. Ils nécessitent de grandes équipes et prennent des risques substantiels.
• Le capitalisme des Rollups deviendra une marchandise au fil du temps. Comme l'électricité et l'eau, il y aura moins d'incitation financière nécessaire à terme.
• Les Rollups veulent une décentralisation maximale. Ils veulent passer de séquenceurs centralisés à décentralisés.
• Les rollups ont besoin d'une exécution rapide et d'un plan de décentralisation. Une feuille de route de neutralité crédible est vitale étant donné les effets de réseau.

Dans tous les cas, les rollups non basées domineront à court/moyen terme

À propos des Based Rollups

• Les Based Rollups font partie de la progression de la décentralisation. Ils Déplacent le séquenceur de L2 vers L1, conduisant à un rollup consacré "enshrined rollup".
• Les Based Rollups offrent crédibilité, sécurité et décentralisation. Cela s'aligne avec l'objectif final d'un rollup mature et maximalement neutre.
• Cependant, on ne voit pas clairement comment les Based Rollups fournissent des pré-confirmations. Mais des méthodes comme Eigenlayer peuvent permettre ces services.

Les Based Rollups font partie intégrante des recherches pour concevoir des rollups.

Avons-nous besoin de enshrined PBS "ePBS" ? (37:45)

L'industrie de la MEV évolue rapidement semaine après semaine. Étant donné son rythme de changement, nous avons besoin de plus de recherche avant de nous engager :

• Voir plus de données et d'expérimentations
• Comprendre la forme optimale avant d'avoir besoin de l'utiliser

Des solutions de minimisation de la confiance alternatives valent la peine d'être explorées avant de s'engager. Les opérateurs de relais veulent un ePBS, mais être un opérateur de relais comporte des risques comme les piratages, les collusions ou les vols. Nous avons besoin de techniques astucieuses pour supprimer la confiance du relais :

• Flashbots travaille à utiliser les SGX pour supprimer le relais.
• Les recherches sur le relayage optimiste (Optimistic Relaying) fait progresser le PBS

Cela dit, selon les participants, nous aurons une sorte d'équilibre raisonnable dans 1.5 à 2 ans.

Le pays de la MEV

Sa population (0:45)

Trois agents sont impliqués :

1. Utilisateur honnête : Tout ce que les utilisateurs veulent est d'acheter/vendre leurs tokens
2. Proposer : Ordonne les transactions en attente et décide de l'ordre final de ces transactions dans le prochain bloc.
3. Searcher : Les bots MEV qui recherchent des opportunités financières, les regroupent et paient les Proposers pour les inclure.

Cycle de vie d'une transaction avant Flashbots (1:15)

Comment l'utilisateur obtient-il sa transaction et la communique-t-il au proposer à l'aide d'un réseau pair-à-pair ?

• Alice envoie une transaction à un pair.
• En 1-2 secondes, tous les pairs du réseau obtiennent une copie de cette transaction, y compris les proposers.
• Ils prendront cette transaction et l'incluront avec un peu de chance dans leur bloc

Problème : c'est une forêt sombre. N'importe qui pourrait s'y trouver, y compris un Searcher, ils pourraient donc repérer la transaction de l'utilisateur, l'inspecter, trouver une opportunité de MEV et la devancer pour voler le profit. Cela conduit à des "enchères de gaz prioritaires (ou Priority Gas Auctions dites "PGAs")", où les chercheurs surenchérissent les uns sur les autres.

Nous pouvons voir ici dans le graphique qu'en dix secondes, il y a globalement des centaines de transactions envoyées. Il y a 2 problèmes à ce sujet :

• Les enchères de gaz prioritaires génèrent beaucoup de gaspillage, car il y a beaucoup de transactions échouées.
• Il n'y a aucun cadre à la MEV. Nous prenons la transaction de l'utilisateur, et nous la jetons aux loups en espérant qu'elle arrive à destination

Cycle de vie d'une transaction après Flashbots (3:30)

Flashbots est venu comme une solution pour poser un cadre à la MEV en permettant aux utilisateurs d'envoyer des transactions directement à Flashbots, qui les donnait directement au Proposers au lieu de passer par le réseau peer-to-peer.

Qu'en déduire de ce scénario ? (4:00)

• La politique d'ordonnancement : nous choisissons les transactions en fonction des frais, les plus élevés d'abord, et environ 12 secondes pour le faire.
• Communication : Comment le proposer de bloc apprend-il la transaction et comment les chercheurs le trouvent-ils également ?
• Expérience utilisateur : Combien de temps faut-il à un utilisateur pour être informé que sa transaction est confirmée et comment elle a été exécutée ? (les utilisateurs méritent d'être informés car la MEV existe grâce à eux)

La MEV du Layer 2 (4:30)

Il y a trois acteurs dans le pays des rollups aussi :

1. Utilisateur honnête : Initie des transactions.
2. Séquenceur : Ordonne les transactions en attente pour inclusion dans un bloc de rollup.
3. Exécutant : Exécute les transactions.

Le séquenceur a tout à voir avec la MEV, car il décide de la liste des transactions et de leur ordonnancement. De plus, le cycle de vie est assez similaire.

Cycle de vie d'une transaction dans un séquenceur (5:15)

1. Le séquenceur a une liste de transactions en attente.
2. Ordonnancement des transactions selon les consignes en vigueur
3. Les publier sur Ethereum

Consignes d'ordonnancement du séquenceur

Admettons qu'Alice puisse communiquer directement avec le séquenceur. Quand Alice reçoit-elle une réponse du séquenceur et de quel type de réponse s'agit-il ?

Cela va dépendre de la façon dont le séquenceur décide de l'ordre de ces transactions, et ce qui nous intéresse, c'est la politique d'ordonnancement du séquenceur.

Highest Extraction First ou l'extraction la plus élevée d'abord (6:15)

Quand on parle de séquenceurs et de MEV dans les Layer 2, c'est la première politique d'ordonnancement dont tout le monde parle.

Un utilisateur peut se voir présenter des "transactions gratuites" car les récompenses MEV sont suffisantes. Mais si nous permettons au séquenceur d'extraire de la valeur pendant 2 ou 3 heures, et bien, ça craint pour l'utilisateur.

Selon Patrick, nous n'avons pas besoin de résoudre le problème de l'ordonnancement équitable pour l'instant. Il y a de très bonnes chances qu'un séquenceur puisse gagner plus d'argent en ayant un marché ouvert de Searchers et faire le travail difficile plutôt que d'essayer d'extraire le MEV eux-mêmes.

Highest fee first, ou les frais les plus élevés d'abord (9:15)

Cette politique est similaire au système actuel d'Ethereum :

1. Les séquenceurs reçoivent des listes de transactions en attente des Searchers
2. Les Searchers extraient le MEV et envoient des bundles au séquenceur avec paiement.
3. Le séquenceur ordonne les transactions en fonction des paiements reçus

Même expérience utilisateur que l'Highest Extraction First : les utilisateurs pourraient avoir des transactions gratuites car les frais de transaction sont déjà payés par le MEV extrait. Mais là encore, le délai pourrait être long

First Come First Serve "FCFS" ou Premier arrivé, premier servi (10:30)

Le FCFS cherche à prioriser l'expérience utilisateur :

1. L'utilisateur enverra sa transaction au séquenceur.
2. Le séquenceur horodatera la transaction.
3. La transaction est classée selon l'horodate.

D'une certaine manière, c'est comme faire une transaction sur Coinbase : nous envoyons notre transaction au fournisseur de services et ils nous renvoient une réponse pour dire qu'elle est confirmée.

Cependant, il est illusoire de penser qu'il n'y a pas de MEV sous cette politique :

Lorsqu'un utilisateur donne sa transaction, le séquenceur va créer un petit bloc en 250 millisecondes, puis publier cela sur un flux.

Maintenant, que se passe-t-il lorsque vous avez un flux de données qui publie l'état des transactions en temps réel ? Des Searchers sauvages apparaissent !

Quiconque obtient ces données de transaction en premier est celui qui gagne l'opportunité de MEV. Et cela conduit à la montée des jeux de latence parce qu'on se retrouve avec 150 000 connexions WebSocket (comme Arbitrum l'a vécu). Une solution à cela est le "hashcash", mais c'est une solution à court terme uniquement

FCFS + HFF, "le premier le plus offrant ?" (13:00)

Selon Patrick, une solution plus intéressante consiste à combiner le premier arrivé, premier servi et le Highest Fee First :

1. Les transactions des utilisateurs sont collectées par les séquenceurs qui les transmettent aux chercheurs dans des petits lots ou "batchs".
2. Les Searchers participent à une enchère en extrayant des réponses du lot qu'ils ont reçu et soumettent leur lot avec paiement au séquenceur.
3. Le séquenceur sélectionne le lot qui offre le paiement le plus élevé et le confirme.

Avantages :

• Confirmations rapides pour les transactions des utilisateurs (500 millisecondes).
• Les chercheurs ont un marché ouvert pour participer aux enchères, ce qui leur permet de trouver des extractions rentables dans des lots plus petits.
• Les séquenceurs peuvent décider quels types d'extraction sont autorisés ou non (front-running, transactions en arrière-plan, attaques sandwich, ou tout à la fois).

Tout ce qui est dit sur le FCFS + HFF est à prendre au conditionnel, car c'est encore un problème ouvert aujourd'hui.

Composantes d'une blockchain :

• L'"algorithme de sélection des leaders" est fondamentalement un algorithme qui vous indique qui est autorisé à produire réellement de nouveaux blocs. Après tout, les blockchains qui ne peuvent pas ajouter de nouveaux blocs ne servent à rien
• Le "mécanisme de résistance au Sybil" est le mécanisme de consensus (PoW, PoS...) pour empêcher le spam
• La "fonction de validité de bloc" définit les règles d'exécution d'un bloc
• La "règle de choix du fork" pour faire la distinction entre deux chaînes valides

La sélection des leaders et la règle de choix de fork sont liées à la MEV, car le leader peut capturer la MEV via l'arbitrage, le front running, etc. Et la règle de fork peut permettre des attaques temporelles liées à la MEV.

L'algorithme de sélection des leaders (3:00)

Dans une blockchain décentralisée, aucun leader unique ne peut arrêter la chaîne à lui seul. Cela empêche toute partie de détruire ou de contrôler la chaîne.

Les leaders sont généralement liés à un mécanisme de consensus comme la preuve de travail (PoW) ou la preuve d'enjeu (PoS) pour contrer les manipulations :

• En PoW, vous devez faire beaucoup de travail.
• En PoS, divers protocoles ont des leaders préassignés.

Choix du fork (5:00)

Il peut être plus facile de manipuler la règle de choix du fork que l'algorithme de sélection des leaders. Manipuler la règle de choix du fork pourrait permettre des attaques telles que le time-bandit (les mineurs réécrivent l'historique de la blockchain pour voler des fonds alloués par des smart contracts dans le passé).

Une fois qu'un attaquant a réorganisé la chaîne, il peut également s'engager dans le front running, l'arbitrage, etc. dans les blocs qu'il contrôle

Le monde modulaire (5:30)

Dans l'ensemble, le leader contrôle la chaîne et peut capturer le MEV, il est donc essentiel d'empêcher la manipulation de la sélection des leaders et des règles de choix du fork. Ces problèmes ne sont pas forcément aussi importants dans un contexte de Layer 1, mais ça devient un vrai problème dans un contexte modulaire car ces règles sont beaucoup plus flexibles

L'écosystème blockchain évolue vers un modèle avec de multiples chaînes et couches spécialisées qui interagissent. Cela inclut des couches de données (Celestia), et des couches d'exécution comme les Rollups (Abritrum, Optimisme, zkSync, Starknet) qui exécutent des transactions.

La différence entre les MEV (6:15)

La MEV Cross-chaîne dite "Horizontale" fait référence à la valeur extractible des opportunités d'arbitrage et de séquençage entre des environnements d'exécution séparés comme plusieurs Rollups.

La MEV Modulaire dite "Verticale" fait référence à la valeur extractible entre une couche d'exécution comme un Rollup et la couche de données sous-jacente sur laquelle elle s'appuie (c'est le sujet de cette discussion).

Contrairement à la MEV horizontale, il n'y a pas d'opportunité d'arbitrage directes entre une couche de données et une couche d'exécution. Cela soulève la question de savoir en quoi la MEV verticale est un problème

Première loi de la cryptodynamique : La MEV ne peut être ni ajoutée ni supprimée, elle peut seulement être déplacée d'une couche à l'autre. John Adler

Cette "loi" suggère que même si la MEV est traitée sur une couche, elle peut réapparaître sur une autre couche dans la blockchain modulaire

Considérations pour les algorithmes de sélection des leaders (8:30)

La MEV dans le Rollup doit rester sur le Rollup, et ne pas déborder sur la couche de données, car les validateurs de données seront incités à extraire la MEV qui atterrit dans leur champ d'action => centralisation.

Pour la décentralisation et la modularité, il vaut mieux que les opportunités de MEV soient cloisonnées plutôt qu'agrégées sur la couche de données de base.

Cela dit, aligner les incitations des rollups et de la couche de données est un problème ouvert aujourd'hui. Les rollups ont leurs propres incitations économiques qui peuvent se désaligner avec les intérêts à long terme de la couche de données.

Quelques exemples d'algorithmes de sélection des leaders (12:15)

Premier arrivé premier servi : Les participants enchérissent pour être les premiers à poster un blob de bloc pour devenir leader. Cela transforme la sélection des leaders en une enchère on-chain, mais apporte plusieurs problèmes comme la gouvernance ploutocratique, le débordement de la MEV vers la couche de données, et le gaspillage de l'espace des blocs puisqu'un seul blob compte.

L'approche Tendermint (Cosmos) : La rotation des leaders de Tendermint utilise l'état du Rollup, ce qui évite la dépendance à la couche de données. De plus, Tendermint peut être forké librement. Cependant, comme on peut attendre les blocs de la couche de données, il est difficile d'obtenir une bonne vivacité (liveness) et réactivité (responsiveness).

Highest Priority First ou Plus haute priorité d'abord : Cette idée nécessite que la couche de données prenne en charge les champs de priorité que les participants peuvent manipuler. Mais cela devient essentiellement un "premier arrivé, premier servi" avec l'enchère se déroulant off-chain, ce qui manque de transparence.

Based Rollups : Ils utilisent leur consensus et MEV-boost pour améliorer l'efficacité. Cependant, MEV-boost nécessite des hypothèses de confiance et le fonctionnement du Layer 1 nécessite des enchères, ce qui amène la MEV à déborder

Aller plus loin (16:45)

Une grande partie des réflexions et des propositions autour de la sélection des leaders des Rollups et de la MEV vertical proviennent de l'équipe Solana (Connor, Rutul, Evan, Callum, Gabriel)

Il s'agit d'un domaine de recherche actif avec un travail antérieur et des idées déjà publiées.

L'objectif de cette discussion est d'aborder une technique spécifique pour atténuer la MEV lors du transfert de tokens via un bridge

Comment ça marche

La communication cross-chain (0:15)

1. Lorsqu'un utilisateur souhaite transférer des actifs via le pont, la chaîne A crée un message représentant le transfert.
2. Les acteurs off-chain surveillent la chaîne A et récupèrent ce message de transfert.
3. Les acteurs off-chain livrent le message à la chaîne B.
4. La chaîne B valide que le message provient de la chaîne A et crédite le compte du destinataire.

La création du message sur la chaîne A et sa validation sur la chaîne B sont des opérations atomiques on-chain. Cependant, les étapes off-chain de récupération et de livraison du message ajoutent des délais allant de plusieurs dizaines de secondes à plusieurs minutes. Ces délais dans le processus de bridge cross-chain permettent des opportunités importantes de MEV.

La MEV est un accès anticipé à l'information (2:45)

Tout le monde a 10 minutes de prévention sur ce qu'un message fait et ce qu'il va faire lorsqu'il atteint la chaîne de destination. Ainsi, on peut savoir comment le devancer de la façon la plus efficace.

Donc la MEV pousse l'ordonnancement d'une blockchain vers l'ordre le plus extractible. Ce que nous voulons faire, c'est atténuer l'impact du réordonnancement et des attaques Sandwich sur les messages cross-chain parce que ces messages sont plus vulnérables que les transaction moyennse.

Atténuer le réordonnancement & le Sandwich

Lots de messages (4:15)

1. Au lieu de dispatcher immédiatement les messages cross-chain, on les accumule en lots. Plus précisément, on regroupe les messages qui concernent le même smart contract ou la même application.
2. Au lieu de faire de chaque message un engagement distinct, on s'engage sur l'ensemble du lot.
3. On diffuse le lot et on le traite en une unité sur la chaîne de réception.

En gardant les messages dans un lot, leur ordre relatif est fixé. Cela empêche le réordonnancement des messages au sein du lot pour exploiter la MEV, et nous supprimons la capacité de Sandwicher des transactions pour extraire la MEV.

Cela introduit généralement une latence, mais au final, on ne peut pas extraire la MEV aussi facilement.

Réordonner les lots à la réception (6:15)

Lorsqu'un lot atteint la chaîne de destination, nous pouvons le réorganiser on-chain. Par exemple, en utilisant une combinaison déterministe basé sur le hachage de bloc de la chaîne de réception.

Cette technique n'est pas totalement imprévisible, mais elle augmente toujours les coûts de manipulation de l'ordre du lot. Les Searchers pourraient essayer différentes combinaisons jusqu'à ce qu'ils obtiennent un ordre exploitable, mais cela demanderait de la puissance de calcul. En parlant de puissance de calcul, nous avons déjà un mot pour ça : preuve de travail (PoW).

L'extraction optimale est désormais un problème de Proof-of-Work

Donc le Searcher doit maintenant répéter de manière itérative une certaine fonction de hachage, puis essayer d'extraire ce blob et il doit le répéter de nombreuses fois, dans le but de trouver la meilleure combinaison.

Manipuler l'aléatoire équivaut à faire du Proof-of-Work. Cela augmente le coût de l'extraction.

Avantages et inconvénients (8:15)

En d'autres termes, nous augmentons les coûts. Mais ce n'est qu'une atténuation, pas une solution.

Cela ne fonctionne que si on a plusieurs messages et un nombre important qui touchent le même état. En outre, les noeuds veulent savoir que les messages sont reçus dans l'ordre dans lequel ils sont envoyés et cette propriété n'est pas préservée.

Ce qu'on n'a pas pu aborder (9:30)

La MEV Cross-chain est principalement statistique, car elle repose sur des patterns réalisés sur de nombreuses transactions au fil du temps.

La MEV cross-chain est une sorte de rayonnement fossile du cosmos, car elle est omnipotente et part dans toutes les directions

Discussion avec Jon Charbonneau (10:30)

Il y avait un débat pour savoir si les rollups sont définis par leur bridge vers le Layer 1 ou non. Selon James, les rollups incluent un bridge par définition, car ils en ont besoin pour être liés au Layer 1

Quand on y pense, les rollups se démarquent en raison de leur bridge natif. Cela les distingue des autres types de rollups, comme les rollups souverains qui n'ont pas de bridge natif. Les rollups sont une sous-classe de rollups souverains avec un bridge en plus (la terminologie a évolué à l'envers, c'est pour ça qu'elle est déroutante).

La question qui fait débat est de savoir si le bridge ou les nœuds déterminent l'état correct du rollup. James pense que les nœuds décident de l'état du rollup, et non le bridge :

• Les nœuds peuvent forcer le bridge à accepter n'importe quoi, mais pas l'inverse.
• Les nœuds décident de l'état du rollup, le bridge ne peut pas forcer de blocs non-valides sur les nœuds.

La MEV, c'est quoi ? (1:00)

Le MEV découle de la liberté des Proposers de bloc d'ordonner les transactions d'une manière qui les avantage. Cette liberté existe malgré les contraintes du protocole de consensus.

Cette liberté donne lieu à des marchés ainsi qu'à des externalités négatives. Des marchés émergent autour de la fourniture de services relatifs à la MEV et du paiement pour organiser les transactions. Cependant, des pratiques comme le front-running sont des externalités négatives - elles imposent des coûts aux utilisateurs et dégradent l'équité du système.

Certains systèmes sont plus faciles à extraire que d'autres :

• En PoW, les mineurs peuvent réorganiser plus librement les blocs pour maximiser les bénéfices.
• En PoS, des mécanismes comme les dépôts bloqués et le slashing dissuadent ces pratiques. Les validateurs risquent de perdre leurs dépôts s'ils s'écartent des règles de consensus.
• Le Single-Slot Finality (SSF) dans les chaînes PoS comme Ethereum aide à atténuer la MEV en finalisant rapidement les blocs.

Le staking/slashing programmable pourrait permettre aux Proposers de s'engager sur des règles anti-MEV supplémentaires. Par conséquent, des nouveaux concepts de staking/slashing permettent des mécanismes intéressants pour gérer la MEV.

Le Restaking, c'est quoi ? (3:30)

Le restaking permet aux validateurs Ethereum de prendre des engagements supplémentaires avec leur stake, et cela a été introduit par EigenLayer, qui est un protocole de restaking permettantt aux validateurs de définir des informations d'identification de retrait et d'opter pour de nouveaux engagements :

• Exécution de middlewares : Les validateurs peuvent s'engager à exécuter des protocoles middleware spécifiques qui ont probablement leurs propres incitations et sanctions
• Préférences d'ordre des transactions : Les validateurs peuvent s'engager à suivre certains ordonnancements des transactions, par exemple des schémas anti-MEV qui limitent la MEV toxique
• Sécurisation de nouveaux services : Au-delà de la simple sécurisation d' Ethereum, les validateurs peuvent engager leur stake pour sécuriser d'autres services / blockchains

On l'appelle "restaking" parce que les validateurs réutilisent leurs ETH stakés pour des engagements supplémentaires, pas seulement pour sécuriser la couche de base.

Cas d'utilisation

Activation basée sur des événements (5:30)

Certaines actions comme les liquidations dans un protocole de prêt ou les mints de NFT sont basées sur des événements qui se produisent sur la blockchain Ethereum.

Ces actions déclenchées par des événements se produisent actuellement off-chain par divers services comme Gelato, Keepers et Chainlink. Ils surveillent la chaîne, détectent les changements d'état et essaient de diffuser des transactions en réaction à ces événements. Toutefois, il n'existe pas de lien direct entre la surveillance on-chain et les Proposers qui pourraient inclure les transactions souhaitées.

Avec Eigenlayer, les validateurs s'engageant dans des services d'événements peuvent être obligés d'inclure des transactions répondant à des événements. Si l'événement se produit, le validateur doit inclure la transaction associée ou se faire slasher.

Partial Block Auction ou Enchères de bloc partiel  (8:30)

Les enchères de blocs partiels permettent aux constructeurs de blocs (builders) d'acheter uniquement une partie d'un bloc auprès des validateurs, plutôt que le bloc entier comme sur MEV-Boost.

Actuellement, l'intégralité du bloc est vendue pour empêcher les validateurs de modifier ou de censurer le contenu du bloc acheté, auquel ils sont cryptographiquement engagés à inclure.

Avec Eigenlayer, les validateurs peuvent s'engager à inclure une partie "builder" préfixée du bloc : le validateur conserve la liberté d'inclure n'importe quelle transaction dans le reste du bloc. Cela permet aux validateurs de vendre une partie du MEV aux constructeurs mais de tout de même inclure certaines de leurs propres transactions:

• Les validateurs peuvent exprimer plus d'influence en incluant des transactions choisies.
• Conserve la décentralisation de la construction de blocs entre les validateurs.
• Permet aux validateurs de capturer une partie de la MEV du bloc.

Cette approche équilibrée aligne les incitations entre les validateurs décentralisés et les constructeurs de blocs MEV professionnalisés.

Cryptographie à seuil (11:00)

Nous pouvons également utiliser le chiffrement à seuil avec le restaking d'EigenLayer :

• Les transactions peuvent être chiffrées via une cryptographie à seuil et divisées en fragments partagés entre les nœuds restakés.
• Les proposers de blocs s'engagent à n'inclure que la version déchiffrée des transactions chiffrées. Si la clé de déchiffrement est révélée, le proposer doit inclure les transactions déchiffrées. Sinon, ils peuvent être slashés
• Il y a une hypothèse d'honnêteté selon laquelle le groupe de détenteurs de clés révélera les clés. Si les clés ne sont pas révélées, les proposers peuvent gaspiller l'espace des blocs au lieu d'être réduits. Cela décourage le groupe de détenteurs de clés de retenir les clés

Blockspace Futures ou Contrats futurs sur l'espace de bloc (13:15)

Les Blockspace Futures permettent de réserver un espace de bloc futur auprès des validateurs :

1. Les transactions sont envoyées à une sidechain pour l'inclusion prioritaire.
2. Si une transaction est incluse sur la sidechain, les validateurs Eigenlayer doivent l'inclure dans un futur bloc Ethereum.
3. Les validateurs prennent des engagements pour honorer les transactions incluses dans la sidechain.

Cela garantit l'inclusion sur Ethereum pour les transactions prioritaires.

Risques (14:45)

Centralisation : La MEV a naturellement tendance à se centraliser. Toutefois, certaines solutions comme la protection des MEV par cryptographie à seuil, constituent un moyen de créer une décentralisation encouragée par le marché.

MEV Cross-chain : Bien que MEV-Boost++ réduise l'exigence de sophistication des proposers, l'existence de MEV cross-chain encourage la centralisation entre ces réseaux

Censure : "l'activation basée sur des événements" peut être utilisée pour acheter la censure de certains événements et donc des transactions. Toutefois, cela imposerait un coût élevé au censeur

Risques de centralisation (0:30)

Les protocoles de Restaking et de Liquid Staking sont actuellement confrontés à des risques de centralisation, car il y a un nombre limité d'opérateurs contrôlant les principaux protocoles :

• Pour le Liquid Staking, la majeure partie du marché est dominée par un petit nombre de plates-formes.
• Pour le restaking, il existe également le risque qu'un petit nombre d'acteurs sophistiqués en viennent à dominer les services de restaking si cela s'avère rentable. De fortes incitations pourraient motiver plus d'opérateurs à devenir des «restakers sophistiqués», pour réduire l'hétérogénéité.

Confiance économique VS Confiance décentralisée (2:00)

La confiance décentralisée nécessite à la fois des incitations financières / économiques suffisantes et une véritable décentralisation entre les nœuds. Ne compter que sur l'un des deux est dangereux.

Certains services comme la souscription financière ne nécessitent que les incitations économiques des actifs engagés pour la sécurité. Mais d'autres ont besoin de décentralisation pour la résistance à la censure, le partage de secrets, la cryptographie à seuil, etc.

Décentralisation des fournisseurs de Liquid Staking (4:30)

Il existe des compromis inhérents entre la décentralisation des opérateurs et la scalabilité du protocole. Les fournisseurs entièrement décentralisés comme Rocket Pool sacrifient une certaine scalabilité tandis que les fournisseurs plus centralisés comme Lido atteignent une plus grande échelle.

Une décentralisation complète pourrait être irréalisable, mais des améliorations peuvent être apportées grâce à des solutions techniques ou des protocoles :

• Systèmes de réputation : suivre et quantifier la réputation des opérateurs sur la base de métriques telles que la disponibilité, les performances, la gestion des fonds.
• Delayed Deposit Threshold (DDT) ou "Seuil de dépôt différé" pour limiter les risques des nouveaux opérateurs / non éprouvés.
• Staking Routers : acheminer les fonds engagés via un protocole de routage décentralisé pour attribuer des opérateurs (Lido)
• Distributed Validator technology (DVT) ou "Technologie de Validateur Distribué" : répartir le travail de validation sur différents nœuds.

Le modèle de routeur de staking Lido peut représenter l'objectif final pour atteindre à la fois une décentralisation suffisante des opérateurs tout en conservant la scalabilité du protocole.

Les écosystèmes modulaires n'aident pas (9:00)

Nous passons déjà à ce type d'écosystème extrêmement complexe de blockchains et nous allons inévitablement devoir résoudre des problèmes d'allocation pour tous les participants des réseaux.

Partant de là, Tarun pense que la définition du collatéral va changer au fil du temps, en particulier si beaucoup d'opérateurs de nœuds Lido font du restaking pour des services de séquençage à destination des Rollups

Séquençage des transactions (10:45)

Les rôles de séquençage de base comme l'ordonnancement des transactions et la disponibilité des données peuvent être conçus pour être stateless, il s'agit simplement d'ordonner les transactions dans les blocs.

Cependant, les fortes demandes de bande passante observées par les premiers séquenceurs soulèvent des inquiétudes quant à savoir si les exigences en infrastructure diffèrent substantiellement d'une blockchain comme Solana.

L'absence d'enchères MEV sur les séquenceurs partagés jusqu'à présent exacerbe les problèmes de bande passante

Dans l'ensemble, la relation entre les flux de valeur de staking et les incitations à staker à différents rôles affecte profondément les risques de centralisation.

Rewards (15:00)

La centralisation du staking vers les protocoles de restaking peut se produire même si les récompenses de restaking ne sont que légèrement supérieures aux récompenses de staking Ethereum, comme nous l'avons vu avec l'adoption de MEV-Boost. Les rendements n'ont pas nécessairement besoin d'être très élevés.

Inciter de manière algorithmique les nœuds et comités décentralisés avec des récompenses plus élevées est une option pour contrer les effets de centralisation, mais identifier algorithmiquement la décentralisation est un défi :

• Les oracles de décentralisation peuvent aider à orienter les opérateurs de nœuds vers des services ayant des besoins spécifiques de décentralisation.
• Les protocoles d'élection de leader secrets peuvent aider à sélectionner des nœuds décentralisés de manière anonyme, mais il faut d'abord une base de décentralisation. La distribution de l'état doit être uniforme sur les identités uniques, pour que l'élection ait un sens.
• La cryptographie à seuil pour l'élection de comité décentralisé est une direction de recherche inexplorée mais prometteuse pour l'avenir.

Il est plus prudent d'attendre la maturité de ces technologies naissantes avant de les intégrer dans des systèmes critique comme Ethereum et son staking.

Effets de levier (27:00)

Dans l'ensemble, l'effet de levier est un facteur externe que les protocoles doivent prendre en compte :

• Nous pouvons considérer le "levier" créé par le restaking comme un modèle d'assurance de type "tranche".
• Les tokens de staking liquide (LST) comportent déjà un effet de levier implicite puisqu'ils sont utilisés comme garantie dans les protocole de liquidité pour emprunter d'autres actifs.
• Même en preuve de travail, les fermes minières sont très endettées, empruntant contre leurs machines ASIC pour acheter davantage de matériel pour miner

Les protocoles ne peuvent pas contrôler l'effet de levier que les utilisateurs prennent de manière externe, donc des marges de sécurité sont essentielles dans la conception.

Certains espaces de conception restent pour l'innovation après les premières percées du Liquid Staking comme les routeurs de staking et les seuils de dépôt différés.

Séquenceurs partagés (33:45)

Les séquenceurs partagés capturent la MEV qui reviendrait normalement aux séquenceurs propres aux rollups, les rollups perdent donc ce bénéfice en adoptant le séquençage partagé. Il faut un réalignement des incitations pour que les rollups utilisent le séquençage partagé s'ils perdent leur MEV native.

Le séquençage partagé devrait théoriquement créer une MEV interopérable supplémentaire qui n'existe pas aujourd'hui. La clé est d'avoir des rapports transparents sur la contribution marginale de chaque Rollup individuel à la MEV totale générée par le séquenceur partagé.

Une autre option est d'estimer la MEV en solo contrefactuelle que les rollups pourraient générer par eux-mêmes, et d'incorporer cela dans les frais. Laisser tomber les rollups au hasard pour mesurer l'impact sur la MEV peut aider à estimer la MEV marginale.

Les enchères cognitoires sont possibles mais probablement trop coûteuses en pratique pour une adoption généralisée.

Rollups x Eigenlayer (39:45)

Permettre aux rollups de changer de séquenceurs sur une base par bloc introduit une concurrence entre les séquenceurs pour enchérir les revenus MEV versés aux rollups. Cette concurrence constante pourrait aider à aligner les incitations, bien que la viabilité doive être évaluée.

Rendre les protocoles conscients des événements de slashing externes, comme Ethereum avec Eigenlayer, sera bientôt possible grâce à des mises à jour comme les retraits déclenchés par smart contract. Cela améliore la sécurité.

Une voie prudente semble être de permettre l'expérimentation sur des protocoles de surcouche opt-in (Layer 2 ?) dans un premier temps, avant une adoption formelle sur Ethereum

Intro

L'idée d'utiliser des concepts de la théorie du choix social pour rendre les blockchains plus équitables grâce à l'ordonnancement des transactions est intéressante, mais il y a des problèmes dans la façon dont cela a été mis en œuvre jusqu'à présent :

• Les mécanismes d'ordonnancement équitable garantissent certains modèles mais n'analysent pas l'économie ou les coûts.
• On ne sait pas si le travail supplémentaire requis par les validateurs pour appliquer le classement équitable a une valeur économique ou s'il est préjudiciable.

L'objectif principal est d'approfondir l'économie du classement équitable pour voir s'il y a une valeur nette réelle, étant donné les coûts et les compromis. Tarun veut simplement souligner les problèmes, pas attaquer les travaux antérieurs.

Qu'est-ce que le "Fair Ordering" ou classement équitable ? (1:45)

Le théorème d'impossibilité de Kenneth Arrow prouve que l'équité parfaite est inaccessible dans les systèmes de vote classés, qui sont analogues aux validateurs qui ordonnent les transactions.

Les algorithmes de classement équitable tentent d'approximer les votes majoritaires, mais ne peuvent pas échapper complètement aux limitations comme la centralisation et les "dictatures" où un validateur a trop d'influence.

Le problème se cache dans les définitions d'équité. Ces définitions décrivent les propriétés des ordres de transaction partiels résultant du classement équitable. Cependant, ils ne quantifient pas la valeur économique ou la rente extraite par ordre partiel, alors que la MEV est purement un profit économique.

Le classement équitable est un mensonge (3:30)

Themis, Acquitus et Quick Block Ordering ont affirmé que le classement équitable élimine la MEV. Les intentions sont bonnes, mais nous sommes confrontés à plusieurs problèmes :

• Il n'est pas logique d'être agnostique à toutes les applications alors que certaines génèrent du MEV régulier (AMM) et d'autres génèrent du MEV en pointe (liquidations).
• Le classement équitable n'est pas universellement applicable à toutes les applications. Parce que les profils MEV diffèrent selon les applications, ce qui améliore l'équité pour une application peut nuire à une autre.
• Il peut être préjudiciable d'obliger les validateurs à faire un travail supplémentaire sans retombées économiques.

De plus, d'autres domaines comme la théorie de la décision et l'IA obtiennent des résultats d'impossibilité lors de l'étude de l'équité de l'ordre pour des objectifs comme la qualité du modèle. On devrait s'attendre à la même chose pour l'impact du classement équitable sur l'objectif de la valeur économique de la MEV.

Comment casser le classement équitable

Étant donné les problèmes ci-dessus, nous allons maintenant plonger dans les détails de pourquoi le classement équitable est fondamentalement problématique

Théorie des jeux (6:00)

Considérons un jeu à deux joueurs :

1. Le protocole de classement équitable qui contraint les ordonnancements de transaction
2. Un développeur DeFi adversaire essayant de concevoir un protocole qui exploite le classement équitable

En suivant les mécaniques de jeu (décrite sur l'image ci-dessus), nous analysons ce jeu à l'aide d'une fonction de perte min-max qui vise à mesurer l'équité. Le choix de la fonction de perte affecte les notions d'équité.

• Si la valeur du jeu est positive, le développeur a pu exploiter le classement équitable.
• Si négatif, le classement équitable a limité l'exploitation.

Plus l'ensemble des ordonnancements autorisés est contraint, plus le protocole de classement équitable a le pouvoir de gagner.

Pourquoi ce jeu représente-t-il les protocoles de classement équitable ? (8:45)

Les protocoles de classement équitable autorisent un large ensemble d'ordonnancements de transaction, ce qui facilite pour les développeurs adverses de trouver des moyens d'exploiter le protocole. D'un autre côté, restreindre l'ensemble peut limiter l'exploitation.

Les contraintes combinatoires de l'ensemble d'ordonnancements autorisé bornent la valeur du jeu

Comment ce jeu casse le classement équitable ? (9:30)

En supposant qu'il y ait suffisamment de randomisation dans les ordonnancements, des fonctions de paiement adversaires peuvent être construites pour exploiter le classement équitable.

Un protocole DeFi avec des règles de liquidation ayant de mauvaises performances sur les permutations autorisées par le classement équitable prouve que le classement équitable favorise implicitement certaines applications par rapport à d'autres.

Et favoriser certaines applications, c'est, et bien...pas équitable.

Le compromis qui discrimine (12:15)

Plus l'ensemble des ordonnancements autorisés est contraint, moins les développeurs adverses ont de flexibilité pour construire des fonctions de paiement qui exploitent certains ordonnancements.

Cependant, restreindre excessivement les ordonnancements rend difficile pour les protocoles de classement équitable de s'adapter à l'aléa résultant de choses comme la latence réseau. Cela peut aller à l'encontre des hypothèses et conduire à des conséquences imprévues.

Ces contraintes créent un compromis entre la taille de l'ensemble et la manipulabilité. Rétrécir l'ensemble réduit la manipulation mais rend le protocole trop rigide. D'autre part, élargir l'ensemble augmente l'adaptabilité mais permet plus de manipulation.

Si le protocole de classement équitable autorise un ensemble d'ordonnancements suffisamment large, la valeur min-max du jeu est positive, ce qui signifie que le protocole DeFi adversaire se comporte moins bien. Par conséquent, le classement équitable est discriminatoire.

Soyons optimiste (16:30)

Plutôt qu'une approche universelle, des préférences d'ordre adaptées à des applications spécifiques pourraient être plus efficaces, pour 2 raisons :

1. Une recherche a examiné l'ordonnancement premier arrivé, premier servi (à l'instar Arbitrum) uniquement pour la transaction principale et a formellement prouvé qu'il est toujours sous-optimal par rapport au meilleur ordonnancement.
2. La manipulation minimale possible dépend de la complexité de la fonction de paiement. En d'autres termes, des smart contracts plus simples peuvent être plus équitables.

Au lieu de rechercher une équité universelle parfaite, nous pouvons analyser des politiques spécifiques simples ou simplifier les smart contracts.

Vue d'ensemble (1:30)

La plupart des recherches sur la MEV se sont concentrées sur le système actuel où les utilisateurs signent des transactions qui sont diffusées dans le mempool public.

Cependant, il y a des signes que ce modèle évolue, avec plus de transactions passant par des mempools privés. Une analyse de BlockNative a montré que 3,8% des transactions n'atteignent pas le mempool public et le pourcentage est probablement en hausse aujourd'hui

La MEV standard repose sur les Searchers voyant les transactions dans le mempool public, mais l'utilisation en hausse des mempools privés signifient que les Searchers ne peuvent pas accéder à ces données de transaction. Donc les hypothèses sur le fonctionnement de la MEV deviennent obsolètes.

Les chercheurs ont proposé de meilleures conceptions d'enchères de MEV pour rendre les choses plus équitables, mais ces conceptions ne fonctionnent que si les transactions sont publiques. Si nous n'avons pas d'incitations pour encourager les gens à participer aux enchères, elles finissent par être gaspillées.

La plupart des discussions se contentent de se plaindre que la privatisation du flux d'ordres (Order Flow) est néfaste, car elle conduit à la centralisation de la construction de blocs dominée par quelques grands acteurs et qui crée un effet de boule de neige (décrit ci-dessus)

Mais au lieu de critiquer, nous devons comprendre pourquoi et comment le flux d'ordres privatisé est réalisé. À partir de là, nous pouvons entrevoir des solutions pour créer des incitations à la participation décentralisée

La chaîne d'approvisionnement de la MEV (3:30)

La chaîne d'approvisionnement MEV standard est Utilisateur -> Wallet (portefeuille) -> Searcher (chercheur de bloc) -> Builder (constructeur de bloc) -> validateur, mais cette vue est trop simpliste. L'étape du Wallet au Searcher est là où il y a le plus de pouvoir de négociation et de levier.

Être plus en amont de la chaîne d'approvisionnement confère plus de pouvoir. Par exemple, les Wallets ont un pouvoir de négociation sur les Searchers en termes de transactions qui sont envoyées.

Voici comment les transactions sont formées :

1. L'Interface Utilisateur (Dapp UI) envoie une demande de signature au Wallet
2. Le Wallet demande à l'utilisateur (User) de signer
3. L'utilisateur envoie la transaction signée au Wallet
4. Le Wallet envoie la transaction à un point de terminaison RPC (RPC Endpoint)
5. La transaction entre dans le mempool public

À qui appartient ce putain de flux d'ordres ?

Tous les acteurs participants au cycle de vie d'une transaction veulent capturer plus de flux d'ordre pour eux-mêmes. Et ce flux a commencé à se désagréger à cause de ça.

Dans cette partie, on va faire un état des lieux des arguments avancés par chacun des acteurs qui revendiquent le flux d'ordre

Fournisseurs de RPC (5:15)

La perception commune est que les fournisseurs RPC contrôlent le flux d'ordre, mais les RPC personnalisés font face à des défis :

• La construction de RPC personnalisés fixe des barrières à l'entrée difficiles pour les nouveaux projets
• De nombreux Wallets ne permettent pas de changer facilement le fournisseur RPC par défaut
• On ne sait pas clairement comment les fournisseurs RPC personnalisés peuvent monétiser leurs services ou être payés

Une option serait les RPC axés sur la sécurité : ils peuvent fournir une sécurité supplémentaire par rapport à simplement diffuser des transactions dans le mempool public, intercepter et scanner chaque transaction pour les risques (Harpie) et offrir des options comme l'authentification à 2 facteurs (2FA) pour les transactions à haut risque.

Une autre option serait les RPC axés sur l'expérience utilisateur : ils améliorent la facilité d'utilisation par rapport aux fournisseurs existants (Infura, RPC publics...). Par exemple, ils peuvent optimiser les frais de gaz, éviter les transactions ratées ou attendre le juste prix sur un swap.

Les deux options devraient être supérieures aux RPC existants, mais il est difficile d'amener les utilisateurs à changer de fournisseurs RPC par défaut. Donc, au lieu d'avoir les utilisateurs qui basculent leur RPC, nous pouvons vendre directement leurs services aux Wallets :

• Les Wallets ont plus de pouvoir et d'options de monétisation
• Peuvent externaliser l'extraction de MEV à d'autres acteurs
• Les utilisateurs peuvent obtenir une part de MEV, améliorant la rétention du Wallet
• Ca créé un nouveau flux de revenus pour les Wallets au-delà des frais d'échange

Wallets (9:00)

Les Wallets ont beaucoup de pouvoir : ils contrôlent où les transactions signées sont envoyées, et ils décident quels RPC ont accès au flux d'ordre. De plus, ils doivent trouver des sources de revenus alternatives (tous les Wallets ne peuvent pas avoir de Metamask Swap)

Le flux d'ordre est une source de revenus pertinente, car tout le flux d'ordre n'est pas créé égal. Le flux d'ordre des bots / arbitrages contient peu de MEV, mais les utilisateurs moins sensibles au prix génèrent plus de MEV.

En ce sens, Metamask est en train d'assimiler les fournisseurs RPC et d'avoir leur propre couche per-dessus ces derniers, où ils peuvent à nouveau fournir bon nombre de ces avantages de sécurité et d'UX mais aussi potentiellement extraire la MEV.

Problème : avoir notre propre couche par-dessus des fournisseurs RPC est centralisé. La question est, quel est l'intérêt pour les Wallets d'externaliser l'extraction de MEV au lieu de la garder pour eux-mêmes ? Spoiler : nous n'avons pas besoin de réponses pour l'instant.

Les frais d'échange internes au Wallet (comme Metamask Swap) sont plus lucratifs que l'extraction de MEV pour l'instant, donc la monétisation de la MEV n'est pas un problème prioritaire. Ce talk suppose que les utilisateurs envoient des transactions au Wallet et que le Wallet contrôle le flux... Pour l'instant.

Dapps ou "Applications décentralisées" (11:45)

Les Dapps peuvent initier la signature sans transaction de Wallet. L'utilisateur signe un hachage représentant l'intention, qui n'est pas une transaction réelle. Un exemple est Sushi avec "Sushi Guard", où l'utilisateur signe l'intention et Sushi Guard extrait le MEV. Donc le Wallet ne voit pas cette transaction dans ce flux et donc les fournisseurs RPC ne voient même pas cette transaction.

Selon Tom, ce n'est pas optimal :

• Un message peut, dans certaines conditions, être malveillant. Il est risqué pour les utilisateurs de signer des choses qu'ils ne comprennent pas.
• On a peu de contrôle sur les transactions si la majorité du volume passe par un tiers (agrégateur, bot...).

Points à retenir (14:15)

• L'amont de la chaîne d'approvisionnement (plus précisément la partie Wallet) a plus de pouvoir, c'est pourquoi tous les acteurs essaient de remonter la chaîne pour atteindre cette partie. Les acteurs se comportent de manière rationnelle, pas malveillante.
• Les systèmes de MEV actuels supposent que les transactions sont publiques, mais cette hypothèse est de moins en moins correcte.
• Les premières données suggèrent que les mempools privés sont un problème croissant.
• Nous ne voulons pas vraiment d'un monde où des entités centralisées contrôlent davantage le chaîne d'approvisionnement de la MEV (MetaMask fait de l'auto-extraction avec les swaps + devient constructeur de blocs).
• Nous avons besoin de rendre les enchères MEV ouvertes/équitables pour éviter les pools privées centralisées, mais nous ne pouvons pas compter sur le bénévolat.
• Davantage de recherches sont nécessaires pour quantifier les problèmes de mempool public vs privé (nous sommes dans une position similaire à l'ère Pre-MEV Explorer).

Questions ouvertes

• Quelle est la véritable destination de la MEV extraite (Users, Wallets, Builders) ?
• Existe-t-il des incitations pour que les acteurs fournissent un flux d'ordre ouvert ?
• La concurrence mènerait-elle au partage du MEV avec les utilisateurs ?

Intro

Une "enchère" peut être définie plus largement que la simple découverte de prix. Elle peut être un mécanisme pour découvrir la meilleure façon d'interagir avec les blockchains par la concurrence sur d'autres dimensions que le prix.

Quintus veut donner un aperçu et une direction pour explorer un espace de conception d'enchères plus large que ce dont les gens discutent habituellement

Auctions ou "enchères" (1:40)

Les enchères inversées sont un exemple où les participants font concurrence sur des dimensions comme la vitesse ou la fiabilité plutôt que le prix. Les enchères sont utiles ici parce que nous ne connaissons pas le meilleur moyen d'atteindre les objectifs des utilisateurs.

L'état final idéal serait d'avoir un mécanisme d'enchère entre les utilisateurs et les blockchains qui aide les utilisateurs à atteindre leurs objectifs de manière optimisée.

Dans cette discussion, nous ne parlerons pas de l'ensemble du système MEV, mais nous concentrerons sur les Order Flow Auctions spécifiquement (le rectangle vert sur le schéma)

Taxonomie (3:15)

• Les enchères scellées déterminent le gagnant à l'avance, elles ressemblent aux méthodes de la finance traditionnelle
• Les maisons de vente aux enchères ont des variantes où les gens enchérissent sur des articles individuels. Les articles sont assimilables aux transactions que les utilisateurs souhaitent réaliser on-chain (les enchères combinatoires permettent d'enchérir sur des sous-ensembles d'articles)
• Les enchères par lots sont similaires aux enchères combinatoires mais la composition du lot est fixe
• Les enchères néerlandaises impliquent des enchères dans le temps

Cette taxonomie montre certains espaces de conception existants, mais il manque une dimension intéressante : le contrôle du flux d'informations et de la confidentialité au cours de l'enchère. Quintus pense que le contrôle du flux d'informations et de la confidentialité ouvre de nouvelles possibilités.

L'autre chat de Schrödinger

Comme ça marche (6:00)

Faisons une expérience de pensée impliquant le "chat de Schrödinger" comme commissaire-priseur contrôlant le flux d'informations :

• Le chat contrôle toutes les actions à l'intérieur de sa "boîte" et contrôle crucialement les informations qui peuvent traverser les frontières de la boîte.
• Le chat autorise également des agents/bots enchérisseurs à l'intérieur de la boîte mais pas nécessairement les enchérisseurs eux-mêmes. Cela limite le flux d'informations.

Si la boîte est totalement transparente, alors tous les enchérisseurs connaissent tous les détails de l'enchère, mais cela peut ne pas être souhaitable. Heureusement, d'autres options existent pour limiter les fuites d'informations.

• Seul le gagnant connaît les détails
• Personne ne sait jusqu'à nouvel ordre

Exemple concret : une enchère sur les infos d'une grosse transaction. Le but des enchérisseurs est de connaître ces infos pour en tirer parti

• Si totalement transparent, les concurrents peuvent devancer l'exécution de la transaction puisqu'ils connaissent les détails. Cela augmente les coûts d'exécution.
• Si seul le gagnant sait, l'exécution est plus favorable car ça limite les fuites d'informations

Cela pourrait être un cas d'utilisation intéressant pour les oracles. Quelques exemples :

• Tous les enchérisseurs sont au courant d'une mise à jour de l'oracle, mais seul le gagnant obtient l'information
• Vente d'un accès anticipé aux mises à jour de l'oracle avant qu'elles ne soient publiques.

Les enchérisseurs ont intérêt à enchérir davantage pour cette mise à jour, car cela leur donne une longueur d'avance sur le marché.

Récap (11:25)

• Les conceptions d'enchères peuvent sélectionner la concurrence qui augmente les revenus, tout en limitant les impacts néfastes comme le front-running qui nuisent aux utilisateurs.
• L'asymétrie de l'information peut être monétisée, par exemple les mises à jour des oracles (décrites ci-dessus)
• Le contrôle du flux d'informations permet de contrôler les actions, comme garder les détails sensibles privés pour éviter le front-running indésirable

L'exemple du "chat dans une boîte" illustre une façon de contrôler les informations, mais de nombreuses approches sont possibles en combinant la cryptographie, les systèmes distribués, etc. Le principe clé est de lier le contrôle de la disponibilité de l'information à l'activation ou à la limitation des actions.

Comment garantir l'accès à l'information sans qu'il y ait de fuite ? (13:15)

Les SGX fournissent une puissance de calcul confidentielle mais nécessite des hypothèses de confiance. Des alternatives comme le calcul multipartite existent, avec plusieurs parties exécutant ces SGX, ou les enchérisseurs eux-mêmes exécutant différentes instances.

Dans tous les cas, c'est un espace de conception ouvert. Comme il existe probablement des possibilités encore non découvertes dans la conception des enchères, il peut tout aussi bien y avoir de nouvelles approches du contrôle de l'information qui pourraient émerger.

À quoi ressemble les flux du partage de MEV ?
  L'entonnoir des d'appels d'offres MEV

La répartition des revenus de MEV en fonction des rôles
  Searchers
  Builders + Validateurs

À quel endroit de l'entonnoir pouvons-nous trouver, extraire et restituer les bénéfices de l'utilisateur ?
  Les profits on-chain des Searchers
  Surplus d'offre des validateurs

Order Flow Auctions (1:30)

1. Les utilisateurs initient des transactions via une application décentralisée, un Wallet ou un fournisseur RPC
2. Les services de MEV agissent comme des matchmakers entre les utilisateurs et les Searchers.
3. Les Searchers enchérissent sur les transactions des utilisateurs pour maximiser les profits, et envoient des bundles pour essayer de gagner (si aucun chercheur n'enchérit, retour au mempool)
4. Les Builders incluent les bundles des Searchers gagnants dans leurs blocs.
5. Les validateurs valident les blocs et reçoivent les paiements des Builders.

Qui prend quoi ? (2:30)

• Utilisateurs : Dans le modèle actuel, les utilisateurs ne reçoivent aucun revenu MEV directement. Mais à l'avenir, ils pourront peut-être demander une part des bénéfices.
• Services MEV : Ils agissent comme intermédiaires et peuvent prendre des frais à l'avenir comme revenu.
• Searchers : Ils obtiennent une part importante des bénéfices de la MEV, une partie on-chain et une partie inconnue/off-chain. C'est leur revenu principal.
• Builders : Peuvent conserver une partie des bénéfices MEV qui leur sont transmis par les Searchers. Le reste est distribué aux validateurs.
• Validateurs : Reçoivent le revenu MEV des Builders sous forme de paiements pour l'inclusion de leurs blocs. C'est actuellement leur principale source de revenu avec la MEV.
• Relais : Ne reçoivent pas de revenu MEV directement pour le moment.

Définir toute la valeur (3:30)

Il y a davantage de rôles qu'avant qui s'approprient une part de la MEV et cela peut potentiellement se scinder davantage. Maintenant que les Searchers sont séparés des Wallets/Builderss, nous passons par les Order Flow Auctions.

Dans le passé, les Searchers conservaient ~70% des revenus de MEV et les Validators/Builders recevaient ~30% des revenus de MEV.

Actuellement, les choses ont été inversées : les Builders et Validators reçoivent maintenant une plus grande part, environ 70% des revenus MEV et les Searchers reçoivent environ 30%.

Ce à quoi nous pouvons nous attendre à l'avenir :

• Les services de MEV peuvent fixer des frais pour la mise en relation des utilisateurs et des Searchers
• Les utilisateurs pourront peut-être demander un pourcentage spécifique des revenus de MEV
• Les Order Flow Auctions pourraient permettre aux utilisateurs de négocier un pourcentage plus élevé.
• La séparation entre les Searchers/Builders/Validateurs peut encore évoluer
• Plus le temps passe, plus il y a de parties prenantes qui s'attibuent une part des revenus de MEV

Répartition du revenu de MEV des rôles actuels

Disclaimer (5:30)

Nous ne pouvons voir que les bénéfices de MEV on-chain sur les DEX. Nous ne pouvons pas quantifier la MEV hors-chaîne sur les exchanges centralisés, et les échanges CEX-DEX sont d'un autre type de MEV.

La MEV totale est sous-estimée ici, car une grande partie de la MEV se produit off-chain et nous ne pouvons pas la quantifier.

Bénéfices on-chain des Searchers (6:00)

Les revenus de MEV on-chain attribués aux Searchers sont estimés entre 50 000 $ et 100 000 $ par jour.

Dans un flux normal, les Searchers transfèrent les bénéfices aux builders, et les Builders peuvent conserver certains bénéfices, puis transférer le reste aux validateurs. Mais il y a des exceptions qui rendent l'analyse difficile :

• Certains Builders ne tirent aucun bénéfice
• Des Searchers contournent les Builders
• Des validateurs se définissent directement comme bénéficiaires des frais

Revenus des Proposers (8:30)

Étant donné qu'il est difficile de quantifier la répartition constructeur/validateur, nous regardons le revenu combiné, et le revenu quotidien total des Proposers a augmenté de 600 000 $/jour fin 2022 à 1 M$/jour début 2023.

Depuis le début de l'année, la répartition de la MEV a grandement changé en faveur des Builders & Proposers, et au détriment des Searchers

Où peut se faire l'extraction ?

L'entonnoir de la MEV (10:15)

En regardant à nouveau le flux, lorsque l'Order Flow Auction prend l'information d'ordonnancement de l'application ou des utilisateurs, ils pourront potentiellement savoir combien l'utilisateur a déjà demandé ou souhaite partager. Ainsi, les Searchers voyant les demandes des utilisateurs, peuvent offrir un %age élevé en remerciement pour un flux d'ordre exclusif.

Les données de MEV-Boost data permettent d'extraire le montant de l'enchère excédentaire applicable :

1. Peut calculer le "surplus d'enchère" entre la 1ère et la 2ème offre la plus élevée
2. Déduire le surplus laisse toujours l'offre la plus élevée, les validateurs doivent la prendre
3. Donc le surplus pourrait être extrait pour le partage des revenus des utilisateurs

Bénéfices on-chain des Searchers (12:30)

La première approche consiste à regarder les bénéfices des Searchers provenant des transactions MEV en %age du volume total des transactions, et à quantifier la rentabilité par transaction MEV :

• La marge bénéficiaire médiane est d'environ 3 bps (0.03%)
• La plupart des transactions ont une marge de 0-5 bps
• Le 95ème centile (top 5%) des transactions atteint des marges bénéficiaires de plusieurs centaines de pbs
• Le 99ème centile (top 1%) des transactions a une marge d'environ 1000 pbs

Les estimations d'EigenPhi sont probablement des limites supérieures. Les montants réels sont probablement inférieurs dans la réalité, car les transactions ne sont pas tous rentables.

Le "surplus" d'enchère de bloc (15:15)

La deuxième approche consiste à analyser le surplus d'enchère de bloc. La différence entre la plus haute offre et la 2ème plus haute offre comme décrit précédemment est considérée comme un surplus d'enchère :

Méthodologie

• Obtenir la dernière offre de chaque constructeur
• Prendre les 2 meilleures offres
• Le surplus est la différence entre elles

Chiffres cohérents

• ~$5 de surplus par bloc
• ~$25k de surplus par jour
• ~2 ETH sur 1000 blocs

En conséquence, le surplus est de 2 à 5 % de l'offre totale la plus élevée. Sur la base des parts de marché :

• 5% de part de marché sur un DEX donne $37 500 de surplus
• 50% de part de marché sur un DEX donne $375 000 de surplus

Ces estimations sont des limites inférieures, car seule la partie applicable est prise en compte.

On refait le portrait (18:30)

• Nous avons vu que la part des validateurs/Builders est passée de 30% à 70%
• La part des revenus Builders/Proposers n'est pas claire (marquée x%? en rouge)
• Une partie des bénéfices on-chain des Searchers peut être partagée via la conception Order Flow Auction, nous savons que les utilisateurs peuvent déjà spécifier le %age qu'ils veulent redonner (marqué x% en vert)
• Le revenu on-chain total est estimé à $1,4M quotidien et $42M mensuel (limite supérieure)

Les Oder Flow Auctions peuvent déplacer les parts de MEV on-chain vers l'Off-chain. Du point de vue de l'utilisateur, c'est notre MEV. Nous voulons obtenir un pourcentage en retour car nous sommes à l'origine des revenus de MEV.

Les validateurs peuvent gagner des revenus de diverses sources (staking, prêt, MEV, dérivés) et considérer les revenus de ces sources comme un portefolio à optimiser. En conséquence, les différentes sources de revenus sont en concurrence pour l'allocation dans le portfolio du validateur.

Mais le staking est spécial. Il a le double objectif de fournir des revenus et de sécuriser le réseau. Il a un statut privilégié qui le distingue des revenus du prêt, des dérivés, etc. qui ne contribuent pas directement à la sécurité du réseau. Cela soulève plusieurs questions :

• Pouvons-nous utiliser la MEV comme incitation pour améliorer la sécurité de la chaîne ?
• La MEV peut-elle agir comme une sorte de levier économique pour inciter à la sécurité ?
• Peut-elle être utilisée comme un moyen d'amener les validateurs à éviter certains mauvais équilibres économiques qui pourraient survenir ?

Ce sont les questions auxquelles nous essaieront de répondre

Les protocoles Proof-of-Stake (3:00)

Cette formule explique comment l'offre évolue au fil du temps : prenez l'offre à la dernière étape de temps, ajoutez l'inflation, puis ajoutez ou soustrayez la liquidité détenue ou brûlée par le protocole.

D'un point de vue mathématique, le validateur considère cela comme un problème d'optimisation de portfolio, qui est fondamentalement un ratio Bénéfices/Risques

Perspective d'optimisation de portfolio (4:00)

Pour optimiser leur portfolio, les validateurs vont examiner les sources de revenus auxquelles ils peuvent accéder, et ils vont calculer un rendement moyen pour chacune de ces sources.

Bien sûr, cela pourrait inclure d'autres choses comme des dérivés s'ils s'engagent dans ces actifs en fonction de leur ratio Bénéfices/Risques

Il s'agit d'un problème d'optimisation qui peut être résolu avec de bonnes estimations des Rendements et des Risques.

Dynamiques Staking-Lending (5:00)

• Le rendement du Staking provient de l'inflation naturelle et de la MEV redistribuée aux validateurs (la MEV est redistribuée proportionnellement au portfolio du validateur)
• Le rendement du Lending est basé sur la demande d'emprunt et mis à l'échelle par un taux sans risque.

Question clé : comment les choix de portfolios des validateurs et la redistribution de la MEV affectent-ils les incitations ?

Staking VS Lending (7:30)

Des travaux antérieurs ont montré que le staking a souvent besoin de récompenses inflationnistes pour concurrencer les rendements du Lending. Avec des récompenses constantes ou déflationnistes, les validateurs préfèrent le Lending au Staking : si les validateurs préfèrent le Lending, cela peut compromettre la sécurité du réseau puisque moins de validateurs font du Staking.

La recherche a montré qu'une dynamique similaire se produit entre les rendements du Staking et les rendements des Dérivés.

La redistribution de la MEV pourrait fournir un moyen alternatif d'inciter au Staking et d'éviter des récompenses très inflationnistes. Mais comment la redistribution de la MEV impacte-t-elle la dynamique Staking-Lending ?

Staking VS Lending VS MEV (10:45)

Bien que la MEV soit souvent considérée négativement comme parasitaire sur les blockchains, la redistribuer peut inciter à un comportement bénéfique pour le Staking.

Si le paramètre α de redistribution de la MEV est défini suffisamment haut, le modèle montre que les validateurs peuvent être suffisamment incités à faire du Staking sans compter sur une émission monétaire très inflationniste.

La redistribution de la MEV fournit un moyen alternatif d'inciter au Staking et d'empêcher les validateurs de quitter le Staking pour d'autres rendements. Cela dit, la façon dont la MEV est redistribuée est très importante pour aligner correctement les incitations.

Propriétés distributives de la redistribution (12:30)

Aligner correctement les incitations ne suffit peut-être pas. Nous devons permettre aux validateurs d'avoir une certaine prévisibilité des revenus pour rendre la redistribution de la MEV efficace.

Comme dit précédemment, les validateurs font un arbitrage Bénéfices/Risques pour optimiser leur portfolio, et les revenus prévisibles réduisent le risque.

Orientations futures (14:00)

Un domaine important pour les recherches futures consiste à analyser les risques de centralisation potentiels de la redistribution de la MEV, en particulier les boucles de rétroaction (Feedback loops)

Les mécanismes existants de frais de transaction pourraient potentiellement être modifiés pour mettre en œuvre la redistribution de la MEV dans la pratique :

• Nous avons besoin de mécanismes appropriés pour empêcher les validateurs de conclure des accords off-chain ou de se retirer de la redistribution.
• Nous devons analyser la théorie des jeux coopératifs des pools de validateurs dans le cadre de la redistribution de la MEV.

Question ouverte : La compatibilité des incitations en boucle fermée peut-elle être formellement prouvée pour la redistribution de la MEV ?

Courses à l'arbitrage

Les jeux de latence dans les plateformes d'échange (0:20)

Une recherche utilisant des données de trafic de messages entre traders et bourses sur le marché des actions britanniques a révélé un volume étonnamment élevé de courses à l'arbitrage :

• 20% du volume de transactions a été identifié comme des courses, avec des différences de l'ordre de millisecondes ou microsecondes entre les entreprises poursuivant le même arbitrage.
• Parmi ces entreprises, seules quelques-unes ont remporté 50 à 85% des courses, montrant des tendances à la centralisation.

Les bourses de crypto centralisées sont également confrontées à des jeux de latence comme le déploiement de nœuds dans des services de cloud et le ping des matching engines. Les points de terminaison hébergés dans le cloud permettent des jeux de latence similaires aux marchés traditionnels parmi les bourses de crypto.

Les jeux de latence en crypto (5:00)

La crypto a probablement encore plus de jeux de latence en raison de la capacité à manipuler l'ordre des transactions et les horodatages. Des exemples ont été observés :

• Solana a priorisé des temps de bloc faibles, ce qui a conduit à des stratégies nécessitant que les validateurs soient situés dans des centres de données haut de gamme et à faible latence comme AWS.
• Dans les séquenceurs comme Arbitrum, il est nécessaire de signaler des manipulations, mais ce genre de manoeuvre est largement opaques pour les utilisateurs lambdas.

Les jeux de latence on-chain sont moins répandus que les marchés traditionnels, mais c'est un problème croissant et plus complexe que les marchés traditionnels.

Tout pour le vainqueur (8:00)

Les jeux de latence peuvent être des courses "winner-takes-all" qui incitent à la centralisation physique de l'infrastructure :

• Avec des séquenceurs à faibles frais, les jeux de latence se manifestent par du spam.
• Des frais élevés permettent l'arbitrage de latence.

Éliminer les jeux de latence implique des recherches, des données, des conversations et une réflexion philosophique sur des concepts comme la décentralisation géographique.

La conception par lots d'Ethereum réduit les jeux de latence, mais la MEV Cross-chain et les exchanges centralisés créent une pression centralisante.

Et si les jeux de latence étaient une question de temps ?

Personne n'est d'accord sur le temps(12:40)

Nous avons le temps discret, le temps continu, le temps relatif et le temps absolu. Il y a une tendance à la compétition relative, au temps relatif plutôt qu'au temps absolu

Certains types de jeux de latence pourraient être du type "Winner-takes-all", tandis que d'autres types de jeux de latence pourraient ne pas l'être. Différentes parties pourraient découvrir des opportunités d'arbitrage dans des secteur ultra-spécifiques. Et cela, pour certaines raisons, rappelle l'industrie immobilière.

L'industrie immobillière (16:20)

L'industrie immobilière est une autre industrie avec beaucoup de rentes. La façon dont cela se déroule économiquement est que nous avons beaucoup de petits agents immobiliers se battant chacun pour leur petit bout. Mais il y a une tendance à la centralisation dans ce marché, qui sont les lobbies immobiliers.

Les lobbies aident à préserver une sorte "d'arrangement économique défectueux" de la nécessité d'un courtier acheteur et vendeur. Même si les rentiers seraient très dispersés, ils trouvent tout de même un moyen de se regrouper

La clé est d'aligner les incitations privées avec le bien-être social, pas les activités socialement improductives.

Crypto VS TradFi

Différences avec la TradFi (26:10)

Contrairement à la finance traditionnelle où l'exécution repose sur des relations de confiance, la crypto permet des ordres combinatoires plus programmatiques couvrant différents lieux en même temps :

• Nouveaux actifs et protocoles
• Effet de levier
• Enchères
• Cross-chain

Tous ces domaines créent des opportunités d'arbitrage, et amènent la structure de marché crypto à évoluer différemment de la TradFi.

L'arbitrage reste un concept simple en crypto, à savoir l'exploitation des différences de prix. Mais sur le plan technologique, ils sont difficiles à exploiter

Concurrence sur le risque (31:10)

Lors des récents effondrements de stablecoins, les LP passifs ont fourni un filet de sécurité de liquidité alors que les entreprises sophistiquées se retiraient rationnellement d'opportunités d'arbitrage extrêmement volatiles.

Les profils de risque variés entre les fournisseurs de liquidité passifs (LP) et les arbitragistes sophistiqués créent un système plus robuste par rapport au cas où ce ne serait qu'un jeu à somme nulle sur l'arbitrage.

La MEV ne peut pas être complètement résolue

Limites fondamentales (33:30)

Il existe des limites fondamentales à l'ordonnancement décentralisé :

• L'horodatage parfait ne peut pas atteindre une véritable équité en raison de la relativité. L'ordre des événements dépend du référentiel de l'observateur.
• L'horodatage de confiance ne ferait que raccourcir l'intervalle de traitement par lots, et ne résoudrait pas la MEV. Au mieux, l'horodatage approxime un ordonnancement du premier arrivé, premier servi, qui laisse toujours la voie ouverte au spam de transactions ou aux courses de latence pour obtenir un traitement favorable.
• Les enchères par lots fréquentes (Frequent Batch Auctions) pourraient résoudre la MEV au niveau de la couche applicative en réduisant les dynamiques du type "Winner-Takes-All" liées à l'équité. Mais ils ne peuvent résoudre la MEV au niveau du protocole de base.

Les protocoles décentralisés ne peuvent pas échapper à la subjectivité inhérente à l'ordonnancement des événements, contrairement aux systèmes centralisés qui peuvent dicter un cadre de référence. Résoudre complètement la MEV peut être impossible en raison de l'inéquité inévitable dans la façon dont les différents observateurs ordonneront les événements.

À propos de l'équité (45:50)

Il n'y a aucun moyen d'atteindre un ordonnancement décentralisé parfait sans subjectivité. La diversité géographique augmente le temps de coordination que certains peuvent juger injuste, mais le manque de diversité soumet les systèmes à des réglementations centralisées (comme on a pu le voir avec l'OFAC)

La paramétrisation des intervalles de temps implique des arbitrages d'équité :

• Des intervalles plus courts favorisent les participants à faible latence.
• De longs intervalles désavantagent les participants à latence plus élevée.

La véritable équité concerne la distribution rationnelle des loyers. Mais il n'y a aucun moyen clair de définir une distribution de loyer rationnelle. Différents observateurs ordonneront les événements différemment.

Il y a donc 2 questions ouvertes:

1. Que peut-on résoudre au niveau applicatif ?
2. Que peut-on, le cas échéant, résoudre au niveau du protocole ?

Les enchères par lots (Batch Auctions) sont des "cartels" (52:00)

Il n'y a aucun jugement de valeur à les appeler des cartels. C'est juste une façon de désigner des utilisateurs disant "mettons-nous ensemble pour nous faire respecter", et leur impact peut être positif ou négatif.

Mais la nature de cartel des Batch Auctions implique inévitablement des compromis :

• Blockchains à usage général : peuvent accueillir divers cas d'utilisation, mais cela nécessite d'aligner les externalités avec le protocole de base (comme l'intégration de Flashbots dans la production de blocs Ethereum).
• Blockchains spécifique : un Batch Auction sur une chaîne spécifique permettrait une abstraction nette des externalités, mais il y aurait toujours de la MEV provenant de l'arbitrage Cross-chain

Il s'agit d'un domaine actif d'expérimentation et de débat pour déterminer l'approche optimale.

L'avantage matériel (55:20)

Les profits incitent à tous les types de comportements innovants, mais nous devons aligner les incitations aux bénéfices privés avec ce qui est socialement utile pour les marchés afin d'éviter les jeux à somme nulle ou négative (les arbitrages sont des jeux à somme nulle).

Les risques de MEV poussent vers du matériel spécialisé, transformant les systèmes de Proof-of-Stake en "Proof-of-Work". En d'autres termes, des stratégies crypto complexes créent des avantages pour le matériel spécialisé, risquant la centralisation, comme les FPGA dans l'extraction de la MEV sur Solana.

À propos des investissements en fibre HFT

Il n'y a aucune preuve claire que les investissements en fibre HFT ont apporté une valeur sociale. Eric garde l'esprit ouvert quant à la possibilité d'avoir des avantages imprévus, mais n'a pas trouvé de preuves démontrant leur existence

Pour Eric, il est difficile de concevoir qu'il y ait une valeur sociale à passer de 5 microsecondes à 4 microsecondes

Il y a eu un débat pour ou contre la répartition géographique :

😇Pour Phil, la crypto devrait répartir le calcul géographiquement, et ne pas le centraliser en un seul cartel
😈Michael pense que la diversité géographique est antagoniste à l'équité car vous augmentez le temps réel nécessaire au réseau pour se coordonner