Verificación exacta de contratos y mints

Máster de origen EN · P08-L01 · 45 minutos estimados · needs_review

Todos los cálculos posteriores dependen de analizar el activo previsto. Una auditoría correcta de permisos del contrato equivocado sigue siendo una investigación fallida. Los nombres, símbolos e iconos ayudan a navegar, pero no pueden servir como claves primarias. Esta lección amplía el reconocimiento del mint exacto a un registro de identidad reproducible que distingue el rol de la cuenta y la lógica que la gobierna.

Concordará un objetivo declarado con registros suministrados, identificará la evidencia de implementación ausente y escribirá un resultado que otro analista pueda repetir. No firmará, aprobará ni comprará nada.

Construya la tupla de identidad

Empiece por la red, la dirección exacta y el tipo de objeto. Distinga la red principal de los entornos de prueba y las diferentes cadenas EVM. Una cadena de texto con forma de dirección por sí sola está incompleta. Una URL de explorador puede seleccionar una red diferente aunque la dirección mostrada parezca familiar. Conserve la red solicitada cuando una búsqueda devuelva un parecido más popular.

Escriba el identificador completo en lugar de un prefijo abreviado. En una inspección real valide la codificación y compare los bytes de dirección decodificados con una herramienta fiable. El uso de mayúsculas y minúsculas de la suma de comprobación EVM y las convenciones base58 de Solana requieren tratamientos diferentes. El conjunto de datos usa etiquetas inválidas para que ningún alumno pueda operar accidentalmente con ellas; sus comparaciones son comparaciones educativas de cadenas de texto.

Pregunte qué objeto nombra el identificador. Un mint de Solana es distinto de una cuenta de tokens que contiene unidades y del Token Program que contiene la lógica de instrucciones [S08-TOKENS]. Una implementación EVM detrás de un proxy no es automáticamente la dirección de saldos orientada al usuario. Describa el rol antes de usar valores.

Separe existencia, lógica y afiliación

Una fuente que devuelve una cuenta es evidencia de un objeto en un contexto, no de que una marca lo respalde. La verificación de código fuente de un explorador se refiere a la correspondencia entre código fuente y código desplegado; no certifica la afiliación oficial ni la integridad de una auditoría. Estas preguntas requieren registros separados [S08-CODE]. Etherscan distingue coincidencias exactas de similares; una coincidencia similar puede dejar diferencias de constructor o inicialización. Inspeccione el tipo de coincidencia declarado en lugar de tratar todas las insignias como el mismo hallazgo.

Use resultados distintos: objeto exacto concordado, implementación sin resolver y afiliación sin corroborar. Una concordancia positiva de identidad no resuelve los otros dos. Si se suministra correspondencia de código, conserve el compilador, la configuración y el alcance del despliegue en lugar de parafrasearlo como «seguro».

ERC-20 describe una interfaz; name y symbol son metadatos opcionales, y la compatibilidad no certifica un proyecto [S08-ERC20]. Por tanto, recibir el símbolo esperado no puede resolver la afiliación. Una implementación puede exponer métodos familiares e incluir controles adicionales no descritos por la interfaz básica.

Trace el límite de la lógica

Para un mint de Solana registre el Token Program propietario de su cuenta de datos. No confunda el campo de propietario del programa base con el campo de propietario de cuenta de tokens usado para las tenencias. Un mint con extensiones necesita una decodificación que las tenga en cuenta. Un analizador básico que ignore estado adicional no puede establecer que no existe comportamiento adicional.

Para un proxy, la dirección solicitada del token puede permanecer estable mientras cambia la lógica delegada. ERC-1967 describe enlaces a implementación o beacon y un slot opcional de administrador [S08-PROXY]. El despliegue real determina su aplicabilidad; los slots estándar vacíos no establecen que esté ausente todo mecanismo posible de actualización.

Mantenga juntos la dirección del proxy, la implementación y el contexto. Código en un contexto y estado en otro crean un registro mixto. Si no está disponible el enlace, identifique el objeto orientado al usuario y marque la resolución de lógica como incompleta. Nunca llene esa laguna con cualquier contrato que una interfaz etiquete como «implementación».

Conserve la procedencia de recuperación

Registre fuente, hora de recuperación, contexto de bloque o slot cuando se devuelva, compromiso/finalidad y supuestos del decodificador. Un tiempo de espera agotado significa datos no disponibles. Una respuesta de la red equivocada es una discordancia, no ausencia en la red prevista. No reintente silenciosamente en otra cadena ni combine esos valores.

Dos interfaces pueden compartir un indexador. La concordancia es útil, pero no constituye automáticamente dos observaciones independientes. Registre la fuente subyacente si es visible; de lo contrario, indique que se desconoce la independencia. Un registro bruto y su decodificación son más reproducibles que una imagen recortada sin el identificador exacto.

Separe objetivos declarados y corroborados. Una captura que afirma una dirección oficial es una declaración. Concordarla solo prueba que inspeccionó el objeto que nombra. La afiliación requiere fuentes del emisor debidamente autenticadas con contexto de captura, e incluso una afiliación corroborada no prueba seguridad.

Use una regla de detención

Detenga las conclusiones dependientes de identidad cuando la tupla no concuerde o el rol del objeto no esté resuelto. Aún puede documentar la laguna; no puede atribuir el suministro o los permisos de otro activo al objetivo. Una coincidencia genérica de resultados de búsqueda no es un sustituto.

Un hallazgo conciso podría decir: «La red/dirección solicitada se resuelve como un mint en el S0 suministrado. No se suministran su inventario de extensiones ni afiliación al emisor». Esto conserva un hallazgo positivo y sus límites. Un registro completo también debe indicar qué evidencia adicional permitiría el siguiente paso.

Un revisor independiente debería poder partir de su tupla sin adivinar qué pestaña de red o dirección truncada seleccionó. La verificación de solo lectura protege este flujo: no se necesita aprobación de cartera para establecer la identidad de un objeto, y ningún ejercicio requiere credenciales.

• Tupla de identidad: red, dirección completa y rol del objeto.
• Mint: cuenta de Solana que representa un token.
• Cuenta de tokens: cuenta separada que contiene unidades de un mint.
• Implementación: lógica usada por un contrato delegado.
• Procedencia: fuente y contexto que respaldan un registro.
• Afiliación: relación declarada con un emisor o marca.

ILLUSTRATIVE — FIX-P08-01. S0 es ficticio, no un bloque real. La declaración D1 solicita SIM-SOL-A / MINT-ALPHA como mint; la atribución al emisor no está autenticada.

I1 contiene campos básicos, pero ningún inventario de extensiones. I5 tiene enlace, pero no correspondencia de fuente/compilación.

OBSERVED en el conjunto de datos: I1 concuerda con la tupla de D1; I3 hace referencia a su mint, pero tiene un rol diferente.

INFERRED: I1 es el registro inicial correcto para una inspección básica. I5/I6 describen un enlace separado de proxy suministrado.

UNKNOWN: Afiliación, estado de extensiones omitido y correspondencia de código/compilación de I5.

INSUFFICIENT EVIDENCE: Símbolos iguales no pueden convertir I2/I4 en el objetivo. I6, que contiene lógica, no puede sustituir a I5, orientado al usuario.

Concordar solo símbolos, olvidar la red, sustituir un mint por una cuenta de tenencias, analizar saldos de implementación y llamar certificado de seguridad a la visibilidad del código fuente.

Elija la concordancia con D1; rechace I2–I4 con razones individuales. Escriba una nota de identidad separada para I5. Enumere tres lagunas de evidencia antes de una revisión completa del comportamiento de I1.

• Conserve red e identificador completo.
• Verifique el rol y el enlace de programa/lógica.
• Concorde contextos antes de combinar evidencia.
• Separe afiliación de revisión de código.
• Deténgase cuando los datos dependientes de identidad no concuerden.

La verificación de identidad produce un registro acotado del objeto. La red y el rol correctos son requisitos previos para mediciones posteriores.

Un símbolo es una etiqueta. Mints, cuentas de tenencias e implementaciones son objetos diferentes. La evidencia ausente de enlace o afiliación sigue siendo visible.

Compare D1 con I1–I4, anotando diferencias de red/dirección/rol. Sitúe I5→I6 en un panel de lógica S0 separado; marque la correspondencia de compilación como desconocida. Evite insignias de seguridad.

Concordancia de identidad ilustrativa; sin corroboración del emisor.

Use SVG/HTML deterministas o gráficos con alternativas textuales, azul marino oscuro/negro y cian, azul eléctrico y violeta moderados. Etiquete cada cantidad e incertidumbre. A 390px apile los paneles; la verificación a 768px/escritorio y RTL en árabe sigue siendo trabajo futuro de los recursos. Mantenga los identificadores LTR y los ejes/direcciones de aristas factuales sin cambios. Use solo la marca oficial BlockAssay proporcionada si se añade identidad de marca. Ambos registros son especificaciones, no recursos entregados.

Use RADAR para el propósito educativo acotado de la lección solo si se verifican la compatibilidad de la red, la identidad exacta, los campos y la procedencia. Este contenido no afirma ningún endpoint de runtime ni capacidad de proveedor. Use el conjunto de datos sin conexión incorporado sin acceso de pago. Los datos ausentes siguen siendo desconocidos; no se requiere conexión de cartera, firma de transacción, lanzamiento de tokens ni operación en vivo. El progreso, los pagos y las referencias de Academy nunca cambian la evidencia de Radar. Un Pasaporte de Diagnóstico conserva observaciones y límites, no una predicción de precios ni un certificado de seguridad.

• Pestaña de código de contratos de Etherscan — Etiquetas de coincidencia exacta frente a similar de bytecode e información separada de compilador/constructor/auditoría. Revisado 2026-09-30.
• Activos de Solana — Identidad de mint/cuenta/programa y decimales; distinguir los campos de propiedad de cuentas. Revisado 2026-09-30.
• Estándar de tokens ERC-20 — Interfaz estándar; name, symbol y decimals opcionales; no certificación de privilegios ni identidad. Revisado 2026-09-30.
• Slots de almacenamiento de proxies ERC-1967 — Slots de implementación, beacon y administrador opcional; inspección específica del mecanismo. Revisado 2026-09-30.

La documentación respalda mecanismos, no valores de conjuntos ficticios. Todos los ejemplos y registros de ejercicios son material original ILLUSTRATIVE, congelado en este archivo. S0/S1 son etiquetas de contexto sintéticas; observedAt es null porque no se recopiló ninguna medición de un registro de cadena en vivo ni histórico. Vuelva a revisar la documentación y el comportamiento efectivamente desplegado antes de cualquier publicación o integración.

P08-L02 después de revisar el ejercicio resuelto y el cuestionario.