Frame transactions EIP-8141 : ce qui changerait pour le gas
Votre compte approuve, un sponsor paie votre gas, votre appel part : dans le brouillon EIP-8141, tout tiendrait dans une transaction. Que reste-t-il aux bundlers ?
EN 30 SECONDES
Une frame transaction est le type de transaction que propose EIP-8141 : une liste d’appels pour le contrôle du compte, le paiement du gas et les actions. C’est un brouillon sans date confirmée. Les paymasters n’y déposent plus de caution, et le mot « bundler » n’y apparaît pas.
À RETENIR · 3
- Dans le brouillon EIP-8141, une transaction contient de 1 à 64 frames : le compte approuve, quelqu’un accepte de payer, puis les appels s’exécutent.
- Le brouillon n’a ni UserOperation, ni contrat EntryPoint, ni staking des paymasters. Le mot « bundler » n’y apparaît pas.
- Dans le mempool public, seul le paymaster canonique, reconnu à son code exact, peut garder plusieurs transactions en attente à la fois. Les autres, une seule.
Sur cette page
Ce que change une frame transaction EIP-8141
EN BREF Dans le brouillon 8141, une seule transaction fait tout le travail : le compte donne son accord, quelqu’un accepte de payer, puis les actions partent.
LES MOTS À CONNAÎTRE
- Frame transaction
- Le type de transaction proposé par EIP-8141 : une liste d’appels, les frames, pour la validation, le paiement du gas et l’exécution.
- Paymaster
- Un contrat qui accepte de payer le gas (les frais du réseau) de la transaction de quelqu’un d’autre.
- Mempool
- La salle d’attente des transactions. Les nœuds les y contrôlent avant qu’un bloc ne les inclue.
EIP-8141 est un brouillon, prévu pour Hegota, une mise à jour du mainnet sans date confirmée (chaque L2 a son calendrier). Noms et règles peuvent encore changer.
Une Frame transaction Le type de transaction proposé par EIP-8141 : une liste d’appels, les frames, pour la validation, le paiement du gas et l’exécution. Voir le glossaire (type 0x06) est une liste de 1 à 64 frames, chacune étant un appel associé à un mode.
EN CLAIR
Une frame VERIFY ne fait que lire et n’agit que via APPROVE, un nouvel opcode (une instruction de base de la machine). Une frame SENDER agit au nom du compte ; une frame DEFAULT, au nom d’une adresse du protocole, 0xaa, nommée ENTRY_POINT.
APPROVE peut approuver l’exécution, le paiement ou les deux, comme drapeaux valables pour toute la transaction. Sans approbation du paiement à la fin, la transaction est invalide. Un drapeau natif peut aussi faire réussir toutes les actions, ou aucune.
ÉTAPE PAR ÉTAPE
Étape 1. Frame 0 : contrôle du compte. VERIFY : le compte vérifie la signature et approuve.
- Frame 0 : contrôle du compte VERIFY : le compte vérifie la signature et approuve.
- Frame 1 : contrôle du sponsor VERIFY : le sponsor vérifie que la frame 2 lui verse le bon montant de tokens, puis approuve le paiement. La spec note qu’il accepte un risque de front-running.
- Frame 2 : payer le sponsor SENDER : le compte paie les frais en token.
- Frame 3 : l’appel voulu SENDER : l’appel voulu.
- Frame 4 : solder les comptes DEFAULT : le sponsor rembourse ou convertit, comme l’ancien postOp.
Mon rapprochement, côté ERC-4337 : la validation devient des frames VERIFY, postOp une frame DEFAULT, le contrat EntryPoint de la logique du protocole. La UserOperation disparaît.
OBJET OBTENU
La transaction est l’opération
Une adresse sans code reçoit un « code par défaut ». Elle approuve avec la signature secp256k1 d’une clé d’EOA : elle peut regrouper ses actions et être sponsorisée sans déléguer. Une frame qui vise un compte 7702 exécute le code de son délégué.
Il n’y a pas de liste d’autorisations 7702, et c’est voulu : selon la justification, elle « heavily relies on ECDSA cryptography », ce qui ne répond pas à l’objectif post-quantique.
Ce que deviennent les bundlers et les paymasters
EN BREF Le brouillon 8141 ne parle jamais de bundlers, et il transforme les paymasters en frames pay, sans staking ni réputation.
Les frame transactions vont directement dans le Mempool La salle d’attente des transactions. Les nœuds les y contrôlent avant qu’un bloc ne les inclue. Voir le glossaire public. Les nœuds ne simulent (exécutent à blanc) que le préfixe de validation : les frames jusqu’à celle qui fixe le payeur incluse. La suite échappe à ces règles, mais ne peut pas contenir d’autre frame VERIFY.
Les Paymaster Un contrat qui accepte de payer le gas (les frais du réseau) de la transaction de quelqu’un d’autre. Voir le glossaire changent le plus. ERC-4337 garde leur dépôt dans l’EntryPoint, leur demande de limiter leur stockage ou de déposer une caution, et recommande aux bundlers un système de réputation. Le brouillon 8141 « removes staking and reputation entirely » : il les supprime.
À la place, un paymaster qui veut plusieurs transactions en attente à la fois dans le mempool public doit être le paymaster canonique. Les nœuds le reconnaissent à son code exact, conçu pour que l’ether n’en sorte que comme paiement de gas ou après un délai.
1
transaction en attente à la fois pour tout autre paymaster, dans le mempool public
Source : EIP-8141, brouillon au 7 octobre 2026.
Mon interprétation, pas celle de la spec : le bundler continue de relayer ce que refuse le mempool public, comme un paymaster non canonique avec plusieurs transactions en attente. Le brouillon précise que ces transactions « may be accepted into a local or private mempool » : elles peuvent passer par un mempool local ou privé.
Le paymaster canonique a un seul signataire secp256k1 et refuse les signatures de contrat. Dans le préfixe, la validation ne lit que le stockage de l’émetteur (SLOAD). TIMESTAMP, BALANCE, SELFBALANCE et SSTORE sont interdits.
Exceptions : SSTORE vers le stockage de l’émetteur dans la première frame de déploiement, TIMESTAMP seulement dans la frame d’expiration du protocole, et le code du paymaster canonique, admis par correspondance de code.
Sources : EIP-8141 (brouillon), ERC-4337, ethereum.org, Hegota.
NIVEAU TERMINÉ
Ce que vous savez maintenant
- Comment une frame transaction découpe le travail en frames : le compte approuve, un sponsor accepte de payer, puis les appels partent.
- Ce qu’il faut à un paymaster pour garder plusieurs transactions en attente, et ce que le brouillon laisse aux bundlers, à mon sens.
Vérifiez par vous-même
Touchez ou cliquez une question pour voir la réponse.
Un paymaster qui n’est pas le paymaster canonique veut cinq transactions sponsorisées en attente dans le mempool public. Est-ce possible ?
Non. Dans le brouillon, il n’a droit qu’à une transaction en attente à la fois. Les autres peuvent passer par un mempool local ou privé.
Ingénieur web3 x IA, ancien CTO d’Integra. Auteur nommé (1 sur 5) d’ERC-3643, premier auteur d’ERC-6960, co-auteur d’ERC-7410 et co-auteur d’ERC-8203, encore à l’état de brouillon.
Un projet à livrer ou un poste à pourvoir ?
Parlons de votre besoinSuivre les notes techniques
Recevez les nouveaux articles sur l’IA en production et les smart contracts par email.