eth_call exécute un appel de contrat sur un état sélectionné d’Ethereum, sans créer de transaction sur la blockchain. Une transaction suit un autre parcours : elle permet d’engager une modification de l’état du réseau, doit être diffusée et doit être incluse dans un bloc validé. Cette distinction explique pourquoi une simulation renseigne sur une exécution précise sans garantir la réussite d’une transaction ultérieure.
Pour comparer eth_call et une transaction, il faut conserver trois éléments ensemble : l’opération évaluée, l’état choisi pour l’évaluation et ce que le résultat permet réellement d’établir. Un aperçu réussi reste lié à ce contexte.
Exécuter sans enregistrer les changements dans la chaîne
La documentation JSON-RPC d’Ethereum décrit eth_call comme l’exécution d’un appel de message sans création de transaction sur la blockchain. Il y a donc bien une exécution : la méthode ne se contente pas de présenter une demande sans l’évaluer.
La différence entre exécution et persistance est essentielle. La documentation des transactions présente celles-ci comme le mécanisme par lequel un compte engage une mise à jour de l’état du réseau. En rapprochant ces deux éléments, on peut déduire que les changements simulés par eth_call ne sont pas enregistrés dans l’état de la blockchain Ethereum.
Ici, l’expression « lecture seule » décrit l’effet sur l’état persistant de la chaîne. Elle ne signifie pas que le code du contrat ne peut pas s’exécuter pendant la simulation. Même pour une opération destinée à modifier des données stockées, la question reste de savoir si cette modification devient partie intégrante de l’état de la blockchain.
Le bloc sélectionné fait partie du résultat
Une requête eth_call accepte un sélecteur de bloc. Les choix documentés comprennent un numéro de bloc entier et les balises latest, earliest, pending, safe et finalized. Pour une requête portant sur l’état d’Ethereum, le paramètre de bloc détermine la hauteur de bloc utilisée.
Il en découle qu’une description utile du résultat doit conserver ce contexte. Dire « l’appel a renvoyé cette valeur » omet une partie de la question posée. Dire « l’appel a renvoyé cette valeur avec ce sélecteur de bloc » préserve une condition nécessaire à son interprétation.
C’est une déduction fondée sur la structure de la requête. Elle ne signifie pas que deux sélecteurs différents produisent obligatoirement des réponses différentes : deux évaluations peuvent donner le même résultat sans rendre leur contexte superflu.
Choisir pending ne démontre pas non plus qu’une transaction a été incluse dans un bloc validé. Ce choix désigne le contexte d’état demandé ; il ne transforme pas un appel en transaction et n’établit aucune inclusion.
Quels paramètres conserver avec l’appel ?
L’état sélectionné n’est qu’une partie de la requête. L’objet d’appel documenté précise également la destination de l’exécution et les éléments qui lui sont fournis :
- from : une adresse d’émetteur facultative dans le contexte de l’appel.
- to : l’adresse vers laquelle l’exécution est dirigée.
- input : un champ facultatif qui identifie la méthode appelée et ses paramètres encodés.
- value : une valeur facultative fournie dans le contexte de l’appel.
- gas: un paramètre d’exécution facultatif dont certaines exécutions peuvent avoir besoin.
Ces champs se lisent dans le cadre de la définition d’eth_call. Certaines descriptions emploient le vocabulaire des transactions, mais la méthode exécute explicitement l’appel sans créer de transaction sur la blockchain. Renseigner from n’établit donc ni une signature, ni une autorisation, ni une diffusion. Renseigner value n’établit pas qu’un transfert a été enregistré dans la chaîne.
Pour comparer deux résultats, commencez par comparer les contextes consignés : destination, données d’entrée, éventuels émetteur et valeur, puis sélecteur de bloc. Cela ne signifie pas que chaque modification d’un champ change systématiquement la réponse. Il s’agit de conserver les hypothèses nécessaires pour comprendre ce qui a été évalué. Si gas est fourni, conservez-le dans le contexte consigné de l’appel.
Exemple hypothétique : un compteur de 7 à 8
Imaginons un contrat pédagogique fictif dont le compteur stocké vaut 7. Posons qu’une opération nommée setEight, lorsqu’elle s’exécute avec succès, règle ce compteur sur 8 et renvoie 8. Ce comportement est une hypothèse d’enseignement, sans référence à un contrat déployé.
Première branche : l’appel simulé
Supposons qu’eth_call évalue cette opération avec succès sur l’état sélectionné et renvoie la valeur prévue, 8. Cette réponse décrit l’exécution évaluée. La modification simulée n’est pas enregistrée dans la chaîne : l’appel n’a pas fait passer le compteur persistant de 7 à 8.
Cette conclusion applique à notre exemple la distinction entre exécution et persistance. Le nombre renvoyé peut être 8 sans constituer une preuve que le compteur stocké sur la blockchain a été modifié.
Deuxième branche : une transaction distincte
Considérons maintenant une transaction hypothétique appelant la même opération. Supposons qu’elle soit diffusée, incluse dans un bloc validé et exécutée avec succès. Dans ces conditions, elle enregistre la mise à jour du compteur à 8.
Cette comparaison est une déduction qui applique le mécanisme des transactions au comportement fictif défini plus haut. L’inclusion et la réussite sont des hypothèses explicites de cette deuxième branche. Le résultat du premier appel ne les garantit pas.
Pourquoi une simulation réussie ne prouve pas l’inclusion
La documentation Ethereum sur les transactions indique que les transactions destinées à modifier l’état de la machine virtuelle Ethereum doivent être diffusées et incluses dans un bloc validé. Ces exigences concernent leur parcours sur le réseau. Une réponse à eth_call n’établit pas que ces étapes ont eu lieu.
Le résultat documenté d’eth_call correspond aux données renvoyées par le contrat exécuté. Cette définition ne promet ni que toute requête réussit, ni qu’elle produit des données utiles à l’application. Lorsqu’elles sont disponibles, les données de retour doivent être interprétées selon l’opération et le contexte évalués.
Une autre déduction découle de ces limites : un appel réussi ne garantit pas la réussite d’une transaction ultérieure. L’appel évalue un contexte donné sur un état sélectionné, sans créer de transaction. La transaction ultérieure nécessite une inclusion distincte. Ces prémisses ne permettent pas d’établir que son état et son contexte d’exécution correspondront à ceux de la simulation.
Il s’agit d’une absence de garantie, pas d’une prédiction d’échec. La documentation des reçus distingue aussi le numéro du bloc contenant la transaction du statut de réussite ou d’échec. Pour les reçus utilisant le champ status, celui-ci peut signaler l’un ou l’autre résultat. On en déduit que l’inclusion seule ne suffit pas à établir une exécution réussie.
Pour approfondir cette distinction sans la confondre avec une simulation, consultez notre guide sur les étapes de vérification d’une transaction Ethereum.
Liste de contrôle pour interpréter un résultat
- Identifier la preuve : le document décrit-il une exécution par appel ou une transaction soumise séparément ?
- Conserver le sélecteur de bloc : associer le contexte d’état au résultat.
- Garder les paramètres : destination, données d’entrée et éventuels émetteur et valeur. Conserver aussi gas lorsqu’il est fourni.
- Séparer retour et persistance : une réponse simulée ne démontre pas une modification enregistrée.
- Limiter la conclusion : réussite d’un appel, inclusion d’une transaction et réussite de son exécution sont des affirmations distinctes.
- Préciser les hypothèses : dans un exemple fictif, annoncer le comportement de l’opération et toute réussite supposée.
Cette liste aide à évaluer une explication ou un exemple consigné. Les sources primaires étayent les distinctions présentées ; leur attribution ne suffit pas à établir la sécurité ou la correction d’un contrat particulier.
Contenu pédagogique préparé avec l’aide de l’IA. L’exemple hypothétique explique le fonctionnement de l’exécution et ne recommande ni d’envoyer une transaction ni de signer une demande de portefeuille.