Contrapartes

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

Una cartera puede llamar a un enrutador, enviar tokens a una dirección de custodia y recibir una transferencia no solicitada. Un grafo puede mostrar los tres como contrapartes aunque representan relaciones diferentes. Describirlos como socios o afiliados inventa un significado que el registro no proporciona.

Esta lección construye una tabla tipada de contrapartes y un registro separado de etiquetas de proveedor. Distinguirás interacciones técnicas, movimientos exitosos y afirmaciones de entidad no verificadas.

Definir contraparte por tipo de evento

En una transferencia directa de valor, fuente y destino decodificados son puntos de movimiento. En una llamada contractual, la dirección llamada es punto de ejecución. En un registro de token, contrato emisor y campos from/to tienen roles diferentes. Especificar la relación medida.

Una lista sin regla no permite comparación reproducible. «Destinatarios únicos de transferencia» difiere de «todos los contratos llamados». Una transacción puede contener ambas categorías. No combinarlas en un conteo único denominado número de relaciones comerciales.

Identidad del activo y red siguen siendo necesarias. Una transferencia TOKEN-A y otra TOKEN-B son cantidades separadas incluso con igual destinatario. Una llamada de valor cero establece interacción de ejecución sin establecer pago nativo.

Leer cuidadosamente ejecución anidada

Geth callTracer representa marcos de llamada y puede configurarse para incluir solo la llamada superior [S09-TRACES]. Una configuración incompleta puede omitir interacciones anidadas. Registrar si la fuente cubre la profundidad relevante en lugar de asumir que el receptor superior es el único punto de ejecución.

Un enrutador puede delegar o encaminar actividad por otros contratos. La cuenta llamada por el usuario puede no recibir el movimiento final de tokens. El grafo debe conservar ambas aristas con tipos distintos en lugar de fingir que son duplicadas o relaciones económicas equivalentes.

Los registros de recibo Ethereum contienen enlace de transacción e información de evento [S09-RECEIPT]. Decodificar requiere emisor y semántica correctos. Emitir un evento Transfer de tokens no convierte al contrato en comprador, destinatario o afiliado de cada dirección nombrada.

Distinguir participación y relación voluntaria

En Solana, una búsqueda de firmas encuentra transacciones que referencian una dirección en accountKeys [S09-SIGNATURES]. Referenciarla no significa que autorizó la transacción. Inspeccionar firmantes, instrucciones y efectos antes de asignar rol activo.

Una transferencia entrante puede ser no solicitada. Recibir no prueba consentimiento, pertenencia ni asociación. Incluso interacción directa repetida puede corresponder al uso ordinario de un servicio público, no afiliación.

Una transferencia mediada por contrato puede involucrar delegado o política de aplicación. No concluir que el tenedor visible firmó personalmente cada movimiento. Los metadatos separan roles de cuenta y vistas de ejecución [S09-STRUCTURES]; intención humana requiere evidencia adicional.

Guardar etiquetas como afirmaciones de fuente

Una etiqueta de proveedor debe tener publicador, dirección/red exactas, contexto de captura/actualización, texto, fundamento y estado de verificación. Señalar los campos ausentes. «Exchange-X» junto a una dirección no es identidad de entidad establecida independientemente.

Dos interfaces con el mismo flujo de etiquetas subyacente no aportan dos confirmaciones independientes. La coincidencia puede motivar investigación manteniendo explícita la dependencia. Si las fuentes discrepan, conservar ambas etiquetas y el conflicto.

Un mecanismo verificado de depósito de servicio, cuando realmente esté establecido, tampoco identificaría al usuario beneficiario de la cuenta ni probaría que el traslado fue venta. Afiliación técnica, custodia de servicio e identidad personal son preguntas distintas.

Contar la unidad pretendida

Usar claves únicas de eventos exitosos para conteos de movimiento. Usar direcciones finales únicas para destinatarios bajo activo/ventana declarados. Envíos repetidos a una dirección cuentan como varios eventos pero un destinatario único.

Excluir intentos fallidos de totales exitosos y conservarlos en tabla de intentos. No borrarlos de la investigación. Si el resultado no está disponible, mantenerlo no resuelto; una fila bonita no permite inferir éxito o fallo.

En informe por dirección, distinguir aristas entrantes y salientes. Recibir de un contrato no equivale a llamarlo. Un viaje de ida y vuelta no prueba propiedad ni finalidad de reembolso sin evidencia de mecanismo.

Expresar qué reforzaría la afirmación

Para un rol técnico, pedir operaciones decodificadas, código/interfaz binaria de aplicación (ABI) correctos, cobertura de trazas y saldos coherentes. Para identidad del proveedor, pedir fundamento de etiquetado y corroboración independiente. Para afiliación, precisar evidencia organizativa o autenticada necesaria.

No buscar identidad personal solo porque una dirección pública resulte interesante. Mantener la pregunta proporcionada al objetivo educativo. El ejercicio no contiene personas reales ni direcciones utilizables y no requiere atribución más allá de registros suministrados.

Un hallazgo delimitado como «W hizo dos envíos TOKEN-A exitosos a X; X está etiquetado Exchange-X por un flujo compartido único, no verificado aquí» es informativo. No implica venta, asociación ni propietario común.

Mantener límites causales y financieros

Interacción no establece afiliación. Un gran traslado a un servicio etiquetado no establece operación de mercado. Que un gráfico cambie después no prueba que el traslado lo causó. Esas conclusiones necesitan evidencia separada y no se recuperan del conteo de contrapartes.

La finalidad es un vocabulario exacto de relaciones. Más aristas no son necesariamente evidencia más fuerte de relación humana. A veces varias líneas simplemente exponen más maquinaria interna de una transacción pública.

• Punto de ejecución: dirección llamada durante ejecución.
• Punto de movimiento: fuente o destino de una transferencia decodificada de activo.
• Emisor: contrato que produce un registro de evento.
• Destinatario único: destino distinto bajo regla declarada.
• Afirmación de proveedor: etiqueta publicada pendiente de evaluación de alcance/procedencia.
• Afiliación: relación organizativa que necesita evidencia independiente.

ILLUSTRATIVE — FIX-P09-04. SIM-EVM-A, W, orden sintético T1–T4. Importes TOKEN-A normalizados. Todos los resultados listados se suministran, no se miden.

No se suministran registros de venta, afiliación organizativa ni evidencia de control humano. Las etiquetas tienen captura sintética T5; no existe marca temporal real.

OBSERVED en el conjunto: W llama a ROUTER; se suministran interacción POOL anidada y dos envíos TOKEN-A a X. L1/L2 comparten fuente de etiqueta; L3 discrepa.

INFERRED: total exitoso saliente TOKEN-A 15, con un destinatario exitoso único X bajo esta ventana/regla. C6 añade destinatario intentado Y, no flujo exitoso.

UNKNOWN: entidad detrás de X, consentimiento de recepción C5, motivos y propietarios beneficiarios.

INSUFFICIENT EVIDENCE: interacciones ROUTER/POOL no prueban afiliación. L1/L2 no son prueba independiente de identidad; L3 no resuelve el conflicto. Recepción X no establece venta.

Contar emisor como destinatario; tratar llamadas de enrutador como asociaciones; mezclar puntos anidados y directos sin tipos; adoptar etiquetas copiadas como confirmación independiente; interpretar recepción no solicitada como pertenencia voluntaria.

Producir tabla tipada de relaciones y estadística saliente exitosa TOKEN-A. Separar afirmaciones de etiquetas de entidad de registros del libro. Reescribir «W vendió15 a su afiliado Exchange-X y recibió un pago de socio».

• Definir reglas de relación y conteo.
• Separar llamante, punto anidado, emisor y destinatario.
• Verificar resultado y cobertura de trazas.
• Registrar etiquetas con dependencias de fuente.
• Preservar posibilidades de recepción no solicitada/intención desconocida.
• Evitar conclusiones de afiliación, venta e identidad sin evidencia.

Analizar contrapartes describe interacciones específicas. Participación técnica y entidades etiquetadas no establecen automáticamente relaciones económicas u organizativas.

Interacción no es afiliación. Destinatarios repetidos difieren de eventos repetidos. Etiquetas de proveedor son afirmaciones con procedencia y conflictos.

Usar estilos de arista distintos para llamadas y transferencias con IDs de registro; emisor TOKEN-A separado. Marcar C6 fallido, consentimiento C5 desconocido. Mostrar etiquetas X en registro de fuentes con corchete de flujo compartido L1/L2 y conflicto L3, sin distintivo de identidad.

Tipos ilustrativos de contraparte; interacción no prueba afiliación.

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.

• 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.
• 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.
• Estructuras JSON del RPC Solana — Metadatos de resultado, comisión, instrucciones y saldos como vistas distintas. 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-L05 después del ejercicio resuelto y la revisión de preguntas.