Historial de transacciones

Máster fuente EN · P09-L02 · 45 minutos estimados · needs_review

Una página de transacción puede mostrar una transferencia, su instrucción, un resumen decodificado y un cambio de saldo. Pueden ser varias vistas del mismo evento. Sumar cada línea infla la actividad; ignorar el estado de ejecución puede convertir intentos fallidos en transferencias exitosas.

Esta lección enseña un registro histórico separando identidad de evento, éxito, actividad anidada y comisiones. Prepara el análisis de financiación sin asumir que toda referencia de dirección significa un pago.

Definir la cobertura histórica

Escribir red, dirección objetivo, cuentas de tokens relacionadas, ventana solicitada y método de recopilación. Solana getSignaturesForAddress devuelve firmas que referencian la dirección solicitada en accountKeys, más recientes primero, con parámetros de paginación [S09-SIGNATURES]. Una página devuelta es una lista de descubrimiento, no un registro completo de transferencias.

Una dirección referenciada no tiene por qué ser firmante o destinataria. Las instrucciones pueden referenciar programas, cuentas de datos y estado de solo lectura. Inspeccionar el rol antes de contar participación como acción. Consultar una dirección propietaria también puede no descubrir todas las operaciones de cuentas de tokens separadas; inspeccionar la cobertura pretendida en lugar de declarar historial completo.

Deduplicar firmas entre páginas superpuestas, conservando instrucciones distintas dentro de una transacción. Ordenar según orden disponible de slot/bloque y evidencia de orden dentro del contexto. El orden mostrado por una interfaz no es automáticamente el orden exacto de ejecución.

Verificar el resultado antes de contar efectos

Recuperar metadatos de ejecución de registros descubiertos. Solana getTransaction puede devolver null en el compromiso solicitado y tiene campos de tiempo o metadatos que pueden ser nulos [S09-TRANSACTION]. Tratar la recuperación ausente como no resuelta, no como evento fallido o inexistente.

Un registro confirmado/incluido aún puede contener una operación fallida. Registrar éxito separado de finalidad. El importe presentado describe intención; un efecto exitoso de saldo describe ejecución. Para T2 fallido del conjunto, los efectos de transferencia de tokens son explícitamente cero mientras se sigue cobrando la comisión nativa suministrada.

No universalizar afirmaciones simplificadas de reversión a toda función de cadena. El ejercicio excluye cambios de autorización y otros mecanismos ajenos a transferencias. Su tabla de resultados suministra directamente los efectos relevantes. En análisis real inspeccionar reglas efectivas del protocolo y diferencias de estado.

Separar identidad del evento y filas mostradas

Elegir clave de evento: red, firma/hash de transacción y ruta de instrucción o índice de registro según corresponda. Una instrucción de transferencia, su resumen decodificado y el cambio de saldo coincidente pueden corroborar un evento. No son tres transferencias separadas.

Un cambio de saldo es un resultado neto. Si una cuenta envía 10 y recibe 4 en una ventana, el cambio es−6 y la salida bruta es 10. El cambio no borra la transferencia entrante y sumar movimiento bruto con cambio neto duplica el cómputo.

Las llamadas anidadas requieren su propia semántica. El callTracer de Geth describe marcos de llamada con alcance configurable [S09-TRACES]. Una llamada interna es parte de una transacción padre, no una transacción firmada aparte. Algunos marcos transportan valor nativo; otras llamadas transportan cero y ejecutan código. No contar cada llamada como pago.

Distinguir llamadas, registros y movimientos de tokens

Un recibo EVM suministra enlace de transacción, estado y registros [S09-RECEIPT]. Un registro de evento de token y una llamada con valor nativo son registros diferentes. El contrato de token que emite un registro Transfer no es necesariamente el destinatario económico.

En Solana, los metadatos de resultado distinguen instrucciones, instrucciones internas, comisiones y saldos [S09-STRUCTURES]. Una instrucción interna puede identificar un mecanismo dentro de una operación padre. Su resumen debe usar el mismo localizador de evento.

Una llamada contractual con registro de transferencia de tokens puede ser un movimiento económico de tokens más una relación de llamada, no dos movimientos de tokens. Conservar ambas observaciones en tablas tipadas y elegir la unidad de cómputo adecuada a la pregunta.

Mantener separadas las comisiones

Las comisiones usan el activo nativo de red y tienen un pagador específico. No son transferencias del token objetivo. La documentación Solana describe un mecanismo de comisiones nativas de transacción [S09-FEES]. No asumir que cada dirección visible pagó la comisión ni que cada intento fallido fue gratis.

Contar comisiones una vez por resultado de transacción suministrado, no por instrucción o resumen. Convertir unidades brutas según precisión nativa si el conjunto real la suministra. Este ejercicio ofrece unidades ficticias normalizadas de comisión sin conversión de precio.

Conciliar movimientos de tokens y costes nativos por separado. Un cambio de tokens puede ser correcto mientras el saldo nativo tiene alquiler, depósitos u otros efectos sin relación. El conjunto los excluye explícitamente; los registros reales requieren conciliación adicional.

Construir una tabla histórica delimitada

Usar columnas de localizador de evento, rol de objeto, resultado, activo, dirección, importe bruto, pagador de comisión e incertidumbre. Mantener lista separada de registros no resueltos. No borrar los ausentes para hacer parecer completo el conteo visible de éxitos.

El conteo de transacciones exitosas de transferencia de tokens difiere del conteo de eventos de transferencia. Una transacción puede tener varios eventos. Declarar la estadística informada. Un intento fallido puede integrar el conteo de intentos y aportar cero al movimiento exitoso.

La descripción final debe nombrar ventana de observación y cobertura suministrada. El historial enseña qué ocurrió en registros disponibles, no por qué lo eligió un actor. Una transferencia exitosa no prueba afiliación ni es señal de precio.

• Resultado de ejecución: éxito/fallo de la operación inspeccionada.
• Localizador de evento: transacción más ruta de instrucción/registro.
• Marco de llamada: ejecución anidada dentro de una transacción.
• Flujo bruto: suma de movimientos direccionales.
• Cambio neto: saldo final menos inicial.
• Pagador de comisión: cuenta que soporta el coste nativo suministrado.

ILLUSTRATIVE — FIX-P09-02. SIM-SOL-A / W / MINT-T. Efectos completos solo de T1–T3, orden sintético S1,S2,S3. Comisiones nativas normalizadas y pagadas por W. Sin otros efectos de ventana. Saldo inicial de tokens 100.

El ejemplo SIM-EVM-A separado E1 tiene éxito con W-E→ROUTER de valor0 en nivel superior; ROUTER→C-E anidado de valor nativo2 y un registro Transfer de tokens por7 unidades de W-E a C-E. El conjunto estipula activos/efectos distintos y cobertura completa de llamadas. No se suministra comisión para E1.

OBSERVED en el conjunto: las tres vistas de T1 describen una transferencia de10 tokens; T2 falla; T3 recibe 4. E1 contiene llamada de valor cero, movimiento de 2 nativos y registro de 7 tokens.

INFERRED: salida objetivo exitosa 10, entrada 4, neto−6; final 94. Comisiones nativas T1–T3 totalizan 0.04.

UNKNOWN: historial anterior, operadores humanos, comisiones E1 y motivos.

INSUFFICIENT EVIDENCE: H2/H3 no añaden20 tokens transferidos adicionales. El intento T2 no cuenta como salida exitosa de 20 tokens. La llamada anidada de E1 no es una segunda transacción firmada independientemente.

Sumar resúmenes y cambios a transferencias; equiparar inclusión y éxito; tratar cada referencia de dirección como acción; mezclar comisiones nativas con tokens; eliminar registros no disponibles de una afirmación de cobertura.

Construir un registro de tokens deduplicado para T1–T3. Calcular flujo bruto y neto, saldo final y comisiones. Clasificar llamada y movimientos de activos de E1 sin sumar activos distintos.

• Registrar descubrimiento y cobertura histórica.
• Verificar resultado de ejecución separado de finalidad.
• Identificar eventos por transacción y ruta.
• Conciliar flujo bruto y saldo neto.
• Contar comisiones una vez y conservar pagador/activo.
• Distinguir llamadas, registros y atribución humana.

Reconstruir historial es contabilidad de eventos, no conteo de líneas. Movimientos exitosos, intentos fallidos y comisiones responden preguntas distintas.

Varias vistas pueden describir una transferencia. Llamadas anidadas no son transacciones firmadas aparte. Los registros faltantes quedan no resueltos, no ausentes.

Cronología T1–T3 con H1/H2/H3 agrupados como evento único, T2 fallido con comisión aún suministrada, T3 entrante4. Mostrar flujo10/4/neto−6/final 94 y panel separado de comisión 0.04. Separar árbol de llamadas E1 de filas de importes nativos/tokens.

Contabilidad ilustrativa de eventos; filas y llamadas anidadas no son transacciones independientes.

Usar SVG/HTML determinista o gráficos con unidades, localizadores de evidencia y alternativas textuales. Azul marino/negro con cian, azul eléctrico y violeta discretos; sin capturas decorativas o fabricadas de exploradores. A 390px apilar anotaciones; verificar 768px, escritorio y RTL árabe cuando se implementen los recursos. Mantener identificadores LTR y las direcciones fácticas de tiempo/aristas/ejes sin cambios. Usar únicamente la marca oficial BlockAssay suministrada. Ambos registros visuales siguen siendo especificaciones.

WALLET_INTELLIGENCE corresponde a la inspección de solo lectura de registros de direcciones públicas, relaciones y procedencia. Verificar red compatible, identificadores exactos, campos y cobertura antes de cualquier integración en ejecución; aquí no se afirma ninguna capacidad de proveedor en vivo. Usar el ejercicio sin conexión incluido si faltan datos o acceso de pago. No se requiere conexión de cartera, credenciales, clave privada, firma ni operación real de mercado. Los datos ausentes siguen desconocidos. El progreso Academy, estatus de creador, pagos y referidos nunca alteran la evidencia Radar.

• Solana getSignaturesForAddress — Historial de firmas que referencian la dirección, orden de más reciente a más antiguo y paginación. Comprobado el 2026-09-30.
• Solana getTransaction — Consulta de transacciones, compromiso de confirmación y campos de datos/tiempo que pueden ser nulos. Comprobado el 2026-09-30.
• Estructuras JSON del RPC Solana — Metadatos de resultado, comisión, instrucciones y saldos como vistas distintas. Comprobado el 2026-09-30.
• Comisiones Solana — Mecanismo de comisiones nativas de transacción; no es movimiento de tokens ni modelo universal de costes. Comprobado el 2026-09-30.
• Trazadores integrados de Geth — Alcance de trazas de marcos de llamada y configuración específica del trazador. Comprobado el 2026-09-30.
• API de ejecución Ethereum eth_getTransactionReceipt — Estado del recibo, enlace con la transacción y registros de eventos. Comprobado el 2026-09-30.

Todos los registros de ejemplo son conjuntos originales ILLUSTRATIVE, no mediciones históricas/en vivo de la cadena. La documentación explica mecanismos, no importes ni etiquetas inventados. La cronología sintética está explícitamente delimitada; observedAt=null es intencional. OBSERVED en un ejercicio significa un registro suministrado del conjunto. Revisar nuevamente la documentación y la decodificación desplegada antes de publicar. Las etiquetas de proveedor no establecen identidad; el control de direcciones y la atribución humana requieren evidencias distintas.

P09-L03 después del ejercicio resuelto y la revisión de preguntas.