Ethereum : l’EIP-7843 propose un accès direct au numéro de slot depuis les contrats

Une consultation pour rendre le temps du consensus accessible

L’EIP-7843 atteint le 1er novembre 2026 la date de fin de dernière consultation indiquée par son document officiel. Créée le 6 décembre 2024 par Marc Harvey-Hill, elle reste au statut Last Call lors de la vérification. Cette proposition Ethereum introduirait une instruction permettant à un contrat de connaître directement le numéro de slot correspondant au bloc courant. Il s’agit d’un jalon de revue technique, pas de l’annonce d’un nouvel outil déjà activé pour toutes les applications.

Le slot est un repère du calendrier du consensus, distinct d’un simple numéro de bloc. Pour obtenir ce repère dans un contrat, le document décrit actuellement deux possibilités : le calculer à partir de l’horodatage ou le fournir avec une preuve liée à la racine d’un bloc de consensus. La première méthode oblige à inscrire une hypothèse sur la durée des slots dans le code. La seconde demande une vérification supplémentaire, donc un coût de calcul que le projet cherche à éviter.

Une instruction à deux gas et un champ supplémentaire

L’instruction proposée, appelée SLOTNUM, utiliserait le code opération 0x4b. Elle ajouterait sur la pile une valeur correspondant au slot du bloc, avec un coût fixe de deux gas dans la spécification. Ce montant est celui de l’instruction seule : il ne représente ni le prix complet d’une transaction ni une garantie de réduction des frais pour tous les usages. La proposition rapproche ce coût de celui d’autres instructions élémentaires comparables.

L’information serait calculée par le client de consensus, puis transmise à la couche d’exécution. Le projet prévoit un champ slotNumber dans l’en-tête ainsi que dans les objets échangés par l’Engine API, l’interface entre ces deux couches. Il décrit les versions de méthodes nécessaires pour construire, recevoir et choisir les blocs avec cette donnée. Une application ne devrait ainsi plus recopier dans son propre code une règle de conversion dépendant de la durée supposée d’un slot.

Préparer une évolution sans promettre des blocs plus rapides

La motivation principale est de réduire ce couplage entre les contrats et le calendrier du réseau. Si la durée des slots changeait à l’avenir, un calcul fixé à l’avance pourrait produire un résultat inadapté. Exposer directement le numéro fourni par le consensus permettrait de conserver cette abstraction. Le document explique aussi que placer l’information dans l’en-tête doit garder le bloc autonome pour les systèmes prouvant l’exécution, sans leur demander une entrée supplémentaire séparée.

Cette proposition ne fixe toutefois aucune nouvelle durée de slot et ne prouve pas qu’un raccourcissement a été décidé. Le texte ne fournit pas de cas de test détaillés et ne recense pas de problème de compatibilité dans sa section dédiée ; ces indications ne remplacent pas une démonstration de déploiement. Pour les développeurs, l’enjeu reste un accès plus direct à une information du consensus. L’échéance du 1er novembre concerne l’examen de ce mécanisme, distinct de son éventuelle adoption et de sa disponibilité effective sur le réseau.