Revertida, descartada o no encontrada: cómo leer una transacción fallida en un explorador

2026-08-24

Un explorador puede describir eventos muy distintos con palabras que parecen similares. La frase de búsqueda transaction reverted meaning crypto suele apuntar a un resultado de ejecución registrado en un bloque, mientras que transaction hash not found describe la ausencia de un registro en la cadena, el punto de acceso o el índice concretos que se están consultando. Una etiqueta dropped suele describir un candidato que un nodo o servicio ya no conserva en su grupo de transacciones pendientes. Estas etiquetas solo resultan útiles cuando se mantiene clara su capa: un registro público de la cadena, la vista temporal de un nodo, una respuesta RPC y la base de datos de un explorador son sistemas relacionados, pero no son el mismo sistema.

Un estado de transacción que pasa de la observación de red al recibo de bloque

El ciclo de vida de una transacción

Una transacción firmada puede describirse en varios puntos de su ciclo de vida. Puede crearse como datos, ser observada por un servicio, difundirse entre nodos, ser retenida como pendiente por algunos de ellos, seleccionarse para un bloque, ejecutarse según las reglas de esa cadena y representarse más tarde mediante recibos y páginas indexadas. Un hash de transacción identifica una transacción codificada concreta en la cadena donde esa codificación tiene significado. Por sí solo, no indica hasta dónde llegó la transacción en esa secuencia.

La documentación pública de Ethereum ilustra la diferencia al describir una transacción difundida que puede entrar en un grupo pendiente y ser incluida después por un validador en un bloque. Otros sistemas organizan de forma distinta la participación, el orden y la finalidad, pero la distinción amplia sigue siendo útil. Un candidato visto antes de la inclusión todavía no es una entrada permanente del libro mayor. Cuando una transacción está en un bloque, su asociación con el bloque, el resultado de ejecución y cualquier recibo disponible constituyen una categoría de evidencia distinta de una observación del grupo pendiente.

Qué significa reverted

En redes compatibles con Ethereum, reverted suele referirse a una transacción que llegó a ejecutarse tras su inclusión y cuya ejecución de nivel superior terminó en fallo. EIP-658 introdujo un código de estado en el recibo, donde 1 representa éxito y 0 representa fallo para los bloques pertinentes posteriores a Byzantium. Los exploradores suelen convertir ese resultado de nivel de recibo en una etiqueta legible de fallo. Por tanto, la etiqueta normalmente se refiere a la ejecución y no afirma que la transacción nunca se difundió ni se colocó en un bloque.

El fallo en esta capa puede surgir cuando el código ejecutado alcanza una condición que hace fallar su llamada de nivel superior. El resultado observable es distinto de una interacción de contrato exitosa: la transición de estado de nivel superior prevista no se confirma en el sentido ordinario de éxito, aunque la transacción tenga una posición en el bloque y haya consumido recursos de ejecución. La semántica exacta de ejecución, la decodificación de errores y la redacción de la interfaz varían entre cadenas y máquinas virtuales, por lo que la etiqueta breve de un explorador es un resumen y no una explicación causal completa.

Qué significa dropped

Dropped normalmente no es un estado de consenso escrito en un bloque. Es una descripción de un servicio o cliente para un candidato pendiente que ya no se conserva ni se muestra en la vista del grupo de transacciones de ese servicio. La propia documentación de monitorización de Go Ethereum, por ejemplo, distingue varios eventos locales de descarte del grupo. Esos eventos muestran que la conservación en el grupo es una cuestión de implementación, no la misma clase de registro duradero que un recibo de un bloque aceptado.

Como los grupos de transacciones son temporales y distribuidos, una etiqueta dropped dice algo limitado sobre el observador que la aplicó. Un nodo puede haber dejado de conservar un candidato mientras que otro observador tenía una vista diferente antes o después. Si ningún bloque incluye al candidato, la cadena no tiene recibo para él; si un explorador lo mostró una vez y más tarde no, ese historial de visualización tampoco crea un estado canónico en cadena llamado dropped. La etiqueta debe leerse, por tanto, como una observación del manejo del estado pendiente.

Distintas razones para not found

Not found también es más limitado de lo que parece. Un hash puede buscarse en la cadena equivocada, un punto de acceso puede carecer de un registro de transacción coincidente, un candidato pendiente puede no haber llegado nunca a ese punto de acceso o un explorador puede no haber indexado aún los datos pertinentes. Algunos sistemas también exponen identificadores diferentes para transacciones, mensajes, paquetes, operaciones de usuario u objetos específicos de una capa. Un identificador visualmente parecido no se convierte automáticamente en un hash de transacción dentro del espacio de nombres que espera un explorador concreto.

En las Execution APIs de Ethereum, una consulta de transacción o de recibo puede devolver null cuando el registro solicitado no se encuentra en ese punto de acceso, y un recibo no está disponible mientras una transacción sigue pendiente. Ese comportamiento de API describe la respuesta de una interfaz de nodo determinada; no convierte null en prueba de una ausencia global. La conservación histórica, el estado de sincronización, la cobertura del indexador y la red seleccionada pueden cambiar lo que una interfaz puede devolver en un momento dado.

Qué puede y no puede mostrar un explorador

Un explorador puede organizar datos públicos en campos como número de bloque, hash de transacción, direcciones de remitente y destinatario, valor, datos de entrada, estado del recibo, uso de gas y registros de eventos cuando la cadena los ofrece. También puede decodificar entradas, etiquetar contratos, agrupar actividad o presentar trazas producidas por su propia infraestructura. Estas incorporaciones pueden facilitar la lectura de un libro mayor, pero son interpretaciones y representaciones indexadas sobre los datos del protocolo, no hechos de consenso nuevos.

Un explorador no puede derivar hechos que la cadena seleccionada no registró. Una página no establece la identidad, la intención, un acuerdo fuera de cadena, un arreglo de control de cuenta ni el significado de una afirmación del mundo real. Una etiqueta de estado simplificada tampoco puede resolver cada cuestión sobre la lógica interna de una aplicación. Los datos públicos de una transacción y la presentación del explorador son evidencia valiosa del registro visible de la cadena, pero su alcance probatorio termina en los límites de ese registro y de los métodos de indexación del servicio.

Diferencias de tiempo entre cadenas, RPC e indexadores

Los datos de la cadena, los nodos RPC, los grupos pendientes y los índices de exploradores operan con ritmos distintos. Un productor de bloques trabaja con un conjunto local de candidatos, un punto de acceso RPC responde desde su propio estado de nodo y un explorador primero obtiene y después procesa los datos antes de mostrarlos. Durante esas transiciones, una vista puede mostrar un objeto de transacción sin recibo, otra solo una señal pendiente y una tercera ningún resultado. Ninguna de esas vistas por sí sola describe necesariamente a todos los observadores en el mismo instante.

Las Execution APIs de Ethereum hacen concreta la separación: la búsqueda de una transacción y la de un recibo son métodos distintos, y la respuesta del recibo es null cuando no se encuentra un recibo. Las interfaces comparables de otras cadenas tienen sus propios modelos de datos y patrones de demora. Las demoras de indexación, la sincronización del nodo, la selección de cadena y las decisiones de conservación de datos explican por qué el lenguaje de un explorador necesita un calificativo temporal y de alcance. La afirmación más precisa se refiere a lo que un servicio identificado mostró en un momento determinado, no a un estado universal sin calificación.

Términos neutrales y límites de seguridad

La redacción neutral ayuda a conservar estas distinciones. Included se refiere a una relación con un bloque; pending a la vista temporal de un candidato por parte de un observador; reverted a un resultado de ejecución cuando el término está definido; dropped a un evento de conservación o visualización; y not found a una consulta fallida dentro de un alcance indicado. Tratar las etiquetas como intercambiables puede borrar la diferencia entre una ejecución fallida registrada y un candidato no registrado o no indexado.

El estado de una transacción es información pública del libro mayor, no prueba de identidad, autoridad, propiedad o resultado futuro. Interpretarlo no requiere credenciales secretas ni material de control de cuenta, y una etiqueta de estado no puede establecer recuperación de activos, un acuerdo privado ni un derecho a actuar por otra persona. Mantener clara la frontera entre los identificadores públicos y la autoridad sensible ayuda a preservar el papel factual limitado para el que está diseñado un explorador.

Lecturas relacionadas

Otros artículos de Bitbase sobre este tema:

- Transacciones atascadas y fallidas

- ¿Qué es la agrupación de transacciones en cripto? Ahorrar en comisiones

- Comisiones de trading cripto explicadas: los costes que pagas de verdad

Aviso legal: Este artículo es contenido educativo de Bitbase Academy y se ofrece solo con fines informativos. No constituye asesoramiento de inversión, negociación, fiscal ni financiero. Los criptoactivos son volátiles; evalúa tu propio riesgo. Redactado en agosto de 2026; consulta la información oficial más reciente.