Verificação exata de contrato e mint

Fonte mestra EN · P08-L01 · 45 minutos estimados · needs_review

Todo cálculo posterior depende da análise do ativo pretendido. Uma auditoria correta de permissões do contrato errado ainda é uma investigação malsucedida. Nomes, símbolos e ícones ajudam na navegação, mas não podem servir como chaves primárias. Esta lição amplia o reconhecimento exato do mint para um registro de identidade reproduzível que distingue o papel da conta e a lógica que a rege.

Você corresponderá um alvo declarado aos registros fornecidos, identificará evidências de implementação ausentes e escreverá um resultado que outro analista possa repetir. Você não assinará, aprovará ou comprará nada.

Construa a tupla de identidade

Comece com rede, endereço exato e tipo de objeto. Distinga mainnet de ambientes de teste e de diferentes redes EVM. Uma string com formato de endereço, sozinha, é incompleta. Uma URL de explorador pode selecionar outra rede mesmo quando o endereço exibido parece familiar. Preserve a rede solicitada quando uma busca retornar um semelhante mais popular.

Escreva o identificador completo em vez de um prefixo abreviado. Na inspeção real, valide a codificação e compare os bytes decodificados do endereço com uma ferramenta confiável. Maiúsculas e minúsculas do checksum EVM e convenções base58 da Solana exigem tratamentos diferentes. O conjunto de dados usa rótulos inválidos para que nenhum aluno possa transacionar com eles acidentalmente; suas comparações são comparações educacionais de strings.

Pergunte qual objeto o identificador nomeia. Um mint Solana é distinto de uma conta de token que detém unidades e do Token Program que contém a lógica das instruções [S08-TOKENS]. Uma implementação EVM atrás de um proxy não é automaticamente o endereço de saldo voltado ao usuário. Descreva o papel antes de usar os valores.

Separe existência, lógica e afiliação

Uma fonte que retorna uma conta é evidência de um objeto em um contexto, não de que uma marca o endossa. A verificação de código-fonte de um explorador trata da correspondência entre fonte e código implantado; não certifica afiliação oficial nem completude de auditoria. Essas perguntas exigem registros separados [S08-CODE]. O Etherscan distingue correspondências exatas de semelhantes; correspondência semelhante pode deixar diferenças de construtor ou inicialização. Inspecione o tipo declarado de correspondência em vez de tratar todo selo como a mesma conclusão.

Use resultados distintos: objeto exato correspondido, implementação não resolvida e afiliação não corroborada. Uma correspondência positiva de identidade não resolve os outros dois. Se correspondência de código for fornecida, preserve compilador, configuração e escopo de implantação em vez de parafraseá-la como “seguro”.

ERC-20 descreve uma interface; nome e símbolo são metadados opcionais, e compatibilidade não certifica um projeto [S08-ERC20]. Portanto, receber o símbolo esperado não resolve afiliação. Uma implementação pode expor métodos familiares e incluir controles adicionais não descritos pela interface básica.

Trace o limite da lógica

Para um mint Solana, registre o Token Program proprietário de sua conta de dados. Não confunda o campo básico de proprietário do programa com o campo de proprietário da conta de token usado para posições. Um mint com extensões exige decodificação que as reconheça. Um parser básico que ignora estado adicional não pode estabelecer que nenhum comportamento adicional existe.

Para um proxy, o endereço solicitado do token pode permanecer estável enquanto a lógica delegada muda. ERC-1967 descreve ligação de implementação ou beacon e um slot opcional de administrador [S08-PROXY]. A implantação real determina a aplicabilidade; slots padrão vazios não estabelecem que todo mecanismo possível de atualização está ausente.

Mantenha endereço do proxy, implementação e contexto juntos. Código em um contexto e estado em outro criam um registro misto. Se a ligação estiver indisponível, identifique o objeto voltado ao usuário marcando a resolução da lógica como incompleta. Nunca preencha essa lacuna com qualquer contrato que uma interface rotule como “implementação”.

Preserve a procedência da consulta

Registre fonte, horário de consulta, contexto de bloco ou slot quando retornado, commitment/finalidade e premissas do decodificador. Um timeout significa dados indisponíveis. Uma resposta da rede errada é incompatibilidade, não ausência na rede pretendida. Não tente novamente silenciosamente em outra rede combinando esses valores.

Duas interfaces podem compartilhar um indexador. Concordância é útil, mas não constitui automaticamente duas observações independentes. Registre a fonte subjacente se visível; caso contrário, diga que a independência é desconhecida. Um registro bruto e sua decodificação são mais reproduzíveis que uma imagem recortada sem o identificador exato.

Separe alvos declarados de corroborados. Uma captura de tela que alega um endereço oficial é uma declaração. Correspondê-la prova apenas que você inspecionou o objeto nomeado. Afiliação exige fontes do emissor adequadamente autenticadas com contexto de captura, e mesmo afiliação corroborada não prova segurança.

Use uma regra de parada

Interrompa conclusões dependentes da identidade quando a tupla não corresponder ou o papel do objeto não estiver resolvido. Você ainda pode documentar a lacuna; não pode anexar oferta ou permissões de outro ativo ao alvo. Uma correspondência genérica de resultado de busca não substitui isso.

Uma conclusão concisa poderia dizer: “A rede/endereço solicitados resolvem para um mint no S0 fornecido. Seu inventário de extensões e sua afiliação ao emissor não são fornecidos.” Isso preserva a conclusão positiva e seus limites. Um registro completo também deve dizer qual evidência adicional permitiria a próxima etapa.

Um revisor independente deve poder partir de sua tupla sem adivinhar qual aba de rede ou endereço truncado você selecionou. Verificação somente de leitura protege esse fluxo: nenhuma aprovação de carteira é necessária para estabelecer a identidade de um objeto, e nenhum exercício exige credenciais.

• Tupla de identidade: rede, endereço completo e papel do objeto.
• Mint: conta Solana que representa um token.
• Conta de token: conta separada que detém unidades de um mint.
• Implementação: lógica usada por um contrato delegado.
• Procedência: fonte e contexto que sustentam um registro.
• Afiliação: relação alegada com emissor ou marca.

ILLUSTRATIVE — FIX-P08-01. S0 é fictício, não um bloco real. A declaração D1 solicita SIM-SOL-A / MINT-ALPHA como mint; a atribuição ao emissor não está autenticada.

I1 contém campos básicos, mas nenhum inventário de extensões. I5 tem ligação, mas não correspondência de fonte/build.

OBSERVED no conjunto de dados: I1 corresponde à tupla de D1; I3 referencia seu mint, mas tem papel diferente.

INFERRED: I1 é o registro inicial correto para inspeção básica. I5/I6 descrevem uma ligação de proxy fornecida separadamente.

UNKNOWN: Afiliação, estado de extensões omitido e correspondência de código/build de I5.

INSUFFICIENT EVIDENCE: Símbolos iguais não podem fazer de I2/I4 o alvo. I6, que contém lógica, não pode substituir I5, voltado ao usuário.

Corresponder apenas símbolos, esquecer a rede, substituir um mint por conta de detenção, analisar saldos da implementação e chamar visibilidade de fonte de certificado de segurança.

Escolha a correspondência de D1; rejeite I2–I4 com razões individuais. Escreva uma nota de identidade separada para I5. Liste três lacunas de evidência antes de uma revisão completa do comportamento de I1.

• Preserve rede e identificador completo.
• Verifique papel e ligação programa/lógica.
• Corresponda contextos antes de combinar evidências.
• Separe afiliação de revisão de código.
• Pare quando entradas dependentes da identidade não corresponderem.

Verificação de identidade produz um registro delimitado do objeto. Rede e papel corretos são pré-requisitos para medições posteriores.

Um símbolo é um rótulo. Mints, contas de detentores e implementações são objetos distintos. Evidências ausentes de ligação ou afiliação permanecem visíveis.

Compare D1 com I1–I4, anotando diferenças de rede/endereço/papel. Coloque I5→I6 em um painel de lógica S0 separado; marque correspondência de build como desconhecida. Evite selos de segurança.

Correspondência ilustrativa de identidade; nenhuma corroboração do emissor.

Use SVG/HTML determinístico ou gráficos com alternativas textuais, azul-marinho escuro/preto e ciano, azul elétrico e violeta discretos. Rotule cada quantidade e incerteza. Em 390px empilhe painéis; a verificação em 768px/desktop e RTL árabe permanece trabalho futuro dos recursos visuais. Mantenha identificadores em LTR e eixos factuais/direções das arestas inalterados. Use apenas a marca oficial BlockAssay fornecida se identidade visual for adicionada. Ambos os registros são especificações, não recursos entregues.

Use RADAR para o propósito educacional delimitado da lição somente se suporte à rede, identidade exata, campos e procedência forem verificados. Nenhum endpoint de runtime ou capacidade de provedor é afirmado por este conteúdo. Use o conjunto de dados offline incorporado sem acesso pago. Dados ausentes permanecem desconhecidos; nenhuma conexão de carteira, assinatura de transação, lançamento de token ou operação ao vivo é necessária. Progresso na Academy, pagamentos e indicações nunca mudam evidências do Radar. Um Passaporte Diagnóstico preserva observações e limites, não uma previsão de preço ou certificado de segurança.

• Aba de código de contrato do Etherscan — Rótulos de correspondência exata versus semelhante de bytecode e informações separadas de compilador/construtor/auditoria. Verificada em 2026-09-30.
• Ativos Solana — Identidade de mint/conta/programa e casas decimais; distinguir campos de propriedade de contas. Verificada em 2026-09-30.
• Padrão de token ERC-20 — Interface padrão; nome, símbolo e casas decimais opcionais; não é certificação de privilégios ou identidade. Verificada em 2026-09-30.
• Slots de armazenamento de proxy ERC-1967 — Slots de implementação, beacon e administrador opcional; inspeção específica do mecanismo. Verificada em 2026-09-30.

A documentação apoia mecanismos, não valores fictícios do conjunto de dados. Todos os exemplos e registros dos exercícios são material ILLUSTRATIVE original, fixado neste arquivo. S0/S1 são rótulos de contexto sintéticos; observedAt é null porque nenhuma medição de registro ao vivo ou histórico foi coletada. Revise novamente a documentação e o comportamento realmente implantado antes de qualquer publicação ou integração.

P08-L02 após o exercício resolvido e a revisão do quiz.