Dans les deux premières parties de cette série, nous nous sommes concentrés sur les problèmes techniques qui se posent lors de la division de la pile et sur les améliorations qui doivent être apportées dans le monde modulaire. Nous avons couvert un certain nombre d’avancées en matière de travail pour résoudre les problèmes qui surviennent naturellement dans les configurations inter-domaines. Cependant, dans la dernière partie de la série, nous voulons nous concentrer davantage sur l’expérience utilisateur. Nous voulions voir comment la modularisation, la personnalisation et la spécialisation peuvent aider à créer de meilleures applications. Le dernier chapitre de cette série se penchera sur la créativité et les possibilités passionnantes et uniques en matière de modularité permettant aux développeurs de créer des expériences utilisateur Web2 avec la vérifiabilité Web3.
La raison d’être de la modularité ne devrait pas seulement être de répondre à la narration ou simplement d’être modulaire, mais parce qu’elle nous permet de créer des applications meilleures, plus efficaces et plus personnalisables. Lors de la construction de systèmes modulaires et spécialisés, un certain nombre de caractéristiques uniques apparaissent. Certains d’entre eux sont évidents, tandis que d’autres le sont moins. Par conséquent, notre objectif est de fournir un aperçu des capacités du système modulaire que vous ne connaissiez pas, telles que l’évolutivité.
Nous pensons que l’une des capacités que la modularité offre aux développeurs est la possibilité de créer des applications professionnelles hautement personnalisables qui conduisent à une meilleure expérience pour les utilisateurs finaux. Nous avons déjà discuté de la possibilité de définir des règles ou de réorganiser l’ordre dans lequel les transactions sont exécutées.
Les classements vérifiables (ci-après dénommés VSR) sont l’une des opportunités intéressantes offertes par le tri contrôlé, en particulier pour les développeurs intéressés par la construction de systèmes de trading plus « équitables » en termes d’exécution. De toute évidence, la relation entre les pertes des fournisseurs de liquidité et le rééquilibrage (LVR) dépasse le cadre de cet article, nous éviterons donc d’en parler trop. Gardez à l’esprit que les paramètres que nous allons expliquer concernent principalement l’AMM et non le modèle de carnet d’ordres. En outre, CLOB (et même CEX) bénéficiera également grandement de l’exploitation de classements vérifiables qui correspondent à leurs paramètres spécifiques. Dans une configuration hors chaîne, il existe un besoin évident d’un concept d’exécution à connaissance nulle ou optimiste soutenu par une sécurité cryptoéconomique.
La VSR est particulièrement intéressante si l’on considère le fait que la majorité des investisseurs particuliers n’ont pas encore (ou sont peu probables) adopté une approche de conservation. La plupart des portefeuilles/DEX n’implémentent pas non plus de mempools privés, de RPC ou de méthodes similaires. La plupart des transactions sont soumises directement via le frontend (qu’il s’agisse d’un agrégateur ou d’un frontend DEX). Par conséquent, à moins que l’application n’interfère directement avec ses processus et la façon dont les commandes sont traitées, l’utilisateur final peut rencontrer une exécution moins que satisfaisante.
Lorsque nous réfléchissons à l’endroit où la chaîne d’approvisionnement transactionnelle est ordonnée, le rôle de la VSR devient évident. C’est là que les participants professionnels trient (ou incluent) les transactions, généralement en fonction d’une enchère ou d’une commission de base. Ce séquençage est très important car il détermine quelles transactions sont exécutées et quand. Essentiellement, la personne qui a le pouvoir de tri a la possibilité d’extraire le MEV, généralement sous la forme d’une redevance prioritaire (ou d’un pourboire).
Par conséquent, il pourrait être intéressant d’écrire des règles sur la façon de gérer le tri afin de fournir une exécution plus équitable des transactions (dans une configuration DEX) à l’utilisateur final. Cependant, si vous construisez un réseau à usage général, vous devriez essayer d’éviter de suivre de telles règles.
De plus, il y a certains MEV qui sont importants, comme l’arbitrage, la liquidation, etc. L’une des idées est de créer un canal « autoroute » au sommet du bloc, ciblant spécifiquement les arbitragistes et les liquidateurs figurant sur la liste d’autorisation, qui paient des frais plus élevés et partagent une partie des revenus avec le protocole.
Dans l’article « Design of Trusted DEX Exchanges with Verifiable Collations », Matheus V., X. Ferreira et David C. Parkes proposent un modèle dans lequel le séquenceur d’un bloc est soumis à une série de contraintes qui exécutent des classements (et ces contraintes sont vérifiables). Sans respecter les règles établies, l’observateur peut générer une preuve de la défaillance (ou puisque les contraintes sont mathématiquement vérifiables, vous pouvez également imaginer un circuit ZK avec ces contraintes, qui utilise ZKP comme preuve de validité). L’idée principale est essentiellement de fournir une garantie de prix d’exécution à l’utilisateur final (trader). Cette garantie garantit que la transaction est exécutée à la hauteur de la seule transaction du bloc (évidemment, si nous supposons un ordre d’achat/vente/achat/vente basé sur le principe du premier arrivé, premier servi, il y a un certain délai impliqué ici). L’idée de base des propositions de l’article est que si elles fonctionnent à un meilleur prix que le prix disponible au sommet du bloc, ces classements empêcheront le constructeur (dans un scénario PBS) ou le séquenceur de n’inclure que des transactions dans la même direction (par exemple, vendre/vendre). De plus, s’il y a une situation où vous effectuez une vente à la fin d’une série d’achats, alors la vente ne sera pas exécutée (par exemple, acheter, acheter, acheter, vendre), ce qui peut indiquer que les chercheurs (ou les constructeurs/séquenceurs) utilisent ces achats pour pousser le prix en leur faveur. Cela signifie essentiellement que les règles du protocole garantissent que les utilisateurs ne seront pas utilisés pour offrir un meilleur prix (c’est-à-dire MEV) à quelqu’un d’autre, ou pour faire baisser le prix en raison de frais prioritaires. De toute évidence, le défaut de la règle ici (dans le cas de vendre plus que d’acheter, et vice versa) est que vous pouvez obtenir un prix de longue traîne relativement faible.
Pour une plateforme de Smart Contract générale, il est presque impossible de construire ces règles comme purement on-chain car vous n’avez aucun contrôle sur l’exécution et la commande. En même temps, vous êtes en concurrence avec beaucoup d’autres, alors essayer de forcer ceux qui sont au sommet du pâté de maisons à payer des frais prioritaires serait inutilement coûteux. L’une des caractéristiques de la configuration modulaire est qu’elle permet aux développeurs d’applications de personnaliser le comportement de leur environnement d’exécution. Qu’il s’agisse de l’assemblage, de l’utilisation d’une autre machine virtuelle ou de la modification personnalisée d’une machine virtuelle existante, comme l’ajout d’un nouveau code d’opération ou la modification de la limite de gaz, c’est vraiment au développeur de décider, en fonction de son produit.
Dans le cas d’un cumul utilisant la disponibilité des données, les niveaux Consensus et LiquiditySettlement, les paramètres possibles sont les suivants :
Une autre idée possible est le fractionnement des transactions. Imaginez un pool de transactions, comment exécuter des transactions d’ordres importants (qui causent beaucoup de glissement) et si cette transaction est exécutée sur des blocs consécutifs (ou à la fin du bloc si elle est conforme à VSR), est-ce équitable pour l’utilisateur final ?
Si l’utilisateur final est préoccupé par la latence, il se peut qu’il ne veuille pas que sa commande soit fractionnée. Cependant, cela est moins courant, et l’optimisation pour le fractionnement des transactions d’ordres plus importants peut se traduire par une exécution plus efficace pour la grande majorité des utilisateurs. Quoi qu’il en soit, l’une des préoccupations est que les chercheurs MEV peuvent prendre conscience de ces transactions séquentielles et essayer de positionner leurs transactions avant ou après lesdits traders. Cependant, en raison des transactions fractionnées à petite échelle sur une série de blocs, la valeur totale du MEV extrait peut être beaucoup plus faible.
Une autre idée intéressante que nous avons mentionnée plus tôt dans l’article est d’utiliser les enchères en vrac fréquentes (FBA), préconisées par le légendaire Eric Budish et ses collègues, pour traiter les transactions à la manière d’une vente aux enchères en vrac plutôt qu’en série. Il s’agit d’aider à identifier les demandes qui se chevauchent et d’intégrer les opportunités d’arbitrage dans la conception des mécanismes de marché. Cela permet également de « combattre » les parties différées dans les builds de blocs continus (ou les batailles à coût prioritaire dans les blocs en série). Merci à Michael Jordan (DBA) d’avoir porté cet article à notre attention et pour son travail sur l’atténuation de la torréfaction de latence. L’implémenter dans le cadre de la sélection et du classement des forks de Rollup est également une configuration intéressante que les développeurs peuvent utiliser, et nous avons vu sa traction significative au cours de l’année écoulée, en particulier pour Penumbra et CoWSwap. Une configuration possible ressemblerait à ceci :
Dans cette configuration, il n’y a pas de guerre des frais de gaz selon le principe du premier arrivé, premier servi ou prioritaire, mais plutôt un bloc pour mettre fin à l’enchère en gros dans le temps entre chaque bloc en fonction des commandes cumulées.
En général, là où la plupart des transactions ont été déplacées vers un monde « on-chain » non dépositaire, le service Expédié par Amazon peut être l’un des moyens les plus efficaces de découvrir les prix « réels », en fonction du temps de bloc. L’utilisation du service Expédié par Amazon signifie également que, puisque tous les ordres groupés sont en vrac et ne seront pas révélés avant la fin de l’enchère (en supposant qu’il y ait des configurations de crypto-monnaies), il y aura une réduction significative des transactions en cours d’avance. Les prix de règlement sont la clé ici, car il ne sert à rien de réorganiser les transactions.
Il est également important de noter qu’en 2018, des designs comme ceux que nous venons de couvrir ont été discutés sur les forums Ethresear.ch (voir ici). Dans l’article, ils mentionnent deux articles qui fournissent un mécanisme d’enchères en masse sur Plasma (un peu comme une préquelle aux Rollups modernes), où chaque lot accepte des ordres d’achat de jetons ERC20 supplémentaires à un certain prix limite maximum. Ces ordres sont collectés à certains intervalles et fournissent un prix de règlement uniforme pour toutes les paires de trading de jetons. L’idée générale derrière ce modèle est qu’il aidera à éliminer le phénomène de course frontale qui est courant dans les AMM populaires.
Une autre chose importante à noter est que dans ces configurations, le séquenceur peut avoir besoin d’incitations pour appliquer (et appliquer) les règles ci-dessus. Cela est souvent négligé, mais une grande partie de l’infrastructure du réseau Blockchain est gérée par des entreprises spécialisées, dont le coût est très différent de celui du participant domestique moyen. En général, les incitations sont un élément important de la mise en œuvre de l’infrastructure de sécurité. Les séquenceurs et les constructeurs sont également plus susceptibles de faire plus d’efforts lorsque les incitations sont alignées sur les règles appliquées. Cela signifie que ces installations doivent également avoir un marché actif. De toute évidence, ce type de marché est de plus en plus centralisé, car le coût du capital pour la spécialisation peut être élevé. En conséquence, les Satoshi (et les plus riches) sont susceptibles de se consolider et de se spécialiser afin de capturer autant de valeur que possible. Ici, le flux de commande d’exclusivité peut être une flèche sur le genou pour certains participants, conduisant à une augmentation de la centralisation. Des frais généraux de Benchmark peuvent être suffisants, mais ils ne poussent pas vraiment les participants au classement vers la spécialisation. Par conséquent, vous voudrez peut-être introduire certains concepts qui rendent les traders satisfaits des résultats grâce à des incitations adaptées à votre situation particulière.
C’est clair pour la plupart des gens, mais cela doit tout de même être mentionné lors de la discussion sur l’ordre des niveaux de cumul. Si vous pouvez contrôler l’ordre, il sera plus facile d'"extraire » la valeur du protocole. Cela est dû au fait que vous contrôlez le pouvoir de réorganiser les transactions, qui est généralement basé sur les frais de priorité (paramètres MEV-boost-esque) sur la plupart des L1. Il vous fournit des frais prioritaires payés par des participants complexes qui extraient de la valeur sur la chaîne. Ces participants sont généralement prêts à payer un montant considérable (jusqu’à ce qu’il ne soit plus en mesure de fournir de la valeur). Cependant, la plupart des cumuls actuels se font principalement selon le principe du premier arrivé, premier servi. La plupart des extractions MEV sont effectuées par le biais de guerres retardées, ce qui met à rude épreuve l’infrastructure Rollup. À la suite de ce qui précède, nous verrons probablement de plus en plus de cumuls commencer à mettre en œuvre une structure de tri avec le concept de frais prioritaires (par exemple, le mécanisme d’amélioration du temps d’Arbitrum).
Un autre exemple que nous aimons est Uniswap. À l’heure actuelle, Uniswap en tant que protocole « crée » beaucoup d’inefficacités. Ces inefficacités sont exploitées par les participants qui cherchent à extraire des MEV (Arbitrage aux dépens des Fournisseurs de Liquidité). Dans le même temps, ces participants paient beaucoup de frais pour extraire de la valeur, mais aucune de ces valeurs ne tombe entre les mains du protocole Uniswap ou de ses détenteurs de jetons. Au lieu de cela, une partie importante de cette valeur extraite est payée en priorité aux proposants d’Ethereum (validateurs) via MEV-Boost pour obtenir le droit d’être inclus dans un bloc qui permet de capturer de la valeur à un moment donné. Par conséquent, bien qu’il existe de nombreuses opportunités MEV pour les flux d’ordres d’Uniswap, aucune d’entre elles n’a été capturée par Uniswap.
Si Uniswap est en mesure de contrôler les commandes au sein du protocole (et la possibilité d’extraire des frais prioritaires des chercheurs), il peut être commercialisé et peut même verser une partie de ces bénéfices aux détenteurs de jetons, aux fournisseurs de liquidité ou à d’autres. Avec les changements apportés à Uniswap (par exemple, UniswapX, etc.) passant à l’exécution hors chaîne (et Ethereum en tant que couche de règlement), ce mécanisme semble de plus en plus probable.
Si nous supposons un cumul avec un mécanisme PBS partiel, le processus de flux de commandes et de commercialisation pourrait ressembler à ceci :
En conséquence, la commercialisation des séquenceurs et des proposants de rollup peut suivre la formule suivante :
Émission (PoS) + Revenus de frais (+priorité) - Le coût de l’AD, de l’État, du stockage
Un bon moyen de voir combien de valeur est actuellement retirée sur Ethereum (en particulier l’arbitrage) peut être trouvé sur Mevboost.pics, qui donne un bon aperçu de la valeur qui peut réellement être extraite des inefficacités.
De plus, la séparation de la guerre du gaz prioritaire et de la structure hors chaîne peut aider à contenir les perturbations de la chaîne d’approvisionnement en isolant l’extraction des MEV dans l’environnement d’exécution. Cependant, étant donné que si l’élection du chef a lieu sur le Rollup, la majorité du MEV sera tirée sur le Rollup, cela laisse peu de place à la structure sous-jacente à moins que la couche DA ne soit incluse, les frais prioritaires de la couche Settlement proviennent de la consolidation de la liquidité ou d’autres économies d’échelle.
Pour clarifier, beaucoup de ces structures peuvent fonctionner comme des structures purement hors chaîne sans avoir besoin de ponts de vérification ou de solides garanties de sécurité. Cependant, il y a des compromis à faire. Nous commençons à voir de plus en plus de ces choses apparaître, à la fois existantes et invisibles. Une chose que je tiens à souligner, c’est que la modularité ne signifie pas nécessairement des cumuls.
Le classement ci-dessus représente un exemple où le réglage fin de l’infrastructure peut améliorer considérablement l’application construite dessus.
Voir l'original
Cette page peut inclure du contenu de tiers fourni à des fins d'information uniquement. Gate ne garantit ni l'exactitude ni la validité de ces contenus, n’endosse pas les opinions exprimées, et ne fournit aucun conseil financier ou professionnel à travers ces informations. Voir la section Avertissement pour plus de détails.
Comment obtenir un séquençage équitable des transactions avec le MEV modulaire ?
Auteur : Maven11
Compilateur : Luffy, Foresight News
Dans les deux premières parties de cette série, nous nous sommes concentrés sur les problèmes techniques qui se posent lors de la division de la pile et sur les améliorations qui doivent être apportées dans le monde modulaire. Nous avons couvert un certain nombre d’avancées en matière de travail pour résoudre les problèmes qui surviennent naturellement dans les configurations inter-domaines. Cependant, dans la dernière partie de la série, nous voulons nous concentrer davantage sur l’expérience utilisateur. Nous voulions voir comment la modularisation, la personnalisation et la spécialisation peuvent aider à créer de meilleures applications. Le dernier chapitre de cette série se penchera sur la créativité et les possibilités passionnantes et uniques en matière de modularité permettant aux développeurs de créer des expériences utilisateur Web2 avec la vérifiabilité Web3.
La raison d’être de la modularité ne devrait pas seulement être de répondre à la narration ou simplement d’être modulaire, mais parce qu’elle nous permet de créer des applications meilleures, plus efficaces et plus personnalisables. Lors de la construction de systèmes modulaires et spécialisés, un certain nombre de caractéristiques uniques apparaissent. Certains d’entre eux sont évidents, tandis que d’autres le sont moins. Par conséquent, notre objectif est de fournir un aperçu des capacités du système modulaire que vous ne connaissiez pas, telles que l’évolutivité.
Nous pensons que l’une des capacités que la modularité offre aux développeurs est la possibilité de créer des applications professionnelles hautement personnalisables qui conduisent à une meilleure expérience pour les utilisateurs finaux. Nous avons déjà discuté de la possibilité de définir des règles ou de réorganiser l’ordre dans lequel les transactions sont exécutées.
Les classements vérifiables (ci-après dénommés VSR) sont l’une des opportunités intéressantes offertes par le tri contrôlé, en particulier pour les développeurs intéressés par la construction de systèmes de trading plus « équitables » en termes d’exécution. De toute évidence, la relation entre les pertes des fournisseurs de liquidité et le rééquilibrage (LVR) dépasse le cadre de cet article, nous éviterons donc d’en parler trop. Gardez à l’esprit que les paramètres que nous allons expliquer concernent principalement l’AMM et non le modèle de carnet d’ordres. En outre, CLOB (et même CEX) bénéficiera également grandement de l’exploitation de classements vérifiables qui correspondent à leurs paramètres spécifiques. Dans une configuration hors chaîne, il existe un besoin évident d’un concept d’exécution à connaissance nulle ou optimiste soutenu par une sécurité cryptoéconomique.
La VSR est particulièrement intéressante si l’on considère le fait que la majorité des investisseurs particuliers n’ont pas encore (ou sont peu probables) adopté une approche de conservation. La plupart des portefeuilles/DEX n’implémentent pas non plus de mempools privés, de RPC ou de méthodes similaires. La plupart des transactions sont soumises directement via le frontend (qu’il s’agisse d’un agrégateur ou d’un frontend DEX). Par conséquent, à moins que l’application n’interfère directement avec ses processus et la façon dont les commandes sont traitées, l’utilisateur final peut rencontrer une exécution moins que satisfaisante.
Lorsque nous réfléchissons à l’endroit où la chaîne d’approvisionnement transactionnelle est ordonnée, le rôle de la VSR devient évident. C’est là que les participants professionnels trient (ou incluent) les transactions, généralement en fonction d’une enchère ou d’une commission de base. Ce séquençage est très important car il détermine quelles transactions sont exécutées et quand. Essentiellement, la personne qui a le pouvoir de tri a la possibilité d’extraire le MEV, généralement sous la forme d’une redevance prioritaire (ou d’un pourboire).
Par conséquent, il pourrait être intéressant d’écrire des règles sur la façon de gérer le tri afin de fournir une exécution plus équitable des transactions (dans une configuration DEX) à l’utilisateur final. Cependant, si vous construisez un réseau à usage général, vous devriez essayer d’éviter de suivre de telles règles.
De plus, il y a certains MEV qui sont importants, comme l’arbitrage, la liquidation, etc. L’une des idées est de créer un canal « autoroute » au sommet du bloc, ciblant spécifiquement les arbitragistes et les liquidateurs figurant sur la liste d’autorisation, qui paient des frais plus élevés et partagent une partie des revenus avec le protocole.
Dans l’article « Design of Trusted DEX Exchanges with Verifiable Collations », Matheus V., X. Ferreira et David C. Parkes proposent un modèle dans lequel le séquenceur d’un bloc est soumis à une série de contraintes qui exécutent des classements (et ces contraintes sont vérifiables). Sans respecter les règles établies, l’observateur peut générer une preuve de la défaillance (ou puisque les contraintes sont mathématiquement vérifiables, vous pouvez également imaginer un circuit ZK avec ces contraintes, qui utilise ZKP comme preuve de validité). L’idée principale est essentiellement de fournir une garantie de prix d’exécution à l’utilisateur final (trader). Cette garantie garantit que la transaction est exécutée à la hauteur de la seule transaction du bloc (évidemment, si nous supposons un ordre d’achat/vente/achat/vente basé sur le principe du premier arrivé, premier servi, il y a un certain délai impliqué ici). L’idée de base des propositions de l’article est que si elles fonctionnent à un meilleur prix que le prix disponible au sommet du bloc, ces classements empêcheront le constructeur (dans un scénario PBS) ou le séquenceur de n’inclure que des transactions dans la même direction (par exemple, vendre/vendre). De plus, s’il y a une situation où vous effectuez une vente à la fin d’une série d’achats, alors la vente ne sera pas exécutée (par exemple, acheter, acheter, acheter, vendre), ce qui peut indiquer que les chercheurs (ou les constructeurs/séquenceurs) utilisent ces achats pour pousser le prix en leur faveur. Cela signifie essentiellement que les règles du protocole garantissent que les utilisateurs ne seront pas utilisés pour offrir un meilleur prix (c’est-à-dire MEV) à quelqu’un d’autre, ou pour faire baisser le prix en raison de frais prioritaires. De toute évidence, le défaut de la règle ici (dans le cas de vendre plus que d’acheter, et vice versa) est que vous pouvez obtenir un prix de longue traîne relativement faible.
Pour une plateforme de Smart Contract générale, il est presque impossible de construire ces règles comme purement on-chain car vous n’avez aucun contrôle sur l’exécution et la commande. En même temps, vous êtes en concurrence avec beaucoup d’autres, alors essayer de forcer ceux qui sont au sommet du pâté de maisons à payer des frais prioritaires serait inutilement coûteux. L’une des caractéristiques de la configuration modulaire est qu’elle permet aux développeurs d’applications de personnaliser le comportement de leur environnement d’exécution. Qu’il s’agisse de l’assemblage, de l’utilisation d’une autre machine virtuelle ou de la modification personnalisée d’une machine virtuelle existante, comme l’ajout d’un nouveau code d’opération ou la modification de la limite de gaz, c’est vraiment au développeur de décider, en fonction de son produit.
Dans le cas d’un cumul utilisant la disponibilité des données, les niveaux Consensus et LiquiditySettlement, les paramètres possibles sont les suivants :
Une autre idée possible est le fractionnement des transactions. Imaginez un pool de transactions, comment exécuter des transactions d’ordres importants (qui causent beaucoup de glissement) et si cette transaction est exécutée sur des blocs consécutifs (ou à la fin du bloc si elle est conforme à VSR), est-ce équitable pour l’utilisateur final ?
Si l’utilisateur final est préoccupé par la latence, il se peut qu’il ne veuille pas que sa commande soit fractionnée. Cependant, cela est moins courant, et l’optimisation pour le fractionnement des transactions d’ordres plus importants peut se traduire par une exécution plus efficace pour la grande majorité des utilisateurs. Quoi qu’il en soit, l’une des préoccupations est que les chercheurs MEV peuvent prendre conscience de ces transactions séquentielles et essayer de positionner leurs transactions avant ou après lesdits traders. Cependant, en raison des transactions fractionnées à petite échelle sur une série de blocs, la valeur totale du MEV extrait peut être beaucoup plus faible.
Une autre idée intéressante que nous avons mentionnée plus tôt dans l’article est d’utiliser les enchères en vrac fréquentes (FBA), préconisées par le légendaire Eric Budish et ses collègues, pour traiter les transactions à la manière d’une vente aux enchères en vrac plutôt qu’en série. Il s’agit d’aider à identifier les demandes qui se chevauchent et d’intégrer les opportunités d’arbitrage dans la conception des mécanismes de marché. Cela permet également de « combattre » les parties différées dans les builds de blocs continus (ou les batailles à coût prioritaire dans les blocs en série). Merci à Michael Jordan (DBA) d’avoir porté cet article à notre attention et pour son travail sur l’atténuation de la torréfaction de latence. L’implémenter dans le cadre de la sélection et du classement des forks de Rollup est également une configuration intéressante que les développeurs peuvent utiliser, et nous avons vu sa traction significative au cours de l’année écoulée, en particulier pour Penumbra et CoWSwap. Une configuration possible ressemblerait à ceci :
Dans cette configuration, il n’y a pas de guerre des frais de gaz selon le principe du premier arrivé, premier servi ou prioritaire, mais plutôt un bloc pour mettre fin à l’enchère en gros dans le temps entre chaque bloc en fonction des commandes cumulées.
En général, là où la plupart des transactions ont été déplacées vers un monde « on-chain » non dépositaire, le service Expédié par Amazon peut être l’un des moyens les plus efficaces de découvrir les prix « réels », en fonction du temps de bloc. L’utilisation du service Expédié par Amazon signifie également que, puisque tous les ordres groupés sont en vrac et ne seront pas révélés avant la fin de l’enchère (en supposant qu’il y ait des configurations de crypto-monnaies), il y aura une réduction significative des transactions en cours d’avance. Les prix de règlement sont la clé ici, car il ne sert à rien de réorganiser les transactions.
Il est également important de noter qu’en 2018, des designs comme ceux que nous venons de couvrir ont été discutés sur les forums Ethresear.ch (voir ici). Dans l’article, ils mentionnent deux articles qui fournissent un mécanisme d’enchères en masse sur Plasma (un peu comme une préquelle aux Rollups modernes), où chaque lot accepte des ordres d’achat de jetons ERC20 supplémentaires à un certain prix limite maximum. Ces ordres sont collectés à certains intervalles et fournissent un prix de règlement uniforme pour toutes les paires de trading de jetons. L’idée générale derrière ce modèle est qu’il aidera à éliminer le phénomène de course frontale qui est courant dans les AMM populaires.
Une autre chose importante à noter est que dans ces configurations, le séquenceur peut avoir besoin d’incitations pour appliquer (et appliquer) les règles ci-dessus. Cela est souvent négligé, mais une grande partie de l’infrastructure du réseau Blockchain est gérée par des entreprises spécialisées, dont le coût est très différent de celui du participant domestique moyen. En général, les incitations sont un élément important de la mise en œuvre de l’infrastructure de sécurité. Les séquenceurs et les constructeurs sont également plus susceptibles de faire plus d’efforts lorsque les incitations sont alignées sur les règles appliquées. Cela signifie que ces installations doivent également avoir un marché actif. De toute évidence, ce type de marché est de plus en plus centralisé, car le coût du capital pour la spécialisation peut être élevé. En conséquence, les Satoshi (et les plus riches) sont susceptibles de se consolider et de se spécialiser afin de capturer autant de valeur que possible. Ici, le flux de commande d’exclusivité peut être une flèche sur le genou pour certains participants, conduisant à une augmentation de la centralisation. Des frais généraux de Benchmark peuvent être suffisants, mais ils ne poussent pas vraiment les participants au classement vers la spécialisation. Par conséquent, vous voudrez peut-être introduire certains concepts qui rendent les traders satisfaits des résultats grâce à des incitations adaptées à votre situation particulière.
C’est clair pour la plupart des gens, mais cela doit tout de même être mentionné lors de la discussion sur l’ordre des niveaux de cumul. Si vous pouvez contrôler l’ordre, il sera plus facile d'"extraire » la valeur du protocole. Cela est dû au fait que vous contrôlez le pouvoir de réorganiser les transactions, qui est généralement basé sur les frais de priorité (paramètres MEV-boost-esque) sur la plupart des L1. Il vous fournit des frais prioritaires payés par des participants complexes qui extraient de la valeur sur la chaîne. Ces participants sont généralement prêts à payer un montant considérable (jusqu’à ce qu’il ne soit plus en mesure de fournir de la valeur). Cependant, la plupart des cumuls actuels se font principalement selon le principe du premier arrivé, premier servi. La plupart des extractions MEV sont effectuées par le biais de guerres retardées, ce qui met à rude épreuve l’infrastructure Rollup. À la suite de ce qui précède, nous verrons probablement de plus en plus de cumuls commencer à mettre en œuvre une structure de tri avec le concept de frais prioritaires (par exemple, le mécanisme d’amélioration du temps d’Arbitrum).
Un autre exemple que nous aimons est Uniswap. À l’heure actuelle, Uniswap en tant que protocole « crée » beaucoup d’inefficacités. Ces inefficacités sont exploitées par les participants qui cherchent à extraire des MEV (Arbitrage aux dépens des Fournisseurs de Liquidité). Dans le même temps, ces participants paient beaucoup de frais pour extraire de la valeur, mais aucune de ces valeurs ne tombe entre les mains du protocole Uniswap ou de ses détenteurs de jetons. Au lieu de cela, une partie importante de cette valeur extraite est payée en priorité aux proposants d’Ethereum (validateurs) via MEV-Boost pour obtenir le droit d’être inclus dans un bloc qui permet de capturer de la valeur à un moment donné. Par conséquent, bien qu’il existe de nombreuses opportunités MEV pour les flux d’ordres d’Uniswap, aucune d’entre elles n’a été capturée par Uniswap.
Si Uniswap est en mesure de contrôler les commandes au sein du protocole (et la possibilité d’extraire des frais prioritaires des chercheurs), il peut être commercialisé et peut même verser une partie de ces bénéfices aux détenteurs de jetons, aux fournisseurs de liquidité ou à d’autres. Avec les changements apportés à Uniswap (par exemple, UniswapX, etc.) passant à l’exécution hors chaîne (et Ethereum en tant que couche de règlement), ce mécanisme semble de plus en plus probable.
Si nous supposons un cumul avec un mécanisme PBS partiel, le processus de flux de commandes et de commercialisation pourrait ressembler à ceci :
En conséquence, la commercialisation des séquenceurs et des proposants de rollup peut suivre la formule suivante :
Émission (PoS) + Revenus de frais (+priorité) - Le coût de l’AD, de l’État, du stockage
Un bon moyen de voir combien de valeur est actuellement retirée sur Ethereum (en particulier l’arbitrage) peut être trouvé sur Mevboost.pics, qui donne un bon aperçu de la valeur qui peut réellement être extraite des inefficacités.
De plus, la séparation de la guerre du gaz prioritaire et de la structure hors chaîne peut aider à contenir les perturbations de la chaîne d’approvisionnement en isolant l’extraction des MEV dans l’environnement d’exécution. Cependant, étant donné que si l’élection du chef a lieu sur le Rollup, la majorité du MEV sera tirée sur le Rollup, cela laisse peu de place à la structure sous-jacente à moins que la couche DA ne soit incluse, les frais prioritaires de la couche Settlement proviennent de la consolidation de la liquidité ou d’autres économies d’échelle.
Pour clarifier, beaucoup de ces structures peuvent fonctionner comme des structures purement hors chaîne sans avoir besoin de ponts de vérification ou de solides garanties de sécurité. Cependant, il y a des compromis à faire. Nous commençons à voir de plus en plus de ces choses apparaître, à la fois existantes et invisibles. Une chose que je tiens à souligner, c’est que la modularité ne signifie pas nécessairement des cumuls.
Le classement ci-dessus représente un exemple où le réglage fin de l’infrastructure peut améliorer considérablement l’application construite dessus.