Histórico de transações

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

Uma página de transação pode mostrar transferência, instrução, resumo descodificado e alteração de saldo. Podem ser várias vistas do mesmo evento. Somar cada linha aumenta artificialmente a atividade; ignorar estado de execução pode transformar tentativas falhadas em transferências bem-sucedidas.

Esta lição ensina um registo histórico que separa identidade de evento, sucesso, atividade aninhada e taxas. Prepara a análise de financiamento sem assumir que toda referência de endereço significa pagamento.

Definir a cobertura histórica

Escrever rede, endereço alvo, contas de tokens relacionadas, janela pedida e método de recolha. Solana getSignaturesForAddress devolve assinaturas que referenciam o endereço pedido em accountKeys, das mais recentes às mais antigas, com parâmetros de paginação [S09-SIGNATURES]. Uma página devolvida é lista de descoberta, não registo completo de transferências.

Um endereço referenciado não tem de ser signatário ou destinatário. Instruções podem referenciar programas, contas de dados e estado só de leitura. Examinar o papel do registo antes de contar participação como ação. Consultar um endereço proprietário também pode não descobrir todas as operações de contas de tokens separadas; examinar cobertura pretendida em vez de declarar histórico completo.

Deduplicar assinaturas entre páginas sobrepostas, preservando instruções diferentes na mesma transação. Ordenar segundo ordem disponível de slot/bloco e evidência de ordem dentro do contexto. A ordem apresentada pela interface não é automaticamente a ordem exata de execução.

Verificar resultado antes de contar efeitos

Obter metadados de execução dos registos descobertos. Solana getTransaction pode devolver null no compromisso pedido e tem campos de tempo ou metadados que podem ser nulos [S09-TRANSACTION]. Tratar obtenção ausente como não resolvida, não como evento falhado ou inexistente.

Um registo confirmado/incluído pode ainda conter operação falhada. Registar sucesso separado de finalidade. Montante submetido descreve intenção; efeito bem-sucedido no saldo descreve execução. Para T2 falhado do conjunto, efeitos de transferência de tokens são explicitamente zero enquanto a taxa nativa fornecida continua cobrada.

Não universalizar afirmações simplificadas de reversão a todas as funcionalidades da cadeia. O exercício exclui mudanças de autorização e outros mecanismos fora de transferências. A tabela de resultados fornece diretamente os efeitos relevantes. Em análise real examinar regras efetivas do protocolo e diferenças de estado.

Separar identidade do evento e linhas apresentadas

Escolher chave de evento: rede, assinatura/hash da transação e caminho de instrução ou índice de registo, conforme aplicável. Instrução de transferência, resumo descodificado e variação correspondente de saldo podem corroborar um evento. Não são três transferências separadas.

Variação de saldo é resultado líquido. Se uma conta envia 10 e recebe 4 na janela, a variação é−6 e a saída bruta é 10. A variação não apaga a entrada; somar movimento bruto e variação líquida duplica a contagem.

Chamadas aninhadas têm semântica própria. O callTracer do Geth descreve quadros de chamada com âmbito configurável [S09-TRACES]. Uma chamada interna integra transação principal, não transação assinada separadamente. Alguns quadros transportam valor nativo; outras chamadas transportam zero e executam código. Não contar toda chamada como pagamento.

Distinguir chamadas, registos e movimentos de tokens

Um recibo EVM fornece ligação à transação, estado e registos [S09-RECEIPT]. Registo de evento de token e chamada com valor nativo são registos diferentes. O contrato de token que emite um registo Transfer não é necessariamente destinatário económico.

Em Solana, metadados de resultado distinguem instruções, instruções internas, taxas e saldos [S09-STRUCTURES]. Instrução interna pode identificar mecanismo dentro de operação principal. Resumo da mesma instrução deve usar o mesmo localizador de evento.

Uma chamada de contrato com registo de transferência de tokens pode ser um movimento económico de tokens e uma relação de chamada, não dois movimentos de tokens. Preservar ambas as observações em tabelas tipadas e escolher unidade de contagem adequada à pergunta.

Manter taxas separadas

Taxas usam ativo nativo da rede e têm pagador específico. Não são transferências do token alvo. Documentação Solana descreve mecanismo de taxa nativa de transação [S09-FEES]. Não assumir que todo endereço visível pagou a taxa ou que toda tentativa falhada foi grátis.

Contar taxas uma vez por resultado de transação fornecido, não por instrução ou linha de resumo. Converter unidades brutas usando precisão nativa se o conjunto real a fornecer. O exercício fornece unidades fictícias normalizadas de taxas sem conversão de preço.

Reconciliar movimentos de tokens e custos nativos separadamente. Variação de tokens pode estar correta enquanto saldo nativo inclui renda, depósitos ou efeitos não relacionados. O conjunto exclui-os explicitamente; registos reais exigem reconciliação adicional.

Construir tabela histórica delimitada

Usar colunas de localizador de evento, papel do objeto, resultado, ativo, direção, montante bruto, pagador de taxa e incerteza. Manter lista separada de registos não resolvidos. Não eliminar registos ausentes para fazer a contagem visível de sucessos parecer completa.

Contar transações bem-sucedidas de transferência de tokens difere de contar eventos de transferência. Uma transação pode ter vários eventos. Declarar a estatística apresentada. Tentativa falhada pode integrar contagem de tentativas contribuindo zero para movimento bem-sucedido.

Descrição final deve nomear janela e cobertura fornecida. Histórico ensina o que aconteceu nos registos disponíveis, não por que um ator o escolheu. Transferência bem-sucedida não prova afiliação nem é sinal de preço.

• Resultado de execução: sucesso/falha da operação examinada.
• Localizador de evento: transação e caminho de instrução/registo.
• Quadro de chamada: execução aninhada dentro de uma transação.
• Fluxo bruto: soma de movimentos numa direção.
• Variação líquida: saldo final menos inicial.
• Pagador da taxa: conta que suporta o custo nativo fornecido.

ILLUSTRATIVE — FIX-P09-02. SIM-SOL-A / W / MINT-T. Efeitos completos apenas para T1–T3, ordem sintética S1,S2,S3. Taxas nativas normalizadas e pagas por W. Sem outros efeitos na janela. Saldo inicial de tokens 100.

Exemplo SIM-EVM-A separado E1 tem sucesso com chamada principal W-E→ROUTER de valor0; chamada aninhada ROUTER→C-E de valor nativo2 e um registo Transfer de tokens para7 unidades de W-E para C-E. O conjunto estipula ativos/efeitos distintos e cobertura completa de chamadas. Não é fornecida taxa para E1.

OBSERVED no conjunto: três vistas de T1 descrevem uma transferência de10 tokens; T2 falha; T3 recebe 4. E1 contém chamada de valor zero, movimento de 2 nativos e registo de 7 tokens.

INFERRED: saída alvo bem-sucedida 10, entrada 4, líquido−6; final 94. Taxas nativas T1–T3 somam 0.04.

UNKNOWN: histórico anterior, operadores humanos, taxas E1 e motivos.

INSUFFICIENT EVIDENCE: H2/H3 não acrescentam20 tokens transferidos. Tentativa T2 não conta como saída bem-sucedida de 20 tokens. Chamada aninhada de E1 não é segunda transação assinada independentemente.

Somar resumos e variações às transferências; equiparar inclusão a sucesso; tratar referência de endereço como ação; misturar taxas nativas com tokens; excluir registos indisponíveis de afirmações de cobertura.

Construir registo deduplicado de tokens para T1–T3. Calcular fluxos brutos e líquido, saldo final e taxas. Classificar chamada e movimentos de ativos de E1 sem totalizar ativos diferentes.

• Registar descoberta e cobertura histórica.
• Verificar resultado de execução separado de finalidade.
• Identificar eventos por transação e caminho.
• Reconciliar fluxo bruto e saldo líquido.
• Contar taxas uma vez e preservar pagador/ativo.
• Distinguir chamadas, registos e atribuição humana.

Reconstrução histórica é contabilidade de eventos, não contagem de linhas. Movimentos bem-sucedidos, tentativas falhadas e taxas respondem a perguntas diferentes.

Várias vistas podem descrever uma transferência. Chamadas aninhadas não são transações assinadas separadamente. Registos ausentes ficam não resolvidos em vez de inexistentes.

Cronologia T1–T3 com H1/H2/H3 agrupados num evento, T2 falhada com taxa ainda fornecida, T3 entrada4. Mostrar fluxo10/4/líquido−6/final 94 e painel separado de taxa 0.04. Separar árvore de chamadas E1 das linhas de montantes de tokens/nativos.

Contabilidade ilustrativa de eventos; linhas e chamadas aninhadas não são transações independentes.

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.

• 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.
• Solana getTransaction — Consulta de transações, compromisso de confirmação e campos de dados/tempo que podem ser nulos. 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.
• Taxas Solana — Mecanismo de taxas nativas de transação; não é movimento de tokens nem modelo universal de custos. Verificado em 2026-09-30.
• 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.

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-L03 após o exercício resolvido e a revisão das perguntas.