Jetons natifs de Layer 2 comme paiement des frais de transaction : une analyse technique

Cet article technique examine les avantages et les inconvénients de permettre aux utilisateurs de payer les frais de transaction avec des jetons natifs Layer 2, en analysant à la fois les mécanismes techniques et les implications sur le marché.

Prérequis

Une compréhension des mécanismes de fonctionnement des Rollups et des mécanismes d'inclusion forcée est recommandée pour une compréhension complète de cette analyse.

Introduction

La plupart des réseaux Layer 2 émettent leurs propres tokens, bien que beaucoup soient principalement utilisés à des fins de gouvernance ( comme Arbitrum et Optimism). Certains protocoles L2 ont mis en œuvre des mécanismes de staking pour leurs tokens natifs, y compris Mantle et Manta. Ces tokens stakés remplissent diverses fonctions, telles que la détermination de l'autorité de séquençage des transactions, la puissance de génération de preuves à connaissance nulle, ou l'assurance que les exigences de publication des données sont respectées. Pour des détails techniques, consultez la documentation de StarkNet, zkSync, Mantle et Manta.

Note technique : La vérification objective de "la publication correcte des données" présente des défis significatifs, rendant difficile la mise en œuvre de mécanismes de punition efficaces. Cela soulève des questions sur l'efficacité des conceptions qui reposent sur "le staking de tokens L2 pour la fonctionnalité de publication de données."

Paiement des frais de jetons natifs : Analyse technique et de marché

Avantages Techniques

La mise en œuvre des tokens natifs L2 comme mécanismes de paiement des frais élargit considérablement l'utilité des tokens au-delà des fonctions de gouvernance de base. Cette approche peut être améliorée par la mise en œuvre de mécanismes EIP-1559 pour brûler une partie des tokens collectés en tant que frais, créant potentiellement une pression déflationniste qui contribue à l'accumulation de valeur au sein de l'écosystème.

Limitations techniques

Défi de dénomination des coûts de données

Le problème fondamental reste que les séquenceurs de Rollup doivent payer les coûts de disponibilité des données en monnaie native L1 (ETH) lors du téléchargement des données de transaction sur Ethereum. Cela crée un risque de taux de change inhérent entre le moment où le séquenceur reçoit des jetons L2 en paiement et le moment où il doit convertir ces jetons en ETH pour les coûts de disponibilité des données. Cette exposition au risque ajoute une complexité opérationnelle pour les opérateurs de séquenceurs.

Note technique : Ce problème va au-delà des Rollups basés sur Ethereum. Les réseaux L2 utilisant des couches de disponibilité de données alternatives (comme Mantle ou Manta) font face à des défis identiques avec le token natif de la couche DA respective.

Impact de l'expérience utilisateur

Les modèles de frais à jeton unique peuvent créer une friction significative dans le processus d'intégration des utilisateurs. Lorsque les utilisateurs ne peuvent payer les frais qu'avec le jeton natif de la L2, ils rencontrent un problème de dépendance circulaire : ils ont besoin du jeton pour effectuer des transactions, mais acquérir le jeton nécessite souvent d'exécuter d'abord une transaction.

Par exemple, les utilisateurs déposant de l'ETH sur Polygon PoS pour la première fois découvrent qu'ils ne peuvent pas utiliser cet ETH pour payer des frais de transaction. Sans des jetons MATIC déjà disponibles dans leur portefeuille, ils ne peuvent pas exécuter la transaction nécessaire pour échanger l'ETH contre des MATIC. Cela oblige les utilisateurs à d'abord acquérir des MATIC sur L1 et ensuite à les transférer dans l'environnement L2.

Note technique : Bien que Polygon PoS soit techniquement une sidechain plutôt qu'un véritable L2, cet exemple illustre efficacement le défi de l'expérience utilisateur.

Cette friction se multiplie à travers l'écosystème - avec N différents réseaux L2 nécessitant N différents tokens pour des opérations de base.

Barrières d'interopérabilité Cross-L2

Les exigences de frais en jetons natifs créent des barrières techniques significatives à l'interopérabilité fluide des Layer 2. Par exemple, un transfert de base entre Layer 2 ne peut pas être réalisé uniquement avec de l'ETH si le Layer 2 de destination nécessite son jeton natif pour les frais de transaction.

Cela oblige les utilisateurs à gérer plusieurs avoirs en tokens et à naviguer dans des défis de liquidité complexes. Avec N L2 différents, la liquidité est fragmentée à travers N-1 paires de tokens, ce qui nécessite que les utilisateurs effectuent N échanges distincts avant d'opérer dans plusieurs environnements L2. Des opérations inter-L2 plus complexes telles que le prêt, l'ouverture de positions et les liquidations rencontrent une friction croissante en raison de ces exigences de tokens de frais.

La vision de la Superchaîne Optimism pour l'interopérabilité illustre parfaitement ce défi - si chaque Rollup au sein de l'écosystème de la Superchaîne nécessitait des tokens différents pour le paiement des frais, cela compromettrait directement les objectifs fondamentaux d'interopérabilité.

Cependant, ces limitations d'expérience et d'interopérabilité ne s'appliquent qu'aux modèles de frais de jetons natifs exclusifs. Les approches hybrides qui prennent en charge à la fois les paiements de frais en ETH et en jetons natifs peuvent atténuer ces problèmes en permettant aux utilisateurs de choisir l'ETH pour les opérations inter-chaînes tout en utilisant des jetons L2 pour les opérations natives si souhaité. StarkNet est à l'avant-garde de cette approche hybride en mettant en œuvre un support pour les paiements de frais en ETH et en STRK.

Mise en œuvre technique : STRK en tant que frais de transaction

StarkNet a récemment annoncé le support des paiements de frais en token STRK ainsi qu'en ETH. Ce modèle de frais à double devise permet aux utilisateurs de choisir leur méthode de paiement préférée tandis que le Séquenceur ( appelé "Opérateur" dans la terminologie de StarkNet ) assume le risque de change entre ETH et STRK. Cela soulève d'importantes questions techniques sur la détermination des frais pour les transactions.

Analyse technique de l'autorité du séquenceur

Sur les réseaux L1 et L2, les transactions spécifient généralement un montant maximum que l'utilisateur est prêt à payer. Sur les chaînes compatibles EIP-1559 (Ethereum, Arbitrum, Optimism), les utilisateurs spécifient une valeur maxFeePerGas, qui multipliée par gasLimit définit le montant maximum des frais de transaction. Les chaînes non EIP-1559 utilisent des modèles de frais fixes.

Note technique : StarkNet, bien qu'il n'implémente pas encore l'EIP-1559, nécessite que les utilisateurs spécifient un paramètre maxFee.

Les séquenceurs de transactions ( mineurs, validateurs ou séquenceurs L2 ) conservent l'autorité d'inclure ou d'exclure des transactions spécifiques. Cependant, une fois incluses, les transactions ne peuvent être facturées qu'à hauteur des frais maximums spécifiés par l'utilisateur.

Analyse de l'implémentation d'Oracle

STRK transparents pour la conversion des frais. Cependant, cette approche néglige la dynamique fondamentale de l'autorité des séquenceurs - les séquenceurs peuvent choisir quelles transactions inclure en fonction de leurs propres incitations économiques.

Le facteur critique reste le frais maximum qu'un utilisateur spécifie ( en ETH ou STRK), après quoi il doit attendre l'inclusion. Un oracle de taux de change public ne modifierait pas fondamentalement cette relation, car les séquenceurs conservent la capacité de facturer jusqu'au frais maximum spécifié.

Architecture d'Oracle hors chaîne pour StarkNet

STRK spécifiquement pour les opérations de séquenceur. Cela soulève d'importantes questions de gouvernance technique : comment la communauté peut-elle vérifier que les séquenceurs calculent les frais STRK selon ces devis d'oracle ?

Pour plus de transparence, les devis des oracles devraient être disponibles au public, permettant la vérification communautaire des calculs des frais de séquenceur. Bien que l'intégration des oracles on-chain fournirait de plus fortes garanties, l'approche actuelle représente un compromis pragmatique qui tente d'équilibrer la complexité technique avec les exigences de confiance de la communauté.

Exigences du mécanisme d'inclusion de force

Le mécanisme de Force Inclusion présente un cas d'utilisation plus convaincant pour l'intégration des oracles. Lorsque les utilisateurs déclenchent la Force Inclusion depuis L1 ( pour contourner les séquenceurs L2 ), ils doivent payer des frais d'exécution L2 au niveau L1. Par exemple, la fonction depositTransaction d'Optimism brûle du gaz en fonction de la limite de gaz L2 spécifiée, facturant effectivement de l'ETH sur L1. De même, la fonction requestL2Transaction de zkSync calcule les coûts de transaction L2 de base et nécessite suffisamment d'ETH dans la transaction L1.

Si ces protocoles L2 mettent en œuvre des paiements de frais en tokens natifs, les mécanismes d'Inclusion Forcée font face à un défi technique critique : comment déterminer équitablement les frais ETH sur L1 pour des transactions qui coûteraient normalement des tokens L2 ? Sans des taux de change précis, cela pourrait soit pénaliser injustement les utilisateurs d'Inclusion Forcée par des frais excessifs, soit permettre aux attaquants d'exploiter des frais artificiellement bas.

Ce scénario spécifique présente un cas d'utilisation convaincant pour l'intégration des oracles - permettant aux contrats L1 de calculer équitablement les frais pour les transactions d'inclusion forcée.

Alternativement, les protocoles L2 pourraient se standardiser sur leurs jetons natifs pour les transactions régulières et les transactions d'inclusion forcée, éliminant ainsi le besoin de conversion inter-devises. Cependant, les coûts de disponibilité des données restent libellés en ETH, créant un modèle de frais hybride où les transactions d'inclusion forcée nécessitent à la fois des ETH ( pour les données ) et des jetons L2 ( pour l'exécution ) - un défi technique que les développeurs L2 doivent relever lors de la mise en œuvre des modèles de frais de jetons natifs.

Synthèse Technique

• Les jetons natifs de Layer 2 peuvent remplir plusieurs fonctions techniques, le paiement des frais représentant une expansion significative de l'utilité au-delà de la gouvernance.

• L'avantage principal des modèles de frais de jetons natifs est d'établir une utilité claire des jetons avec des mécanismes déflationnistes potentiels grâce à la mise en œuvre de l'EIP-1559.

• Les inconvénients techniques incluent une exposition accrue aux risques de séquenceur, des frictions dans l'expérience utilisateur et des barrières d'interopérabilité dans l'écosystème L2.

• Les modèles de frais hybrides prenant en charge à la fois les ETH et les tokens natifs peuvent préserver l'expérience utilisateur et l'interopérabilité tout en permettant l'utilité des tokens.

• StarkNet est à l'avant-garde d'une approche hybride avec le soutien des frais de jetons STRK, mettant en œuvre des flux de prix d'oracle hors chaîne pour les séquenceurs.

• L'autorité du séquenceur reste une considération technique fondamentale - les séquenceurs conservent un pouvoir significatif sur l'inclusion des transactions et la détermination des frais, contraints uniquement par les frais maximaux spécifiés par l'utilisateur.

• L'intégration des oracles offre des avantages limités pour les transactions standard mais devient critique pour les mécanismes d'inclusion forcée où la conversion entre devises affecte la sécurité et l'équité.

• Les implémentations d'inclusion forcée avec des frais de jetons natifs créent des défis techniques complexes, nécessitant potentiellement que les utilisateurs paient à la fois ETH ( pour la disponibilité des données ) et des jetons L2 ( pour les frais d'exécution ) dans une seule transaction.