Introduction

Dans notre précédent poste 15, nous avons introduit le modèle ERC-4337. Ce modèle décrit la structure du marché des frais pour les emballeurs et détaille la fonction de coût liée au coût de publication on-chain et aux coûts de regroupement (coûts d'agrégation) d'un ensemble.

Nous avons également introduit le concept du 'Bundler Game'. Ce jeu sera l'objectif principal de la deuxième partie. Étant donné un ensemble de transactions, un bundler peut choisir quelles transactions inclure dans son bundle. Cela crée une asymétrie d'informations entre les bundlers et l'utilisateur, car l'utilisateur ne sait pas combien de transactions seront incluses dans le bundle. Cela conduit à un jeu à somme nulle où l'utilisateur est clairement désavantagé.

Cette recherche vise à explorer des méthodes pour améliorer l'expérience utilisateur en veillant à ce que les utilisateurs n'aient pas à payer un prix excessif pour être inclus dans le prochain ensemble. Au lieu de cela, les utilisateurs devraient être en mesure de payer des frais basés sur la demande réelle du marché pour l'inclusion.

L'état actuel d'ERC-4337

Dans le marché d'aujourd'hui, le mempool P2P n'est pas en direct sur mainnet et est testé sur le testnet de Sepolia. Les entreprises utilisant l'ERC-4337 fonctionnent actuellement en mode privé, les utilisateurs se connectent via un RPC à un bundler privé qui travaillera ensuite avec un buidler pour publier sur votre useroperation onchain.Application Bundle Bear 3, développé par Kofi, fournit des statistiques intrigantes sur l'état actuel de l'ERC-4337.

Dans leBundles multi-utilisateurs hebdomadaires %1En termes métriques, nous observons le pourcentage de bundlers créant des bundles qui incluent plusieurs userops. Du début de 2024 à juin 2024, ce pourcentage n'a pas dépassé 6,6%. Ces données deviennent encore plus intéressantes si l'on considère que de nombreux bundlers exécutent leurs propres paymasters, des entités qui parrainent des transactions au nom des utilisateurs. Notamment, les deux plus grands bundlers, qui fonctionnent également comme des paymasters en termes d'opérations d'utilisateurs publiées, sont...sponsored 97% 1des opérations de l'utilisateur utilisant leurs services. Le payeur paie pour certaines parties de l'opération de l'utilisateur et le reste est payé par les dapps ou d'autresentité 1.

La question qui se pose est pourquoi les payeurs, les dApps, etc., paient pour les opérations de l'utilisateur. L'utilisateur va-t-il les rembourser à l'avenir? Nous ne pouvons pas être sûrs de ce qui se passera, mais mon hypothèse personnelle est que actuellement, les dApps couvrent les frais pour augmenter l'utilisation et l'adoption de leurs applications. Une fois l'adoption élevée, il est probable que les utilisateurs devront payer eux-mêmes les transactions. Il est à noter que, pour l'utilisateur, payer une opération utilisateur avec le modèle actuel n'est pas la meilleure option, car une opération de base ERC-4337 coûte environ 42 000 gaz, tandis qu'une transaction normale coûte environ 21 000 gaz.

Variantes sur ERC-4337

Aperçu de ERC-4337

Le mempool est encore en phase de test sur Sepolia et n'est pas en direct sur le mainnet. Sans le mempool, les utilisateurs ont des options limitées pour utiliser l'abstraction de compte. Les utilisateurs interagissent avec une RPC, qui peut être proposée par un bundler qui regroupe les UserOps, ou avec un service RPC qui ne regroupe pas, similaire à des services comme Alchemy ou Infura, qui reçoivent et propaGate les transactions à d'autres bundlers.

Une fois que le mempool est actif, le flux de transactions ressemblera au diagramme ci-dessous, similaire au flux de transactions actuel. Un mempool renforce la résistance à la censure pour les utilisateurs car, contrairement au modèle RPC, il réduit les chances qu'une transaction soit exclue. Cependant, même avec un mempool, il existe encore un risque qu'un fournisseur RPC ne transmette pas la transaction, mais le modèle mempool est particulièrement bénéfique pour les utilisateurs qui préfèrent exécuter leurs propres nœuds, car il mitige ce risque.

Bien que les groupements aient le potentiel d'agir en tant que constructeurs, nous préférons garder les rôles séparés en raison du paysage concurrentiel. Les groupements feraient face à une concurrence importante de la part des constructeurs sophistiqués existants, rendant la construction moins attractive et potentiellement moins rentable. Par conséquent, les groupements sont plus incités à collaborer avec des constructeurs établis plutôt qu'à construire de manière indépendante et à risquer des pertes.

Combining the roles of bundler and builder into a single entity implies significant changes to the current system. Bundlers would need to compete with existing constructeurs sophistiqués, ou alternativement, les constructeurs actuels devront procéder à une intégration horizontale et assumer également le rôle de regroupeur. Ce dernier scénario, bien que plus plausible, suscite des inquiétudes quant à la concentration du marché et à l'impact négatif potentiel sur la résistance à la censure.

Bundlers et builders en tant que deux entités différentes

Avec les utilisateurs se connectant directement à un RPC, tout fonctionne dans un environnement plus privé, ce qui n'aide pas à la concurrence sur le marché. Dans un avenir proche, le mempool sera sur le mainnet augmentant la concurrence.

Utiliser un mempool, dans lequel les userops sont publics pour différents bundlers, augmente la concurrence, dans le cas de l'abstraction de compte non native, une séparation entre le bundler et le builder est nécessaire, dans le cas de l'abstraction de compte native, la séparation pourrait ne pas être nécessaire car le builder peut interpréter les userops comme des transactions normales.

Cela pourrait conduire au résultat suivant : Dans un environnement concurrentiel, les emballeurs abaisseront leurs prix pour être sélectionnés par les utilisateurs, qui chercheront à leur tour le prix le plus bas pour l'inclusion de leur opération utilisateur dans un paquet. Cette concurrence créera un système où l'emballeur qui offre le meilleur prix sera sélectionné plus souvent que l'emballeur qui essaie seulement de maximiser son profit en créant des paquets plus petits. Séparer les rôles de l'emballeur et du constructeur peut également renforcer la résistance à la censure. Un emballeur peut créer un paquet d'opérations utilisateur agrégées et l'envoyer à différents constructeurs. Si le paquet inclut des opérations qui pourraient être censurées, un constructeur non censeur peut l'accepter et procéder à la construction. Cependant, il est à noter que du point de vue de l'utilisateur, ce système pourrait entraîner des coûts supplémentaires, car l'introduction d'un emballeur ajoute une partie supplémentaire, entraînant des dépenses plus élevées.

RIP-7560

L'abstraction de compte native n'est pas un concept nouveau ; elle fait l'objet de recherches depuis des années. Alors que l'ERC-4337 gagne du terrain, son implémentation en dehors du protocole offre des avantages distincts ainsi que des compromis. Notamment, les EOAs existants ne peuvent pas passer sans heurt aux SCWs, et divers types de listes résistantes à la censure sont plus difficiles à utiliser. Comme mentionné précédemment, les frais supplémentaires de gaz d'un coût d'opération d'utilisateur augmentent de manière significative par rapport à une transaction normale.RIP-7560 2 ne résoudra pas intrinsèquement le problème actuel des coûts hors chaîne, mais réduira considérablement les frais de transaction. À partir du gaz initial de ~42000, il est possible de réduire le coût de ~20000 gas.

Abstraction de compte Layer2s

L'abstraction de compte peut être utilisée dans les solutions de couche 2 (L2). Certains L2 l'implémentent déjà nativement, tandis que d'autres suivent l'approche L1 et attendent une nouvelle proposition similaire à RIP-7560. En L2, le L1 est utilisé pour la disponibilité des données afin d'hériter de la sécurité, tandis que la plupart des calculs se font hors chaîne sur le L2, ce qui permet des transactions moins chères et une meilleure évolutivité.

Dans les scénarios où le calcul sur L2 est significativement moins cher que le coût des données pour la disponibilité des données (DA) sur la chaîne principale, l'utilisation de l'agrégation de signatures s'avère très bénéfique. Par exemple, l'appariement pour BLS sur le mainnet est facilité par le 0x08 1précompilation de l'EVM, ce qui coûte environ ~45000k gaz. Par conséquent, l'utilisation de BLS sur L1 est plus coûteuse que les transactions traditionnelles.

Les techniques de compression sur les L2 sont déjà utilisées, telles que la compression de 0 octet, qui réduit le coût de ~188 octets à ~154 octets pour un transfert ERC20. Avec l'agrégation de signatures, l'efficacité de compression peut être encore améliorée en utilisant une seule signature, réduisant la taille à ~128 octets.

Dans les Layer 2, l'agrégation de signatures est une innovation cruciale qui améliore à la fois l'efficacité des transactions et leur rentabilité. En combinant plusieurs signatures en une seule, la charge de données globale est considérablement réduite, ce qui permet de réduire les coûts liés à la disponibilité des données sur la couche 1. Cette avancée améliore non seulement la scalabilité, mais réduit également les coûts des transactions pour les utilisateurs, rendant le système plus économique et efficace.

Économie d'agrégation de signature dans les couches 2

Lors de l'utilisation d'un service L2, l'utilisateur supporte plusieurs coûts, notamment des frais pour l'opérateur L2, un coût basé sur la congestion du réseau et le coût de la disponibilité des données sur L1.

D'une précédente recherche sur 'Gate'Comprendre l'économie du rollup à partir de premiers principes", nous pouvons décrire les coûts auxquels un utilisateur est confronté lors de l'utilisation des services L2 comme suit:

Lorsqu'un utilisateur interagit avec une couche 2, il a certains coûts que nous pouvons définir comme suit :

• Frais utilisateur = frais de publication de données L1 + frais d'opérateur L2 + frais de congestion L2
• Coût de l'opérateur = Coût de l'opérateur L2 + Coût de publication des données L1
• Revenus de l'opérateur = Frais de l'utilisateur + MEV
• Le profit de l'opérateur = le chiffre d'affaires de l'opérateur - le coût de l'opérateur = frais de congestion L2 + MEV

Dans le cas de l'abstraction du compte non natif, une entité supplémentaire, le bundler, peut introduire des frais pour la création de paquets d'opérations utilisateur.

En tenant compte du regroupeur, les coûts et les bénéfices sont étendus comme suit :

• Frais d'utilisateur = frais de publication de données L1 + frais d'opérateur L2 + frais de congestion L2 + Frais de Bundler
• Coût du regroupement = Frais de publication des données L1 + Frais d'opérateur L2 + Frais de congestion L2
• Revenu du regroupement = Frais de l'utilisateur
• Bundler profit = Revenu du bundler - Coût du bundler = Différence entre les coûts L1 et L2 et les prix indiqués par le bundler + Frais du bundler
• Coût de l'opérateur = frais de publication de données L1 + frais d'opérateur L2
• Profit de l'opérateur = Revenu de l'opérateur - Coût de l'opérateur = Frais de congestion L2 + MEV

Le bundleur gagne sa commission auprès de l'utilisateur pour ses services, alors que le reste du paiement de l'utilisateur couvre les coûts de l'opérateur L2. Si l'utilisateur n'est pas conscient de la taille du bundle, il devient difficile d'estimer le coût réel de l'envoi des opérations de l'utilisateur, ce qui peut entraîner le bundleur à facturer des frais plus élevés que ceux nécessaires pour couvrir les coûts de l'opérateur.

Alignement des incitations en L2

L'interaction entre le regroupeur et L2 contribue à résoudre ce problème, car les L2 sont incités à maintenir les coûts des utilisateurs bas en raison de la concurrence. Surfacturer les utilisateurs peut les amener à basculer vers d'autres L2 offrant des prix plus justes.

Redéfinissons notre modèle en introduisant l'opérateur. L'utilisateur fait une offre au regroupeur pour être inclus dans le prochain bloc L2 en proposant une valeur V. L'utilisateur vise à minimiser les frais de publication des données, tandis que le regroupeur cherche à maximiser ses frais ou à obtenir un excédent des coûts d'interaction L2 et des frais d'utilisation.

Les coûts associés à la création d'un ensemble et à sa publication sur la chaîne peuvent être divisés en deux parties:

Fonction de coût on-chain : Un regroupeur émettant le regroupement B lorsque le frais de base est r dépense un coût :

Fonction de coût agrégée : Le regroupeur dispose d'une fonction de coût pour regrouper n transactions dans un seul bundle B avec un frais de base de r :

avec S′F, qui contient la publication et la vérification de la signature agrégée unique sur chaîne.

Si l'utilisateur peut obtenir une estimation fiable pour n, il peut calculer son coût à l'aide de la fonction estimateGas, disponible dans la plupart des solutions L2. Avoir une bonne estimation peut permettre à l'utilisateur de faire une offre en conséquence sans avoir à surestimer son offre pour l'inclusion. Cette fonction détermine le coût nécessaire pour assurer l'inclusion. Avoir une bonne estimation pour n et la fonction estimateGas peut éviter à l'utilisateur de payer un preVerificationGas plus élevé. Dans la prochaine section, nous explorerons divers mécanismes pour garantir une estimation fiable de n.

Les Layer2s exploitent un oracle

Le rôle de l'oracle est de surveiller le mempool et d'estimer le nombre de transactions présentes. Le processus fonctionne comme suit : la couche 2 déploie un oracle pour vérifier le mempool, puis informe l'utilisateur du nombre de transactions dans le mempool. Cela permet à l'utilisateur d'estimer son offre pour être inclus dans un bundle. La couche 2 peut demander au bundler d'inclure au moins un nombre spécifié de transactions (n) dans un bundle, sinon le bundle sera rejeté. Une fois que le bundler rassemble suffisamment de transactions pour former un bundle, il envoie le bundle à la couche 2, qui le transmet ensuite au mainnet en tant que calldata pour la disponibilité des données.

Proposition Watcher691×642 47,4 KB

Layer2s avec séquenceur partagé

Une approche intéressante consiste à avoir plusieurs réseaux de couche 2 (L2) exécutant un séquenceur partagé. Cette configuration peut fournir une estimation plus précise du mempool, car le séquenceur parvient à un accord grâce au consensus facilité par le séquenceur partagé.

Dans cette configuration, différents réseaux L2 fonctionnent de manière indépendante mais partagent un séquenceur commun. À intervalles réguliers, ces réseaux vérifient le nombre d'opérations utilisateur (userops) dans le mempool partagé. Le séquenceur partagé aide à synchroniser et à aggréger les données de ces réseaux. Une fois qu'ils parviennent à un accord, les informations sont communiquées à l'utilisateur, lui permettant de faire une offre en fonction du nombre de userops présents.

Cette approche offre plusieurs avantages. Tout d'abord, elle offre une méthode décentralisée pour déterminer le nombre d'opérations utilisateur dans la mempool, renforçant la résistance à la collusion. Deuxièmement, elle élimine le point de défaillance unique qui pourrait survenir si un seul système gérait la communication entre l'utilisateur et la mempool. Troisièmement, le séquenceur partagé assure la cohérence et réduit les divergences entre les différentes solutions L2.

En utilisant le séquenceur partagé, cette méthode garantit un système robuste et fiable pour estimer et communiquer l'état du mempool aux utilisateurs, améliorant ainsi l'efficacité et la sécurité globales du processus.

Shared Sequencer764×785 66.3 KB

Dans les deux approches expliquées en utilisant un oracle, il existe un vecteur d'attaque potentiel où un adversaire pourrait générer plusieurs opérations utilisateur dans le mempool, sachant qu'elles seront annulées si elles sont agrégées ensemble. En conséquence, l'oracle voit qu'il y a

n

transactions et nécessite un lot volumineux, mais le bundler ne peut pas créer le bundle. Ce problème pourrait bloquer le réseau pendant de nombreux blocs.

Layer2s exploitent leur propre bundler

Dans cette proposition, la couche 2 assume elle-même le rôle du bundler, tandis qu'une autre entité gère l'agrégation des signatures (il pourrait s'agir des services de bundler actuels). Le processus fonctionne comme suit : la couche 2 exploite son propre bundler, et les utilisateurs envoient leurs opérations (userops) au mempool. La couche 2 sélectionne certaines de ces userops du mempool et les envoie "brutes" à l'agrégateur, en compensant l'agrégateur pour l'agrégation des signatures. Une fois que l'agrégateur produit le bundle, il l'envoie au bundler, qui le transmet ensuite au mainnet en tant que calldata pour la disponibilité des données.

L'idée principale est que la couche 2 gère la collecte des opérations utilisateur, puis externalise l'agrégation à une autre entité. La couche 2 paie pour l'agrégation et facture à l'utilisateur des frais pour le service.

Il y a deux options différentes:

1. Modèle de frais fixes: le bundler (Séquenceur) sélectionne certaines transactions et facture à l'utilisateur des frais fixes. Ces frais fixes sont calculés de manière similaire aux transactions actuelles de la couche 2, en prévoyant le coût futur de la publication de données L1. Alternativement, la couche 2 pourrait facturer à l'utilisateur des frais fixes basés sur le coût du regroupement n.
2. aggreGated userops, la couche 2 doit encore prédire combien de transactions seront présentes dans le bundle qu'il construira pour citer correctement l'utilisateur, cela peut être fait de la même manière qu'actuellement où le . Comme c'est actuellement là où le l2 facture le meilleur prix compétitif à l'utilisateur, il est dans le meilleur intérêt de la couche 2 de maintenir les prix aussi compétitifs que possible pour l'utilisateur.
   
3. Frais fixes671×702 22,1 Ko
4. Demande de remboursement : Si la couche 2 veut améliorer sa crédibilité, elle pourrait activer les remboursements automatiques. Il s’agirait d’un mécanisme qui vérifie combien d’userops sont publiés dans un seul bloc et si les transactions auraient pu être aggreGated. Si un utilisateur qui aurait pu être agrégé ne l’a pas été et qu’aucun remboursement automatique n’a été émis, l’utilisateur peut demander un remboursement. Dans ce scénario, la couche 2 pourrait jalonner certains actifs, et si le remboursement n’est pas fourni, l’utilisateur pourrait appliquer le remboursement, garantissant ainsi l’équité et la responsabilité.
   
5. Demande de remboursement671×702 22.8 KB

Conclusion

Dans ces deux publications différentes, nous exposons les difficultés auxquelles les utilisateurs sont confrontés lorsqu'ils soumissionnent pour être inclus dans le prochain paquet. Dans la première partie, nous avons présenté le modèle ERC-4337, expliquant les coûts encourus par un emballeur lorsqu'il publie un paquet on-chain et les coûts externes associés. Nous avons également décrit les marchés des frais pour les emballeurs et avons commencé à discuter de la question du formatage de l'emballeur. Les utilisateurs rencontrent des difficultés avec les soumissions en raison d'un manque de connaissance sur le nombre de transactions présentes dans le mempool au moment de l'emballage.

Dans la deuxième partie, nous avons expliqué ERC-4337 et RIP-7560. Nous avons ensuite discuté de la raison pour laquelle l'agrégation des signatures est plus susceptible de se produire sur les solutions de la couche 2 plutôt que directement sur la couche 1. Nous avons démontré comment les solutions de la couche 2 peuvent résoudre la connaissance asymétrique que les utilisateurs connaissent de différentes manières. La première consiste à utiliser des oracles pour signaler à l'utilisateur combien de transactions sont présentes dans le mempool, avec cette approche, l'utilisateur sait combien il devrait enchérir et peut forcer le regroupeur à créer des lots plus importants. La troisième approche, la plus simple, est que la couche 2 agit comme un regroupeur et externalise l'agrégation à un tiers, laissant aux utilisateurs le soin de payer des frais pour cela.

Démenti:

1. Cet article est repris de [ethresear], Transmettre le titre original'Embedded fee markets and ERC-4337 (part 2)', Tous les droits d'auteur appartiennent à l'auteur original [ DavideRezzoli & Barnabé Monnot]. S'il y a des objections à cette réimpression, veuillez contacter la Porte d’apprentissageéquipe, et ils s'en occuperont rapidement.

2. Clause de non-responsabilité: Les points de vue et opinions exprimés dans cet article sont uniquement ceux de l'auteur et ne constituent aucun conseil en investissement.

3. Les traductions de l'article dans d'autres langues sont effectuées par l'équipe Gate Learn. Sauf mention contraire, la copie, la distribution ou le plagiat des articles traduits est interdit.