Ejecución y finalidad de Ethereum

Fuente maestra EN · P02-L02 · 30 minutos estimados · needs_review

Estudio de solo lectura. Sin conexión de cartera, dinero real, frase de recuperación, clave privada, firma ni operación de mercado en directo. La duración es una estimación editorial; los recursos visuales son especificaciones, no componentes desplegados.

El éxito y la finalidad responden a preguntas distintas. Mezclarlos puede hacer que una transacción fallida parezca exitosa o que una transacción incluida parezca más liquidada de lo que respalda la evidencia.

Dos ejes, no una única escala de estados

Un recibo describe la ejecución. La ejecución de Ethereum funciona en la Máquina Virtual de Ethereum (EVM), el entorno que aplica sus reglas de ejecución. La información de consenso describe si el bloque que la contiene pertenece a un historial con un estado de liquidación particular. La prueba de participación de Ethereum usa puntos de control y votos de validadores para la finalidad; un validador es un participante del protocolo cuyo papel de votación está respaldado por ETH en participación [POS]. Una ejecución exitosa en un bloque reciente puede no estar finalizada todavía.

A la inversa, una ejecución fallida puede estar contenida en un historial finalizado. La finalidad no reescribe su resultado. Un fallo incluido puede seguir consumiendo comisiones [GAS]. No resuma los dos ejes en un único distintivo verde de «completado».

Vincular el recibo con el bloque

Conserve juntos el hash de transacción y el hash de bloque. Un punto de control finalizado de mayor altura no basta por sí solo salvo que se establezca que el bloque del recibo es su antecesor en la misma cadena. El conjunto ficticio proporciona esa ascendencia explícitamente cuando es necesaria; no la invente en un informe real.

Un estado de recibo de cero respalda un fallo en ese contexto de ejecución [RPC]. No identifica la causa sin más datos. Una explicación de error ausente sigue siendo UNKNOWN; no diagnostique un error por agotamiento de gas simplemente porque sea conocido.

Separar medición e interpretación

El valor de estado proporcionado es OBSERVED dentro del paquete. Aplicar la ascendencia estipulada para clasificar la liquidación es una conclusión INFERRED bajo ese supuesto. El estado actual en directo no se observa por el mero hecho de leer el paquete hoy.

Usar una matriz de resultados

Cree filas para éxito incluido/no finalizado, fallo incluido/finalizado y registro no disponible. Esto impide que un único vocabulario de estados oculte datos ausentes. Un resultado finalizado sigue sin establecer la legitimidad de un token, el consentimiento informado de una persona ni la seguridad de otra interacción.

Clasificación de estados de evidencia

OBSERVED en el conjunto ficticio: estados de recibos, comisión proporcionada y ascendencia estipulada del punto de control. INFERRED: la ejecución fallida de A está en la ascendencia finalizada indicada. UNKNOWN: finalidad de B y causa del fallo de A. INSUFFICIENT EVIDENCE: el éxito de ejecución por sí solo establece finalidad del consenso o seguridad del token.

• Estado de ejecución: éxito/fallo de la ejecución de una transacción.
• Finalidad: propiedad de liquidación por consenso del historial de bloques.
• Ascendencia: relación entre bloques en una misma cadena.
• Contexto del recibo: transacción más bloque que la contiene.

ILLUSTRATIVE. R-A: SIM-TX-A, BLOCK-100, status0, comisión de gas de 0.001 ETH simulados. R-B: SIM-TX-B, BLOCK-103, status1. Se estipula que el punto de control BLOCK-102 está finalizado y desciende de BLOCK-100. No se proporciona afirmación de finalidad para 103.

Panel de evidencia de dos ejes: A fallo/finalizado bajo el supuesto; B éxito/finalidad desconocida. Texto alternativo: la finalidad no convierte una ejecución fallida en exitosa.

Las clasificaciones de dos ejes bajo la ascendencia proporcionada explícitamente.

Validación independiente del consenso, diagnóstico del fallo, seguridad o estado actual de la red.

• Suponer que finalizado significa exitoso.
• Suponer que Status1 significa finalizado.
• Suponer la ascendencia a partir de la altura por sí sola.

Clasifique cada transacción en ambos ejes. ¿Desaparece la comisión de A? ¿Qué registro ausente resolvería el contexto de liquidación de B?

Entregue una tabla breve de evidencia y el razonamiento, usando únicamente el material proporcionado. Distribución sugerida: estudio 12 min, inspección/cálculo 8 min, corrección/cuestionario 10 min.

• Resultado del recibo.
• Hash del bloque.
• Respaldo de consenso/ascendencia.
• Comisión por separado.
• Las causas desconocidas de fallo siguen siendo desconocidas.

El éxito y la finalidad responden a preguntas distintas. Mezclarlos puede hacer que una transacción fallida parezca exitosa o que una transacción incluida parezca más liquidada de lo que respalda la evidencia. El material proporcionado respalda las clasificaciones de dos ejes bajo la ascendencia proporcionada explícitamente. No establece validación independiente del consenso, diagnóstico del fallo, seguridad ni estado actual de la red.

• Separar el resultado de ejecución del contexto de consenso.
• Explicar una ejecución fallida finalizada.
• Leer los supuestos de ascendencia de bloques.

P02-L03 después de revisar este ejercicio y sus prerrequisitos.

NONE. El catálogo autorizado no exige acceso a ningún producto para esta lección. Use el material congelado/sin conexión.

• [RPC] Ethereum JSON-RPC — Estado del recibo, contexto del bloque y resultados de API con alcance de red. Comprobado 2026-10-01.
• [POS] Prueba de participación de Ethereum — Puntos de control del consenso y separación de ejecución/consenso. Comprobado 2026-10-01.
• [GAS] Gas y comisiones de Ethereum — Gas usado multiplicado por precio efectivo y costes de fallos incluidos. Comprobado 2026-10-01.

Los valores sintéticos son entradas de ejercicio creadas por el autor. Los valores históricos, si los hay, deben usar el conjunto de datos enlazado y su procedencia más limitada. La inspección de fuentes no es aceptación editorial independiente.