Contrapartes

Master de origem EN · P09-L04 · 45 minutos estimados · needs_review

Uma carteira pode chamar um encaminhador, enviar tokens para endereço de custódia e receber transferência não solicitada. Um grafo pode apresentar os três como contrapartes apesar de serem relações diferentes. Descrevê-los como parceiros ou afiliados inventa significado que o registo não fornece.

Esta lição constrói tabela tipada de contrapartes e registo separado de rótulos de fornecedor. Distinguirá interações técnicas, movimentos bem-sucedidos e afirmações de entidade não verificadas.

Definir contraparte por tipo de evento

Para transferência direta de valor, origem e destino descodificados são pontos de movimento. Para chamada de contrato, endereço chamado é ponto de execução. Para registo de token, contrato emissor e campos from/to têm papéis diferentes. Especificar a relação medida.

Lista de contrapartes sem regra não permite comparação reproduzível. «Destinatários únicos de transferência» difere de «todos os contratos chamados». Uma transação pode conter ambas as categorias. Não as combinar numa contagem única chamada número de relações comerciais.

Identidade do ativo e rede continuam necessárias. Transferência TOKEN-A e transferência TOKEN-B são quantidades separadas mesmo com destinatário igual. Chamada de valor zero pode estabelecer interação de execução sem pagamento nativo.

Ler cuidadosamente execução aninhada

Geth callTracer representa quadros de chamada e pode incluir apenas chamada principal conforme configuração [S09-TRACES]. Configuração incompleta pode omitir interações aninhadas. Registar se a fonte cobre profundidade relevante em vez de assumir que destinatário principal é único ponto de execução.

Um encaminhador pode delegar ou encaminhar atividade através de outros contratos. Conta chamada pelo utilizador pode não receber o movimento final de tokens. Grafo de interação deve manter ambas as arestas com tipos diferentes em vez de as tratar como duplicadas ou relações económicas equivalentes.

Registos de recibos Ethereum transportam ligação à transação e informação de evento [S09-RECEIPT]. Descodificação exige emissor e semântica corretos. Emitir evento Transfer de tokens não torna contrato comprador, destinatário ou afiliado de todo endereço referido.

Distinguir participação e relação voluntária

Em Solana, pesquisa de assinaturas encontra transações que referenciam endereço em accountKeys [S09-SIGNATURES]. Referência sozinha não significa autorização por esse endereço. Examinar signatários, instruções e efeitos antes de atribuir papel ativo.

Transferência de entrada pode ser não solicitada. Receção não prova consentimento, pertença ou parceria. Mesmo interação direta repetida pode ser uso normal de serviço público em vez de afiliação.

Transferência mediada por contrato pode envolver delegado ou política da aplicação. Não concluir que detentor visível assinou pessoalmente cada movimento. Metadados de resultado separam papéis de contas e vistas de execução [S09-STRUCTURES]; intenção humana exige evidência adicional.

Guardar rótulos como afirmações da fonte

Rótulo de fornecedor deve ter editor, endereço/rede exatos, contexto de captura/atualização, texto, fundamento e estado de verificação. Declarar campos ausentes. «Exchange-X» junto de endereço não é identidade de entidade estabelecida independentemente.

Duas interfaces que usam a mesma fonte subjacente de rótulos não fornecem duas confirmações independentes. Concordância pode motivar investigação mantendo dependência explícita. Se fontes divergem, manter ambos os rótulos e conflito.

Mecanismo verificado de depósito num serviço, quando efetivamente estabelecido, ainda não identificaria utilizador beneficiário da conta nem provaria venda. Afiliação técnica, custódia de serviço e identidade pessoal são perguntas separadas.

Contar a unidade pretendida

Usar chaves únicas de eventos bem-sucedidos para contar movimentos. Usar endereços de destino únicos para contar destinatários num ativo/janela declarados. Envios repetidos para um endereço contam vários eventos mas um destinatário único.

Excluir tentativas falhadas de fluxos bem-sucedidos mantendo tabela de tentativas. Não as apagar da investigação. Resultado indisponível fica não resolvido; linha bonita de interface não permite inferir sucesso nem falha.

Para relatório direcional distinguir arestas de entrada e saída. Receber de contrato não equivale a chamá-lo. Ida e volta não prova propriedade ou reembolso sem evidência de mecanismo.

Declarar o que reforçaria a afirmação

Para papel técnico pedir operações descodificadas, código/interface binária da aplicação (ABI) corretos, cobertura de rastreio e saldos coerentes. Para identidade de fornecedor pedir fundamento do rótulo e corroborar independentemente. Para afiliação especificar evidência organizacional ou autenticada necessária.

Não procurar identidade pessoal só porque endereço público é interessante. Manter pergunta proporcional ao objetivo educativo. O exercício não contém pessoas reais nem endereços utilizáveis e não exige investigação de atribuição além dos registos fornecidos.

Resultado delimitado como «W fez dois envios TOKEN-A bem-sucedidos para X; X está rotulado Exchange-X por uma fonte partilhada única, não verificada aqui» é informativo. Não implica venda, parceria ou proprietário comum.

Manter limites causais e financeiros

Interação não estabelece afiliação. Grande transferência para serviço rotulado não estabelece operação de mercado. Gráfico que muda depois não estabelece causa pela transferência. Conclusões posteriores exigem evidência separada e não vêm de uma contagem de contrapartes.

Objetivo é vocabulário exato de relações. Mais arestas não são necessariamente evidência mais forte de relação humana. Por vezes várias linhas apenas revelam mais mecanismos internos de uma transação pública única.

• Ponto de execução: endereço chamado durante execução.
• Ponto de movimento: origem ou destino de transferência descodificada de ativo.
• Emissor: contrato que produz registo de evento.
• Destinatário único: destino distinto sob regra declarada.
• Afirmação de fornecedor: rótulo publicado à espera de avaliação de âmbito/proveniência.
• Afiliação: relação organizacional que exige evidência independente.

ILLUSTRATIVE — FIX-P09-04. SIM-EVM-A, W, ordem sintética T1–T4. Montantes TOKEN-A normalizados. Todos os resultados listados são fornecidos, não medidos.

Sem registos de venda, afiliação organizacional ou evidência de controlo humano fornecidos. Rótulos têm captura sintética T5; não existe instante real registado.

OBSERVED no conjunto: W chama ROUTER; interação aninhada POOL e dois envios TOKEN-A para X são fornecidos. L1/L2 partilham fonte de rótulo; L3 diverge.

INFERRED: total de saída TOKEN-A bem-sucedida 15, com um destinatário único X nesta janela/regra. C6 acrescenta destinatário de tentativa Y, não fluxo bem-sucedido.

UNKNOWN: entidade por trás de X, consentimento de receção C5, motivos e proprietários beneficiários.

INSUFFICIENT EVIDENCE: interações ROUTER/POOL não provam afiliação. L1/L2 não são prova independente de identidade; L3 não resolve conflito. Receção por X não estabelece venda.

Contar emissor como destinatário; tratar chamadas de encaminhador como parcerias; fundir pontos aninhados e diretos sem tipos; adotar rótulos copiados como confirmação independente; interpretar receção não solicitada como pertença voluntária.

Produzir tabela tipada de relações e estatística de saída TOKEN-A bem-sucedida. Separar afirmações de rótulos de entidade e registos do livro. Reescrever «W vendeu15 ao seu afiliado Exchange-X e recebeu pagamento de parceiro».

• Definir regras de relação e contagem.
• Separar chamador, ponto aninhado, emissor e destinatário.
• Verificar resultado e cobertura de rastreio.
• Registar rótulos com dependências de fonte.
• Preservar possibilidades de receção não solicitada/intenção desconhecida.
• Evitar conclusões de afiliação, venda e identidade sem evidência.

Análise de contrapartes descreve interações específicas. Participação técnica e entidades rotuladas não estabelecem automaticamente relações económicas ou organizacionais.

Interação não é afiliação. Destinatários repetidos diferem de eventos repetidos. Rótulos de fornecedor são afirmações com proveniência e conflitos.

Usar estilos distintos de arestas de chamadas e transferências com IDs de registo; emissor TOKEN-A separado. Marcar C6 falhada e consentimento C5 desconhecido. Mostrar rótulos X em registo de fontes com agrupamento L1/L2 de fonte partilhada e conflito L3, sem distintivo de identidade.

Tipos ilustrativos de contrapartes; interação não prova afiliação.

Usar SVG/HTML determinista ou gráficos com unidades, localizadores de evidência e alternativas textuais. Azul-marinho/preto com ciano, azul elétrico e violeta discretos; sem capturas decorativas ou fabricadas de exploradores. A 390px empilhar anotações; verificar 768px, computador e RTL árabe quando os recursos forem implementados. Manter identificadores LTR e direções factuais de tempo/arestas/eixos inalteradas. Usar apenas a marca oficial BlockAssay fornecida. Ambos os registos visuais continuam especificações.

WALLET_INTELLIGENCE corresponde à inspeção só de leitura de registos de endereços públicos, relações e proveniência. Verificar rede suportada, identificadores exatos, campos e cobertura antes de integrar na execução; não se afirma aqui qualquer capacidade de fornecedor em direto. Usar o exercício offline incluído se faltarem dados ou acesso pago. Não é necessária ligação de carteira, credenciais, chave privada, assinatura ou operação real de mercado. Dados ausentes continuam desconhecidos. Progresso Academy, estatuto de criador, pagamentos e referências nunca alteram evidência Radar.

• Rastreadores integrados do Geth — Âmbito de rastreio dos quadros de chamada e configuração específica do rastreador. Verificado em 2026-09-30.
• API de execução Ethereum eth_getTransactionReceipt — Estado do recibo, ligação à transação e registos de eventos. Verificado em 2026-09-30.
• Solana getSignaturesForAddress — Histórico de assinaturas que referenciam o endereço, ordem da mais recente à mais antiga e paginação. Verificado em 2026-09-30.
• Estruturas JSON do RPC Solana — Metadados de resultado, taxa, instruções e saldos como vistas distintas. Verificado em 2026-09-30.

Todos os registos de exemplo são conjuntos originais ILLUSTRATIVE, não medições históricas/em direto da cadeia. A documentação explica mecanismos, não montantes ou rótulos inventados. A cronologia sintética é explicitamente delimitada; observedAt=null é intencional. OBSERVED num exercício significa um registo fornecido do conjunto. Rever documentação e descodificação implementada antes de publicar. Rótulos de fornecedor não estabelecem identidade; controlo de endereços e atribuição humana exigem evidências distintas.

P09-L05 após o exercício resolvido e a revisão das perguntas.