Tuven Chain : Une nouvelle solution aux problèmes de paiement des frais de Gas et analyse des risques de sécurité associés

Presque tous ceux qui ont utilisé un portefeuille en chaîne ont rencontré ce problème : un compte rempli de jetons, souhaitant effectuer un transfert ou interagir avec un contrat intelligent, mais la transaction échoue en raison de frais de Gas insuffisants. Sur les principales chaînes publiques compatibles avec EVM, les frais de Gas des transactions doivent être payés en utilisant le jeton natif de la chaîne, ce qui oblige les nouveaux utilisateurs à acquérir des jetons natifs supplémentaires pour initier des interactions. De plus, les frais de Gas fluctuent dynamiquement en fonction du niveau de congestion du réseau blockchain, rendant impossible pour les utilisateurs de prévoir avec précision le coût réel des frais avant la confirmation de la transaction. Cela constitue l'un des principaux obstacles à l'adoption à grande échelle de Web3.

Cet article analysera les solutions de frais de Gas existantes dans l'industrie Web3 et examinera la nouvelle solution de la chaîne publique RWA Tuven Chain sous différents angles, notamment la logique de mise en œuvre technique, les innovations architecturales et les risques potentiels, afin de fournir des références aux développeurs de chaînes publiques et aux auditeurs de sécurité.

I. Solutions de frais de Gas principales

1.1 Mécanisme de paiement Paymaster d'ERC-4337 (abstraction de compte)

Le Paymaster est un contrat spécial défini dans le cadre d'ERC-4337, qui permet de payer les frais de Gas en lieu et place de l'utilisateur lors de l'exécution d'une UserOperation. Ainsi, l'utilisateur n'a pas besoin de détenir de la monnaie native de la chaîne lors de l'envoi de transactions, ce qui abaisse le seuil d'entrée pour les nouveaux utilisateurs. Le flux de travail central du paiement des frais de Gas est le suivant :

(1) L'utilisateur initie l'opération : l'utilisateur signe et soumet une opération utilisateur (UserOperation) dans son portefeuille intelligent.

(2) Emballage et vérification : le Bundler (emballeur) collecte plusieurs opérations et les envoie au contrat de paiement et au contrat d'entrée (Entrypoint).

(3) Intervention du Paymaster : le contrat Paymaster vérifie s'il accepte de payer les frais de Gas pour cette opération.

(4) Règlement des frais : la transaction est exécutée sur la chaîne, l'Entrypoint déduit le jeton natif (comme l'ETH) du compte de dépôt du Paymaster en tant que frais de Gas.

(5) Compensation ultérieure : les modèles de paiement courants incluent le parrainage total, où le projet couvre entièrement les frais de Gas pour les nouveaux utilisateurs ou des activités spécifiques ; le paiement par jeton, où l'utilisateur n'a pas de jeton natif (comme l'ETH) mais peut payer les frais de Gas avec des USDT ou USDC dans son portefeuille, le Paymaster effectuant automatiquement l'échange en arrière-plan ; et le paiement conditionnel, où le projet définit des règles pour n'ouvrir le paiement qu'aux utilisateurs détenant des NFT spécifiques, ayant accompli des tâches spécifiques ou utilisant des jetons d'application spécifiques.

Cette solution présente des limites, car les comptes externes ordinaires (EOA) ne peuvent pas l'utiliser directement, les utilisateurs devant changer ou mettre à niveau vers un portefeuille d'abstraction de compte.

1.2 Modèle de transaction métam et de relais

C'est une autre solution utilisée dans la blockchain pour réduire le seuil d'utilisation des utilisateurs, permettant des "frais de Gas nuls" ou le paiement des frais de mineur. Les transactions métam signifient que l'utilisateur ne soumet pas directement la transaction à la blockchain, mais signe hors chaîne un message de "métadonnées" contenant l'intention et les données de l'opération avec sa clé privée. Le relais est responsable de la collecte des signatures hors chaîne des utilisateurs, agissant comme l'initiateur réel de la transaction sur la chaîne et payant les frais de Gas, diffusant la transaction sur la blockchain. Le flux de travail central est le suivant : (1) Signature de l'utilisateur : l'utilisateur signe localement l'intention (comme un transfert, un appel de contrat) sans consommer de Gas sur la chaîne (2) Soumission au service hors chaîne : l'utilisateur envoie la signature et les données au relais (qui peut être le serveur officiel de DApp ou un service tiers) (3) Emballage du relais : le relais encapsule cette signature en une véritable transaction sur la chaîne, signe avec son propre compte de portefeuille et paie les frais de Gas (4) Vérification par le contrat intelligent : le contrat intelligent cible reçoit la transaction, analyse et vérifie la signature originale de l'utilisateur, et exécute la logique correspondante si tout est correct. Cependant, cette solution présente des risques de centralisation et des problèmes d'attaques par répétition : si le relais tombe en panne ou refuse intentionnellement certaines demandes d'utilisateurs, ces derniers ne pourront pas envoyer de transactions ; de plus, le relais peut voir l'intention de transaction de l'utilisateur, ce qui peut être exploité pour des transactions de course. Si la signature de l'utilisateur est obtenue par un attaquant et que le contrat manque de vérification de Nonce et de ChainID, cela pourrait entraîner des attaques par répétition.

Les solutions ci-dessus n'ont pas modifié directement la logique de facturation au niveau d'exécution du consensus de la chaîne. Tuven Chain tente de modifier la logique d'exécution sous-jacente pour permettre le paiement de frais de Gas fixes en utilisant des jetons personnalisés, sans changer de portefeuille ordinaire ni modifier les applications, c'est-à-dire en remplaçant les types de frais et en verrouillant les prix.

II. Logique d'implémentation centrale de Tuven Chain

Tuven Chain est un fork de la chaîne Arc de Circle, héritant de la capacité de paiement des frais de Gas en stablecoin d'Arc, l'innovation centrale résidant dans la réutilisation inverse du mécanisme de vérification de liste noire existant. Un registre SponsorRegistry est construit, combiné avec des certificats d'identité SBT pour contrôler l'accès des utilisateurs, complétant la logique de facturation et d'accès aux transactions. 2.1 Composant central SponsorRegistry.sol / sponsor_registry.rs SponsorRegistry est le contrat central pré-déployé, servant de "tableau de frais de Gas" global, stockant plusieurs configurations de facturation de Gas. La disposition de stockage des données est strictement fixée, le code Rust du niveau d'exécution accédant directement aux données via les emplacements de stockage.

// SponsorRegistry.sol —— La disposition est "gelée", le gestionnaire lit directement par slot, l'ordre ne peut pas être modifié struct GasPlan { address token; uint256 feePerTx; address feeBeneficiary; }address public multisig;                        // slot 0mapping(uint256 => GasPlan) public plans;       // slot 1: planId → forfait mapping(address => uint256) public sourcePlan;  // slot 2: SBT → planId pouvant être attribuémapping(address => uint256) public userPlan;    // slot 3: détenteur → planId (0=non dans le forfait )// Point d'entrée d'écriture unique : SBT autorisé pour ajouter/enlever une adresse de la liste function setSponsored(address who, bool on) external {    uint256 plan = sourcePlan[msg.sender];      // L'appelant doit être un SBT autorisé    if (plan == 0) revert NotAuthorizedSource();    userPlan[who] = on ? plan : 0;              // on=ajouter à la liste; off=réinitialiser 0}// Rust: sponsor_registry.rs —— Le niveau d'exécution lit selon la même disposition, les deux côtés testent croisés pour verrouiller const PLANS_MAPPING_SLOT=1; const USER_PLAN_MAPPING_SLOT=3; // Adresse: keccak256(key . slot)

Ici, plans[planId] = { token : quel type de monnaie, feePerTx : combien par transaction, feeBeneficiary : qui reçoit }. Lors du règlement, Tuven Chain vérifie d'abord à quel forfait appartient l'utilisateur, si l'utilisateur n'est pas dans un forfait (userPlan[you]==0), il paie alors normalement avec la stablecoin native USDX ; s'il est dans un forfait, il paie avec le jeton spécifié par le forfait. Il est important de noter que l'USDX est un contrat de stablecoin de Circle, mais le pouvoir d'émission / de gel / de suspension est entre les mains de l'opérateur, et est isolé de l'USDC réel. Sa "stabilité" provient de la stratégie de l'opérateur, et non d'un soutien de réserve.

2.2 Modification de la logique de facturation au niveau d'exécution sous-jacent

(handler.rs)// Simule une "liste noire" : fait un "SLOAD" non mesuré sur le tableau des forfaits, décide pour chaque transaction quel type de monnaie utiliser fn charge_sponsored_gas(&self, evm, caller) -> Result<bool> {      journal.load_account(SPONSOR_REGISTRY_ADDRESS)?;  // Pré-chauffage, sinon une lecture froide SLOAD provoquera un panic      let plan_id = sload(REG, compute_user_plan_slot(caller))?;      if plan_id.is_zero() { return Ok(false); }      // Pas dans le forfait → payer normalement avec USDX      let token = sload(REG, compute_plan_slot(plan_id, PLAN_TOKEN_OFFSET))?;      if token.is_zero() { return Err(GAS_PLAN_UNCONFIGURED); }  // Pas de configuration de forfait → refus, pas de soutien      let fee = sload(REG, compute_plan_slot(plan_id, PLAN_FEE_OFFSET))?;      let bal = sload(token, compute_erc20_balance_slot(caller))?;      if bal < fee { return Err(INSUFFICIENT_GAS_TOKEN); }      // Pas assez de monnaie membre → refus      sstore(token, caller_slot, bal - fee)?;           // Déduire des frais fixes : le membre paie lui-même      sstore(token, benef_slot,  benef_bal + fee)?;      // Créditer le feeBeneficiary (sans rapport avec le gas)      Ok(true)                                          // true = payé avec la monnaie membre, USDX totalement exempt  }
// pre_execution synthétise une pré-paiement USDX pour que la vérification native passe ; reward_beneficiary est ensuite déduit, // et ne créditera pas le bénéficiaire en USDX——sinon cela équivaut à imprimer de l'argent à chaque transaction.

Ici, l'utilisateur déduit un montant fixe de jetons spécifiques pour chaque transaction, indépendamment de la quantité réelle de calcul consommée. Ce paramétrage augmente les frais de base de toute la chaîne, les frais de Gas supplémentaires étant à la charge des utilisateurs ordinaires d'USDX (non forfaitaires), le coût étant en réalité transféré à ces utilisateurs.

2.3 Insigne d'identité SoulboundToken.sol / DeployUserland.s.sol

// SoulboundToken.sol —— Insigne d'identité "non transférable" (ERC-5192)function issue(address to, uint256 id, string uri) external onlyIssuer {      _safeMint(to, id);  registry.setSponsored(to, true);   // Attribution immédiate à la liste des forfaits}function revoke(uint256 id) external onlyIssuer {      address owner = ownerOf(id);  _burn(id);      registry.setSponsored(owner, false);                     // Retrait immédiat de la liste}// Seules les opérations mint(from=0)/burn(to=0) sont autorisées, toute autre transaction est bloquée → ne peut pas être transféré, vendu function _update(...) internal override returns (address) {      if (from != address(0) && to != address(0)) revert Soulbound(); ...}// DeployUserland.s.sol —— Déploiement de la gestion des droits à un multisig (1-of-2 est une redondance de clé privée, pas un équilibre)registry.setSourcePlan(address(sbt), PLAN_ID);   // Autoriser SBT à lier le forfait n° 1 registry.setMultisig(address(multisig));         // admin confié à la gestion multisig // Risque : feeSigner par défaut = signataire admin (coffre et gestion ayant la même paire de clés privées)

Tuven Chain a réutilisé le mécanisme de liste noire existant d'Arc, combiné avec des certificats d'identité SBT pour contrôler l'accès des utilisateurs. Les caractéristiques de sa solution peuvent être résumées comme suit :

(1) Capacité de paiement des frais de Gas multi-jetons natifs de la chaîne Différente des solutions de paiement par contrat de niveau supérieur, la logique de facturation est descendue au niveau d'exécution du consensus, prenant en charge plusieurs forfaits en parallèle, permettant à différents utilisateurs d'identité d'utiliser différents jetons personnalisés pour payer les frais.

(2) Modèle de frais fixes par transaction Détaché du modèle de tarification traditionnel "Prix du Gas × Consommation de calcul", permettant de connaître à l'avance les frais de transaction.

(3) Haute compatibilité avec l'infrastructure existante Pas besoin de compte intelligent, pas besoin de modification de DApp, les portefeuilles EOA ordinaires comme MetaMask peuvent interagir directement.

(4) Réutilisation des mécanismes Réutilisation du chemin d'exécution de lecture de stockage de la liste noire existante de la chaîne, transformé de manière inverse en contrôle d'accès par identité, en réutilisant autant que possible le cadre de code sous-jacent existant.

Cependant, cette commodité repose sur de nombreuses hypothèses de confiance supplémentaires, les modifications du noyau sous-jacent, la conception des autorisations, le modèle économique et les composants inter-chaînes peuvent comporter des risques. La sémantique de la liste noire existante a été modifiée, l'ancienne logique d'interception, qui ne s'appliquait qu'aux scénarios de transfert, a été étendue pour couvrir les appels de contrats ordinaires, modifiant ainsi les frontières logiques. Les frais de paiement par jeton de forfait spécifiques nécessitent un audit de sécurité indépendant pour garantir qu'il n'y a pas de vulnérabilités dans la lecture et l'écriture de stockage, le calcul des soldes, afin d'éviter des conséquences graves telles que des anomalies de transaction, des forks de consensus de chaîne, ou des déductions anormales d'actifs.