¿Cómo se verifica una transacción en una red de criptomonedas? En Ethereum, la respuesta reúne varias comprobaciones y etapas: autenticar la autorización de la cuenta, ejecutar las instrucciones, incluir la transacción en un bloque validado y alcanzar el acuerdo de la red. La palabra «verificada» puede resultar ambigua si no se aclara a cuál de esas etapas se refiere.
Esta explicación utiliza Ethereum como ejemplo concreto y se limita a sus transacciones firmadas ordinarias. No describe todas las criptomonedas ni ofrece un algoritmo exhaustivo de validación. La distinción central es sencilla: una transacción incluida puede tener una ejecución fallida, y una ejecución correcta tampoco demuestra por sí sola que se haya cumplido todo lo que esperaba una persona.
1. La firma acredita la autorización de la cuenta
Una transacción ordinaria de Ethereum lleva una firma generada con la clave privada del emisor. Esa firma permite autenticar la autorización mediante la clave asociada a la cuenta. El campo from identifica la dirección del emisor. Ambas cosas se refieren a la cuenta: no acreditan la identidad personal de quien actúa, su comprensión de las instrucciones ni su satisfacción con el resultado.
La transacción también contiene un nonce, un contador que aumenta secuencialmente e indica el número de transacción de esa cuenta. Conviene entenderlo como un dato propio de la secuencia de la cuenta. Esta definición no basta para explicar todas las reglas de comprobación del nonce ni cómo se sustituyen operaciones pendientes.
La documentación de transacciones de Ethereum describe estos campos y la firma. Su alcance debe mantenerse preciso: acreditar una autorización mediante una clave no equivale a certificar que la operación sea segura o adecuada para los objetivos de quien la autorizó.
2. Difundir la transacción y ejecutarla son pasos distintos
El ciclo de vida documentado comienza con la difusión de la transacción por la red y su incorporación a un conjunto de transacciones pendientes. Es una descripción simplificada: no garantiza que todos los nodos la reciban ni que termine incluida en un bloque.
El cliente de ejecución de Ethereum ejecuta las transacciones difundidas en la máquina virtual de Ethereum, o EVM. La ejecución determina qué producen las instrucciones conforme a las reglas de ejecución. La inclusión responde a otra pregunta: si la transacción pasa a formar parte de un bloque validado. La exigencia de inclusión no constituye una promesa de que vaya a producirse.
La reejecución permite entender cómo se comprueban los resultados sin limitarse a aceptar un estado declarado. Durante una sincronización completa, denominada full sync, el nodo reconstruye el estado de la cadena ejecutando los bloques desde el bloque inicial o génesis.
Esta última afirmación tiene un límite importante: describe ese modo de sincronización. Otros modos pueden partir de puntos de control de confianza o tratar los datos históricos de otra manera. La documentación sobre nodos y clientes explica estas funciones; no debe interpretarse como si todos los nodos reprodujeran siempre toda la historia.
3. El consenso añade el acuerdo de la red
El cliente de consenso de Ethereum implementa el acuerdo mediante prueba de participación a partir de datos validados por el cliente de ejecución. Por tanto, validar la ejecución y alcanzar el acuerdo de la red son funciones relacionadas, pero diferentes.
El ciclo documentado distingue también la inclusión del bloque de sus etapas posteriores de justificación y finalización. La primera aparición de una transacción en un bloque no debe confundirse con la finalidad. Esta descripción tampoco fija un plazo garantizado ni asegura una progresión incondicional entre etapas.
De estas premisas se deduce un límite concreto: si la ejecución proporciona datos validados para el consenso y la finalización es una etapa distinta, la validación local de un solo nodo no establece por sí sola la finalidad de la red. Es una deducción sobre la separación de funciones, no una explicación de los umbrales de consenso.
Al leer que una operación está «verificada», resulta útil precisar qué se ha establecido. La autorización de la cuenta, la ejecución local, la inclusión y la finalidad responden a preguntas diferentes.
4. La inclusión y el resultado de ejecución se leen por separado
En los recibos de Ethereum que incluyen status, ese campo indica éxito de ejecución con 1 y fallo con 0. Por separado, blockNumber identifica el bloque que contiene la transacción. Este último campo no acredita por sí solo la finalidad.
La documentación de la API JSON-RPC de Ethereum define ambos campos. También establece una salvedad histórica: los recibos anteriores a Byzantium presentan una raíz de estado en lugar de ese estado de ejecución.
La separación de campos permite una deducción: si un recibo identifica el bloque que contiene la transacción y admite a la vez un estado de fallo, estar incluida no implica haberse ejecutado correctamente. La aceptación y la inclusión conforme al protocolo son compatibles con un resultado de ejecución fallido.
Existe otra limitación interpretativa. Puesto que status informa de éxito o fallo de ejecución, se deduce que no compara por sí mismo el resultado con todos los objetivos de una persona. Acreditar un resultado concreto del contrato exige pruebas de ese resultado, además del indicador binario.
Para estudiar por separado cómo se presentan estos datos, puedes consultar cómo leer una transacción de Ethereum en un explorador de bloques. Aquí el objetivo es comprender qué demuestra cada etapa, no aprender a utilizar una interfaz.
5. REVERT revierte la ejecución afectada
La instrucción REVERT interrumpe la ejecución afectada de la EVM, la considera fallida y revierte sus cambios de estado. El alcance importa: esa explicación no permite afirmar que se restauren todos los efectos relativos al gas, las comisiones, el nonce o cualquier ejecución exterior.
Según EIP-140, que especifica REVERT, cuando la instrucción se ejecuta normalmente no consume todo el gas restante. Eso no significa que la ejecución sea gratuita ni que se recupere el gas consumido anteriormente.
La especificación contempla una excepción: si no queda gas suficiente para ejecutar REVERT o faltan elementos necesarios en la pila, se comporta como una excepción por agotamiento de gas y consume todo el gas del contexto de ejecución afectado.
EIP-140 también distingue el contrato llamado del que realiza la llamada: este último recibe una indicación de fallo cuando el primero revierte. De la reversión limitada a la ejecución afectada y esa comunicación al llamador se deduce que el REVERT de una llamada no demuestra, por sí solo, que se hayan revertido todos los efectos del contrato que la invocó. Para establecerlo habría que conocer su comportamiento y el resultado del conjunto de la transacción.
6. Ejemplo hipotético y lista de comprobación
Ejemplo hipotético: Marta autoriza una transacción ordinaria destinada a una operación de contrato. La transacción se difunde y después queda incluida en un bloque validado. Su recibo identifica ese bloque, pero muestra status con valor 0. No hay contradicción: la inclusión y el fallo de ejecución son compatibles.
Supongamos que la ejecución afectada utilizó REVERT. Sus cambios de estado se revierten dentro de ese ámbito, con las salvedades sobre gas ya explicadas. La firma y la inclusión no convierten ese fallo en un éxito. Si el ejemplo mostrara status con valor 1, acreditaría éxito de ejecución, aunque seguiría siendo necesario comprobar el resultado específico que Marta esperaba.
Esta lista sirve para evaluar una explicación de verificación sin realizar ninguna operación:
- Identifica la red y mantén las conclusiones sobre Ethereum dentro de ese ámbito.
- Separa la autorización de la cuenta y el nonce del resultado de ejecución.
- Distingue difusión, inclusión en bloque y etapas posteriores del consenso.
- Interpreta el estado de ejecución por separado del bloque indicado en el recibo.
- Limita la reversión al ámbito afectado y conserva las excepciones relativas al gas.
- Pregunta qué pruebas acreditan el resultado concreto que se pretendía conseguir.
Material educativo elaborado con ayuda de inteligencia artificial. Las afirmaciones y sus correspondencias con las fuentes requieren revisión editorial independiente.