Confirmaciones y finalidad en Ethereum: comprueba el bloque, no solo Success

Una transacción incluida en Ethereum puede mostrar Success antes de que se finalice el bloque que la contiene. Success describe la ejecución; las confirmaciones describen bloques añadidos tras la inclusión según el criterio de recuento de la herramienta. La finalidad es un estado de consenso distinto. Comprueba el bloque de la transacción y la cadena finalizada de la red en vez de tratar esas etiquetas como equivalentes.

Esta guía trata de Ethereum Mainnet tras su transición a la prueba de participación. Los rollups, puentes, otras cadenas y servicios de custodia tienen reglas adicionales. Es una comprobación de solo lectura de una transacción que ya tienes, no una recomendación de enviar, cancelar o repetir un pago.

Separa inclusión, ejecución y finalidad

La referencia de recibos JSON-RPC devuelve el número y el hash del bloque que contiene la transacción, junto con el estado de ejecución. Una transacción pendiente aún no tiene un recibo de inclusión. El estado 1, mostrado como 0x1 en JSON-RPC sin procesar, indica ejecución correcta; 0 o 0x0 indica fallo.

Ninguno de los valores es un indicador de finalidad. Una transacción revertida puede pertenecer a un bloque finalizado. A la inversa, una ejecución correcta puede estar en un bloque reciente que aún no se ha finalizado. Esperar la finalidad no convertirá una acción revertida en una correcta.

Observación	Qué indica	Qué no resuelve
Recibo con un bloque	El proveedor informa de la inclusión allí	Si ese bloque está finalizado
Estado del recibo Success	La ejecución de nivel superior fue correcta	La recepción prevista de tokens o la finalidad
Número de confirmaciones	La herramienta informa de la profundidad desde la inclusión	Una regla universal de finalidad o abono
La cadena finalizada incluye el bloque	La finalidad del consenso cubre ese bloque	La seguridad del contrato o un abono de un exchange

Si la transacción sigue pendiente, consulta la guía de transacciones pendientes antes de considerar otra acción. Si fue correcta pero faltan los tokens previstos, la guía de pruebas de transferencia trata esa otra cuestión.

Qué significa finalizado en Ethereum

La explicación de la prueba de participación de Ethereum describe cómo votan los validadores sobre puntos de control. La finalidad ofrece una garantía más fuerte que la mera cercanía al extremo actual de la cadena: revertir un bloque finalizado requeriría un fallo importante del consenso con graves consecuencias económicas. No promete que cada aplicación o activo del bloque sea seguro.

La explicación de la capa de aplicaciones de Ethereum Foundation distingue safe head de los bloques finalizados. Safe es un estado intermedio de confianza, no un sinónimo de finalized. La API de ejecución expone las etiquetas de bloque latest, safe y finalized para consultar la cabecera pertinente.

Usa esas etiquetas en su contexto de Ethereum. Un rollup puede usar palabras similares para etapas que implican un secuenciador y una cadena principal. No apliques sin cambios el procedimiento de Mainnet a una transferencia por puente ni supongas que una transacción finalizada en la cadena de origen completa la acción en el destino.

Aquí no se promete un tiempo fijo de espera. Un retraso, un proveedor desactualizado o un problema de red pueden hacer que un temporizador sustituya mal la comprobación del estado real. Si un servicio exige cierto número de confirmaciones u otra condición, consulta sus requisitos oficiales actuales como comprobación independiente.

Contrasta la transacción con la cadena finalizada

Empieza con un explorador Ethereum conocido o un lector público de bloques al que llegues por una vía de confianza. Algunos exploradores muestran la finalidad directamente; otros solo ofrecen detalles del bloque. Los nombres de métodos siguientes identifican lecturas públicas, no instrucciones para ejecutar una transacción o conectar un monedero. Este procedimiento se contrastó con la documentación el 27 de octubre de 2026; no se probó en un monedero real para este artículo.

1. Fija la identidad de la transacción. Registra Ethereum Mainnet y el hash completo de la transacción. Lee su recibo y anota el número del bloque que la contiene, su hash y el estado de ejecución. Un recibo no disponible sigue sin resolverse; comprueba la red y el proveedor antes de declararlo fallido.
2. Lee el estado de finalidad indicado. Usa la etiqueta de bloque documentada del explorador. En un lector JSON-RPC, eth_getBlockByNumber con finalized solicita la cabecera finalizada actual. Conserva el número de bloque devuelto y la hora de observación. Las lecturas no admitidas o fallidas siguen sin verificar.
3. Compara la identidad del bloque y su altura. Si la cabecera finalizada es inferior al bloque de la transacción, esa observación aún no cubre la transacción. Si ha alcanzado o superado esa altura, vuelve a leer el bloque canónico a la altura de inclusión y compara su hash con el del bloque del recibo. Usa un proveedor coherente y actualizado y vuelve a comprobar el recibo si los hashes difieren.
4. Mantén claro el alcance del resultado. Un bloque contenedor coincidente a la altura de la cabecera finalizada o anterior respalda la finalidad en esa cadena indicada. Un proveedor desactualizado o incoherente aún puede dar datos engañosos. Conserva las discrepancias y consulta el estado oficial o el soporte del proveedor en vez de forzar una respuesta con instantáneas mezcladas.
5. Comprueba por separado el requisito de la aplicación. Determina qué hizo realmente la transacción y si el servicio receptor la ha abonado según sus propias reglas. No envíes un segundo pago solo porque una galería o una página de depósitos no se haya actualizado.

La documentación de consulta de bloques proporciona el número y el hash del bloque. La altura por sí sola no basta cuando los registros difieren: dos bloques distintos pueden ocupar la misma altura durante una reorganización de la cadena. Conserva el hash junto al número para que la comparación identifique el bloque que contenía la transacción.

Lee con cuidado un número de confirmaciones cambiante

Supongamos que un recibo hipotético sitúa una transacción en el bloque 100, mientras un lector indica una cabecera finalizada en 98. La transacción ya puede mostrar Success, pero esa observación de la cabecera finalizada no cubre el bloque 100. Si una lectura posterior coherente indica la cabecera finalizada 102, comprueba que el bloque canónico en 100 conserva el hash del recibo antes de registrar el bloque de la transacción como cubierto.

Estos números de bloque deliberadamente pequeños son un ejemplo inventado, no una observación actual de Mainnet. No predicen cuánto tarda la finalidad ni especifican un umbral de depósito. El número de confirmaciones mostrado puede seguir un criterio que incluya el bloque contenedor; lee la definición de la herramienta antes de comparar cifras de dos interfaces.

Una reorganización puede mover la transacción a otro bloque o dejarla sin su registro previo de inclusión. Conserva el hash original, actualiza su recibo y compara los registros actuales. Un cambio de número por sí solo no prueba que debas reenviar. Tampoco una notificación antigua del monedero invalida un registro de bloque más reciente.

Termina con un registro del bloque fechado

Conserva juntos la red, el hash de transacción, el número y hash del bloque contenedor, el estado de ejecución, la cabecera finalizada observada y la hora de comprobación. Indica si los registros eran coherentes y si el explorador etiquetó directamente la finalidad o se dedujo de la comparación de bloques anterior.

La finalidad no demuestra que el token correcto llegara al destinatario correcto, que un contrato sea fiable ni que un servicio de custodia haya completado su contabilidad. Una discrepancia en el saldo de la cartera también puede ser un problema de visualización, cobertura o precios después de finalizar una transacción.

No se necesita firma, autorización ni frase de recuperación para estos registros públicos. Si un sitio las pide solo para mostrar confirmaciones o finalidad, detén ese proceso. El resultado debe ser un estado observado concreto con sus límites, no una promesa universal de que una insignia verde significa que todas las partes del pago están completas.