définition stale

Qu’est-ce que l’expiration ? Pourquoi est-elle essentielle dans le Web3 ?

L’expiration correspond à l’invalidation d’une action ou d’une autorisation dès que des conditions prédéfinies sont atteintes, telles qu’une limite temporelle, un changement d’état ou une modification de l’environnement réseau. Dans le Web3, l’expiration joue un rôle clé en limitant les autorisations et les risques à des cadres « temporels et conditionnels » précis, ce qui réduit les abus et les attaques par rejeu.

L’expiration s’apparente à la date limite d’un coupon : une fois la période de validité dépassée, les ordres ne peuvent plus être exécutés, les signatures expirées ne permettent plus d’appeler les smart contracts et les autorisations expirées sont rejetées par le contrat. Ce mécanisme limite les usages abusifs et protège vos actifs.

Comment l’expiration se traduit-elle dans les ordres de trading ?

L’expiration d’un ordre est généralement déterminée par des « conditions temporelles et d’exécution ». Les trois stratégies d’ordre les plus courantes sont : GTC, IOC et FOK.

• GTC (Good-Til-Canceled) : l’ordre reste actif dans le carnet tant qu’il n’est pas exécuté ou annulé manuellement. Il n’y a pas d’expiration durant cette période.
• IOC (Immediate-Or-Cancel) : l’ordre est exécuté immédiatement dans la mesure du possible ; toute portion non exécutée est annulée instantanément. Cela confère à l’ordre une fenêtre de validité très brève.
• FOK (Fill-Or-Kill) : l’ordre doit être exécuté en totalité d’un seul coup, sinon il est annulé, évitant ainsi tout remplissage partiel.

Sur les interfaces de trading spot et dérivés de Gate, les stratégies d’exécution telles que IOC et FOK sont couramment disponibles. Choisir IOC permet à toute portion non exécutée de votre ordre d’expirer instantanément ; choisir FOK évite les exécutions partielles, renforçant la fiabilité de la stratégie.

Comment l’expiration est-elle définie pour les signatures et les autorisations ?

L’expiration des signatures et des autorisations est généralement gérée via une « date limite » ou une « fenêtre de validité ». De nombreuses DApps incluent un champ « deadline » dans les demandes de signature ; après cette échéance, la signature devient inutilisable.

EIP-2612 est une norme de « permit signature » qui permet d’approuver la dépense de tokens sans transaction on-chain. Elle intègre une date limite : passé ce délai, la signature expire et le contrat rejette toute tentative d’utilisation.

EIP-712 est une norme de signature structurée qui inclut dans la signature des champs essentiels comme l’ID de la chaîne, le domaine du contrat et l’heure d’expiration. Cela empêche les attaques par rejeu entre différents environnements : même copiée, une signature ne peut être utilisée si elle a expiré ou si le contexte ne correspond pas.

Lorsque votre wallet sollicite une signature, vérifiez la présence d’un champ de validité ou de deadline. Plus la validité est longue, plus la fenêtre de risque d’abus est grande ; des fenêtres plus courtes offrent une sécurité renforcée mais exigent une action rapide de votre part.

Comment l’expiration fonctionne-t-elle dans les smart contracts ?

Les smart contracts appliquent généralement l’expiration en validant les dates limites à l’entrée des fonctions. Une méthode courante consiste à vérifier si le timestamp du bloc courant est inférieur ou égal à la deadline ; sinon, l’appel de fonction échoue et l’action est considérée comme expirée.

Les timestamps des blocs sont définis par les validateurs et peuvent présenter de légères variations. Les contrats prévoient souvent des marges pour éviter les expirations prématurées tout en garantissant qu’aucune action ne soit possible après expiration. Les développeurs ajoutent fréquemment des champs comme « validUntil » dans les structures d’autorisation ou d’ordre pour une validation homogène.

Dans le modèle UTXO de Bitcoin, les scripts temporels définissent également la fenêtre de validité d’une transaction. Par exemple, un script peut imposer que des coins ne soient pas dépensés avant ou après une certaine date : les contraintes temporelles servent ainsi à gérer la validité des transactions.

Comment expiration, temps on-chain et nonce sont-ils liés ?

Le temps on-chain détermine « quand » un élément expire, tandis que le nonce détermine « si » une opération peut être rejouée.

Un nonce agit comme un compteur de transactions : chaque compte doit incrémenter le nonce de ses transactions. Si une nouvelle transaction avec le même nonce est acceptée par le réseau, la précédente est remplacée et retirée des mempools : la transaction précédente est alors considérée comme expirée.

Les timestamps de bloc sont fournis par les producteurs de blocs et ne correspondent pas à des temps réels absolus, mais ils sont essentiels pour déterminer l’expiration. Les contrats s’appuient sur l’heure du bloc pour vérifier l’expiration, évitant ainsi toute dépendance à des horloges externes.

Comment l’expiration diffère-t-elle selon les protocoles ?

Sur Ethereum et les chaînes compatibles, l’expiration est principalement définie au niveau du contrat et de la DApp, souvent via des champs « deadline » et le « remplacement de nonce » pour des raisons de sécurité. Les autorisations de tokens par défaut n’expirent pas, d’où l’adoption fréquente d’EIP-2612 pour introduire des dates d’expiration.

Sur Bitcoin, les scripts temporels et les mécanismes de verrouillage déterminent la fenêtre de validité des transactions de façon plus fondamentale, précisant quand des coins peuvent être dépensés avant ou après certaines dates.

Sur Solana, les transactions peuvent spécifier une « dernière hauteur de bloc valide » ; passé ce bloc, la transaction devient invalide, offrant ainsi une fenêtre de validité basée sur le temps ou la hauteur de bloc. Sur certaines solutions Layer 2, la logique s’apparente à celle d’Ethereum, l’expiration étant principalement gérée au niveau du contrat et de l’application.

Quels risques l’expiration comporte-t-elle ? Comment les limiter ?

L’expiration génère deux risques principaux : l’expiration prématurée (entraînant l’échec d’une opération) et l’expiration tardive (allongeant la fenêtre d’abus possible).

1. Vérifiez la période de validité des signatures ou des ordres. Des durées longues augmentent les risques d’abus ; des durées courtes peuvent ne pas laisser assez de temps pour agir.
2. Choisissez une stratégie d’ordre adaptée : utilisez IOC pour une exécution rapide et éviter les ordres non exécutés persistants ; privilégiez FOK pour exiger un remplissage total et limiter les risques de remplissage partiel.
3. Passez régulièrement en revue la liste de vos autorisations. Les autorisations de tokens par défaut n’expirent pas : conserver des autorisations illimitées sur de longues périodes accroît le risque de vol. Privilégiez les autorisations avec deadline ou révoquez proactivement les permissions dans votre wallet ou dans les paramètres d’autorisation de la DApp.
4. Surveillez les transactions en attente. Les transactions non confirmées qui restent dans les mempools doivent être annulées ou remplacées avec des frais plus élevés pour éviter une exécution ultérieure inattendue.

Faites preuve de vigilance lors des opérations de sécurité sur vos fonds. L’expiration n’élimine pas automatiquement le risque : les autorisations longue durée non expirées nécessitent une gestion active.

Comment définir l’expiration d’un ordre et vérifier l’expiration des autorisations sur Gate ?

Dans l’interface de trading de Gate, votre choix de stratégie d’exécution détermine directement comment les ordres expirent :

1. Sélectionnez le type d’ordre et la stratégie time-in-force dans les formulaires d’ordre spot ou dérivés avancés. Vous pouvez choisir IOC pour que les parties non exécutées expirent immédiatement ou FOK pour que les ordres expirent instantanément s’ils ne sont pas entièrement exécutés.
2. Définissez le prix et la quantité avant de confirmer l’ordre. Avec IOC, le système confronte votre ordre à la profondeur de marché actuelle ; toute portion non exécutée est automatiquement annulée. Avec FOK, les ordres sont annulés s’ils ne sont pas totalement exécutés, évitant ainsi tout remplissage partiel.
3. Consultez l’historique de vos ordres pour vérifier si certains ont expiré en raison des paramètres de stratégie : cela vous aidera à optimiser vos choix de validité et d’exécution à l’avenir.

Concernant l’expiration des autorisations, si vous interagissez avec des DApps via le portail Web3 ou le wallet de Gate, vérifiez si les autorisations comportent des deadlines. Pour les autorisations illimitées sans date d’expiration, auditez régulièrement et révoquez les permissions inutilisées via la page de gestion des autorisations.

Quel est le lien entre expiration des sources de données et expiration classique ?

L’obsolescence d’une source de données constitue une autre forme d’« expiration ». Les oracles fournissent généralement des timestamps ; les contrats vérifient si les données reçues sont suffisamment récentes. Dans le cas contraire, les prix sont considérés comme « obsolètes » et les appels sont rejetés : il s’agit d’une expiration au niveau des données.

Fin 2025, les principaux protocoles DeFi renforcent la validation de la fraîcheur des flux de prix et de taux d’intérêt, imposant des mises à jour fréquentes pour limiter les risques en période de forte volatilité. Pour les NFT et métadonnées hébergés sur des serveurs centralisés, les liens rompus font que les applications considèrent le contenu comme expiré : le résultat est identique à une expiration classique.

Au niveau des nœuds, les clients blockchain tendent à ne plus stocker indéfiniment les données historiques. Les données très anciennes peuvent ne plus être accessibles depuis des nœuds standards ; les développeurs doivent recourir à des services d’archive ou à un indexage personnalisé pour éviter toute interruption d’activité liée à l’« expiration » de l’accès aux données.

Principaux enseignements et recommandations pratiques sur l’expiration

L’expiration réduit la fenêtre effective pour les ordres, signatures, autorisations et données : il s’agit d’un outil fondamental de sécurité et de gouvernance dans le Web3. En comprenant les limites définies par le temps et l’état, en exploitant les contrôles d’expiration au niveau des contrats et le remplacement de nonce, en combinant stratégies d’ordre sur les plateformes d’échange et gestion des autorisations dans les DApps, vous pouvez concilier efficacité d’exécution et maîtrise des risques d’abus ou de rejeu. Révoquez systématiquement les autorisations longue durée inutilisées, choisissez la validité de vos ordres selon la stratégie, vérifiez explicitement la fraîcheur des données dans les contrats et auditez en continu votre activité : transformez ainsi l’« expiration » d’un risque latent en protection proactive.

FAQ

Qu’est-ce qu’un mode d’expiration ?

Un mode d’expiration décrit la manière précise dont une fonction, un ordre ou une autorisation cesse de fonctionner. Dans le Web3, les modes d’expiration incluent l’expiration basée sur le temps (par exemple, timeout d’un ordre), l’expiration conditionnée par un paramètre (par exemple, variation de prix au-delà des seuils attendus), et l’expiration par révocation (par exemple, annulation manuelle d’une autorisation). Comprendre ces différents modes permet d’éviter des échecs de transaction ou des risques sur les fonds.

Quelle est la différence entre blocage et expiration ?

Le « blocage » (stalling) désigne le ralentissement ou l’immobilisation d’une transaction ; l’« expiration » signifie qu’une fonction cesse totalement de fonctionner ou devient invalide. L’expiration a un point final net (tel qu’un ordre atteignant sa date d’expiration), tandis que le blocage traduit une dégradation des performances. Un ordre peut finir par expirer à cause d’un blocage, mais ce sont deux notions distinctes.

Pourquoi les ordres expirent-ils automatiquement ?

L’expiration automatique des ordres est une protection intégrée généralement déclenchée par trois facteurs : le temps (fin de la période de validité), les conditions de marché (prix dépassant les seuils définis par l’utilisateur) ou des contraintes de bloc (dépassement d’une hauteur de bloc spécifiée). Ce mécanisme protège vos transactions d’une exécution dans des conditions de marché extrêmes.

Expiration d’autorisation et expiration d’ordre : est-ce la même chose ?

L’expiration d’une autorisation et celle d’un ordre sont deux concepts distincts. L’expiration d’une autorisation signifie que votre permission pour qu’un contrat utilise vos fonds a expiré ; l’expiration d’un ordre signifie que votre instruction de trading elle-même est devenue invalide. Une transaction peut être concernée par les deux : l’expiration de l’autorisation empêchera l’exécution même si l’ordre est valide ; l’expiration de l’ordre empêchera le remplissage même si l’autorisation subsiste.

Comment savoir si mon ordre a expiré ?

Pour déterminer si un ordre a expiré :

• Vérifiez si le statut de l’ordre indique « expiré » ou « invalide ».
• Vérifiez si la date d’expiration est dépassée.
• Consultez les détails et la raison de l’expiration sur des plateformes comme Gate.
• Vérifiez si votre ordre figure toujours dans les ordres ouverts pour la paire concernée.

Si votre ordre a expiré, vous devrez en créer un nouveau pour poursuivre votre trading.