Numéro de bloc Ethereum : comprendre la hauteur, le hash et l’état

Un numéro de bloc Ethereum indique une hauteur de bloc. Le hash d’un bloc est dérivé de ses données, tandis que son horodatage décrit le moment associé au bloc. Ces champs répondent à des questions différentes, même lorsqu’ils figurent dans le même enregistrement.

Cette distinction devient utile pour lire l’état d’un compte. Une demande de solde exige davantage de contexte qu’une adresse : son paramètre de bloc détermine la hauteur demandée. Choisir un numéro explicite rend cette sélection visible et permet de comprendre ultérieurement à quelle hauteur la requête se rapportait.

Numéro et hash de bloc : deux rôles distincts

Pour les requêtes portant sur l’état d’Ethereum, la documentation JSON-RPC précise que le paramètre de bloc détermine la hauteur du bloc. Un numéro sert donc à sélectionner une hauteur. Le hash entretient une autre relation avec l’enregistrement : il est dérivé cryptographiquement des données du bloc.

Dans l’objet bloc documenté par JSON-RPC, le hash est représenté sur 32 octets. Une exception explicite concerne les blocs en attente, pour lesquels le champ hash vaut null. Il faut conserver cette réserve avec la définition du champ, plutôt que de supposer que toute réponse représentant un bloc contient un hash renseigné.

Lorsque vous examinez un enregistrement, identifiez séparément le numéro et le hash. À côté du numéro, demandez-vous quelle hauteur a été sélectionnée. À côté du hash, demandez-vous quel hash de bloc la réponse indique. Cette lecture distingue les rôles sans transformer une hauteur en promesse d’identité irréversible du bloc.

La relation entre le hash et les données du bloc est expliquée dans la documentation Ethereum sur les blocs. Elle sert ici à distinguer les champs ; cet article ne constitue pas un guide des confirmations ou de la finalité.

Pourquoi l’horodatage diffère de la hauteur

Le champ timestamp de l’objet bloc indique l’horodatage Unix du moment où le bloc a été assemblé. Il décrit un repère temporel associé au bloc, plutôt que la hauteur sélectionnée par une requête d’état. Il faut également le distinguer d’une note indiquant quand vous avez récupéré la réponse.

Ethereum divise le temps en créneaux de douze secondes, appelés slots. Toutefois, la documentation explique que certains créneaux peuvent rester vides lorsque les validateurs sont hors ligne au moment où ils doivent proposer un bloc. Ces créneaux de douze secondes ne garantissent donc pas un intervalle de douze secondes entre chaque paire de blocs produits.

Une déduction limitée découle de ces deux éléments : multiplier un nombre de blocs par douze secondes ne garantit pas de retrouver l’horodatage d’un bloc. Cela ne signifie pas que chaque intervalle diffère et ne fournit pas non plus une autre formule de reconstitution. Pour étudier un bloc précis, conservez son horodatage indiqué à côté de son numéro, plutôt que de remplacer l’un par une estimation à intervalle fixe.

Choisir une hauteur pour une requête d’état

Le paramètre de bloc accepte un numéro entier encodé sous forme de chaîne hexadécimale. Les quantités JSON-RPC utilisent une représentation hexadécimale compacte précédée de 0x. Dans les exemples hypothétiques ci-dessous, la hauteur décimale 1 024 s’écrit 0x400.

La balise latest sélectionne, quant à elle, le dernier bloc proposé dans le contexte du nœud qui répond. Séparément, eth_blockNumber renvoie le numéro du bloc courant auquel se trouve le client. Il convient de traiter cette valeur comme une observation relative au client, plutôt que comme une mesure établie indépendamment à l’échelle du réseau.

Ces définitions permettent une autre déduction : conserver un paramètre entier explicite maintient la hauteur demandée entre plusieurs requêtes, tandis que répéter latest renouvelle une sélection relative. Cette conclusion concerne la hauteur demandée. Elle ne garantit ni une identité immuable du bloc, ni des réponses identiques, ni des valeurs différentes à deux hauteurs distinctes.

Les descriptions des méthodes et les conventions des paramètres figurent dans la documentation JSON-RPC d’Ethereum. Elles établissent le mécanisme de sélection ; cette explication n’établit pas quelles hauteurs historiques un fournisseur donné peut prendre en charge.

Séparer les informations du bloc de la question sur l’état

eth_getBlockByNumber renvoie des informations sur un bloc sélectionné par son numéro. Le rôle de cette méthode permet de distinguer une demande portant sur l’enregistrement du bloc d’une demande portant sur le solde d’un compte à une hauteur choisie.

eth_getBalance renvoie le solde du compte à l’adresse indiquée. Son résultat doit être conservé avec cette adresse et le paramètre de bloc sélectionné. Cette méthode n’est pas une méthode générale de consultation des soldes de jetons : l’exemple reste donc un exercice de lecture du solde d’un compte.

Pour les requêtes concernant des contrats, eth_call figure également parmi les méthodes dotées d’un paramètre de bloc. Elle exécute un appel de message sans créer de transaction sur la blockchain. Cette définition décrit le fonctionnement de l’appel ; elle ne garantit pas qu’un appel quelconque produira un résultat avec succès.

Si votre point de départ est une fiche de transaction, notre guide pour lire une transaction Ethereum dans un explorateur de blocs apporte un contexte complémentaire. Ici, l’objectif reste de choisir et de consigner la hauteur d’une requête.

Deux fiches de requête hypothétiques

Imaginons une fiche pédagogique concernant un réseau défini pour l’exercice et un compte A. Toutes les valeurs de cet exemple sont fictives. Aucune requête n’a été exécutée et la fiche ne présente pas de données réelles de compte.

• Fiche A : méthode eth_getBalance ; adresse du compte A ; paramètre de bloc 0x400, soit la hauteur décimale 1 024 ; résultat laissé vide.
• Fiche B : méthode eth_getBalance ; adresse du compte A ; paramètre de bloc latest ; résultat laissé vide.

La fiche A demande le solde du compte à une hauteur explicitement sélectionnée. La fiche B utilise la sélection du dernier bloc proposé. Laisser les résultats vides permet d’isoler le mécanisme : les instructions de sélection diffèrent avant même de considérer une réponse chiffrée.

Ajoutons maintenant une entrée distincte pour l’enregistrement du bloc à la hauteur 1 024, avec des espaces réservés au hash et à l’horodatage renvoyés. Gardez ces champs séparés de la réponse concernant le solde. Cette organisation relie la hauteur, l’enregistrement du bloc et la question sur l’état, sans traiter le hash ou l’horodatage comme une autre façon d’écrire la hauteur.

Si vous reprenez cette fiche plus tard, conservez les paramètres d’origine et consignez séparément toute nouvelle observation. L’exemple ne suppose ni que les résultats doivent différer, ni que les requêtes historiques seront disponibles, ni que le maintien d’une hauteur garantit une identité inchangée du bloc.

Liste de contrôle pour interpréter une requête consignée

1. Identifiez séparément le numéro de bloc, le hash du bloc et l’horodatage.
2. Notez la méthode ainsi que le compte ou les données d’appel examinés.
3. Conservez le paramètre entier exact ou la balise relative utilisée.
4. Si vous affichez une hauteur hexadécimale en décimal, rendez la correspondance explicite.
5. Distinguez une réponse contenant les informations d’un bloc d’une réponse à une requête d’état.
6. Séparez la hauteur demandée des affirmations concernant la disponibilité chez un fournisseur ou l’identité immuable du bloc.

Contenu pédagogique préparé avec l’aide de l’IA. La fiche hypothétique illustre la lecture du contexte d’une requête.