eth_call ejecuta una llamada a un contrato sobre un estado seleccionado de Ethereum sin crear una transacción en la cadena. Una transacción sigue un recorrido distinto: es el mecanismo para iniciar una actualización del estado de la red, requiere difusión y debe incluirse en un bloque validado. Esta diferencia explica por qué una simulación aporta información útil sobre una ejecución concreta, pero no garantiza el éxito de una transacción posterior.
Para comparar eth_call con una transacción hay que conservar tres elementos: la operación evaluada, el estado elegido para evaluarla y lo que acredita realmente la respuesta. Una vista previa satisfactoria debe mantener ese contexto cuando se describe o se compara con otro resultado.
Ejecutar sin guardar la actualización en la cadena
La documentación de la API JSON-RPC de Ethereum describe eth_call como la ejecución de una llamada sin crear una transacción en la cadena. Sí se ejecutan instrucciones: el método no se limita a etiquetar una solicitud sin evaluarla.
La distinción entre ejecución y persistencia es fundamental. La documentación de transacciones identifica estas como el mecanismo mediante el cual una cuenta inicia una actualización del estado de la red. De ambas premisas se deduce que eth_call no guarda en la cadena de Ethereum los cambios de estado de la operación simulada.
Aquí, «solo lectura» describe el efecto sobre el estado persistente de la cadena. No significa que durante la simulación no pueda ejecutarse código del contrato. Incluso al evaluar una operación destinada a modificar datos almacenados, la pregunta decisiva es si esa modificación pasa a formar parte del estado de la cadena.
El bloque seleccionado forma parte del resultado
Una solicitud eth_call acepta un selector de bloque. Entre las opciones documentadas están un número de bloque y las etiquetas latest, earliest, pending, safe y finalized. La documentación explica que el parámetro de bloque determina la altura de bloque utilizada en una consulta de estado.
Por tanto, una descripción útil del resultado conserva el contexto del bloque seleccionado. Decir «la llamada devolvió este valor» deja fuera parte de la pregunta. Decir «la llamada devolvió este valor con el selector de bloque indicado» mantiene una condición necesaria para interpretar la respuesta.
Esta es una deducción basada en la estructura de la solicitud, no una afirmación de que cada selector distinto deba producir una respuesta diferente. Dos evaluaciones pueden coincidir sin que su contexto de estado deje de ser relevante.
Además, elegir pending no acredita que una transacción esté incluida en un bloque validado. El selector describe el contexto de estado solicitado; no convierte la llamada en una transacción ni demuestra su inclusión.
Qué datos de la llamada conviene conservar
El estado seleccionado es solo una parte de la solicitud. El objeto de llamada documentado también especifica adónde se dirige la ejecución y qué datos se le proporcionan:
- from: dirección opcional del emisor dentro del contexto de la llamada.
- to: dirección a la que se dirige la ejecución.
- input: campo opcional que identifica el método invocado y sus parámetros codificados.
- value: valor opcional aportado como parte del contexto de la llamada.
- gas: un parámetro de ejecución opcional que algunas ejecuciones pueden necesitar.
Estos campos deben interpretarse dentro de la definición de eth_call. Aunque algunas descripciones empleen terminología de transacciones, el método ejecuta expresamente sin crear una transacción en la cadena. Por ello, proporcionar from no acredita firma, autorización ni difusión. Proporcionar value tampoco acredita una transferencia registrada en la cadena.
De aquí se deriva una práctica útil: comparar el contexto registrado antes de tratar dos resultados como respuestas a la misma pregunta. Conviene conservar destino, entrada, emisor y valor proporcionados, además del selector de bloque. Esto no implica que cambiar cualquiera de esos campos altere siempre el resultado; identifica las condiciones que una explicación debe mantener visibles. Si se proporciona gas, consérvalo como parte del contexto registrado de la llamada.
Ejemplo hipotético: un contador de 7 a 8
Imaginemos un contrato didáctico inventado cuyo contador almacenado vale 7. Establecemos que una operación llamada setEight, cuando se ejecuta correctamente, cambia el contador a 8 y devuelve 8. Son supuestos explícitos del ejemplo, no datos de un contrato desplegado.
Evaluación mediante eth_call
Supongamos que eth_call evalúa correctamente esa operación sobre el estado seleccionado y devuelve el valor previsto: 8. La respuesta describe esa ejecución. La actualización simulada del contador no queda guardada: la llamada no ha cambiado de 7 a 8 el contador almacenado en la cadena.
El ejemplo permite separar el número devuelto del número almacenado de forma persistente. La operación ficticia puede devolver 8 durante la evaluación sin que esa respuesta acredite una actualización registrada.
Ejecución mediante una transacción
Consideremos ahora una transacción hipotética independiente que invoca la misma operación. Supongamos que se difunde, se incluye en un bloque validado y se ejecuta correctamente. Bajo esos supuestos, la transacción guarda la actualización del contador a 8.
La comparación aplica, por deducción, la diferencia documentada entre llamada y transacción al comportamiento inventado. La ejecución correcta y la inclusión son supuestos de esta segunda parte. No son consecuencias garantizadas por el resultado de la llamada anterior.
Una simulación satisfactoria no acredita inclusión
La documentación de transacciones de Ethereum explica que las transacciones destinadas a modificar el estado de la EVM deben difundirse por la red e incluirse en un bloque validado. Son requisitos del recorrido de la transacción por la red. Un resultado de eth_call no acredita que se hayan cumplido esos pasos.
La respuesta documentada de eth_call contiene los datos devueltos por el contrato ejecutado. Esa descripción no promete que todas las solicitudes tengan éxito ni que aporten datos útiles para la aplicación. Cuando hay datos de retorno, su significado sigue dependiendo de la operación y del contexto evaluados.
De los límites anteriores se deduce que una llamada satisfactoria no garantiza la ejecución correcta de una transacción posterior. La llamada evalúa un contexto concreto sobre un estado seleccionado sin crear una transacción. La transacción posterior requiere una inclusión independiente. Estas premisas no establecen que su estado y su contexto de ejecución vayan a coincidir con los de la simulación.
Es una ausencia de garantía, no una predicción de fallo. La documentación del recibo registra por separado el número del bloque que contiene la transacción y un estado que puede indicar éxito o fallo. De esa separación se deduce, de forma limitada, que la inclusión por sí sola no acredita una ejecución correcta del contrato. Para profundizar en esa diferencia, consulta qué demuestra la verificación de una transacción en Ethereum.
Lista para interpretar el resultado de una llamada
- Identifica la evidencia: distingue una ejecución mediante llamada de una transacción enviada por separado.
- Conserva el selector de bloque: registra el contexto de estado junto al resultado.
- Mantén los datos de la llamada: destino, entrada y cualquier emisor o valor proporcionados. Conserva también gas cuando se proporcione.
- Separa retorno y persistencia: un resultado simulado no acredita una actualización guardada en la cadena.
- Ajusta la conclusión: éxito de la llamada, inclusión y ejecución correcta de la transacción son afirmaciones distintas.
- Explicita los supuestos: indica el comportamiento ficticio y cualquier éxito de ejecución asumido.
Esta lista sirve para evaluar explicaciones y ejemplos registrados. La atribución a documentación primaria respalda las distinciones descritas; no acredita la seguridad ni la corrección de un contrato concreto.
Material educativo elaborado con ayuda de inteligencia artificial. El ejemplo hipotético explica la ejecución y no recomienda enviar una transacción ni firmar una solicitud de cartera.