P13-L02 · P13 · P13-M01
Reconstruir secuencia saneada de aprobación maliciosa
Requisitos previos: P13-L01
Objetivos de aprendizaje
- Reconstruir secuencia saneada de aprobación maliciosa
- Reconstruir secuencia saneada de aprobación y gasto separando afirmaciones de autorización, movimiento y engaño.
Por qué importa
Una aprobación puede autorizar un gastador sin mover fondos. Confundir aprobación con pérdida oculta qué registro posterior establecería transferencia real.
Explicación
Separe representación al usuario, cambio de autorización, gasto intentado y movimiento observado. La asignación ERC-20 es permiso técnico; un evento de aprobación solo no muestra transferencia completada. Movimiento exitoso tipo transferFrom requiere ejecución/recibo pertinente y conciliación de estado. Autorización por firma tiene esquema y alcance propios; no generalice approve ordinario a todo mensaje firmado.
Conserve activo, propietario, gastador, importe, red y base temporal exactos en casos reales. Aquí solo etiquetas en papel no ejecutables. Si página promete acción y autorización estipulada concede otra, informe incoherencia. Engaño o coacción requieren pruebas admisibles de representación y contexto; asignación amplia expone control sin probar automáticamente intención criminal.
Nunca pida conectar cartera, firmar, aprobar, enviar fondos ni frase semilla/clave privada para demostrar mecanismo. Use registros saneados. Responder a incidente real puede requerir experiencia contextual; esta lección es lectura de pruebas, no procedimiento de transacción.
Terminología
Asignación: autorización técnica de gasto para un gastador.
Aprobación: actualización de permiso, distinta de movimiento real.
Evento de gasto: prueba de ejecución de movimiento de activos bajo una capacidad.
Conflicto de representación: acción prometida distinta de control concedido.
Ejemplo histórico
ILLUSTRATIVE: página en papel P promete « reclamar 10 unidades ». R1 estipula que propietario W concede a S asignación 1000 para T. R2 estipula que S mueve exitosamente 400 T de W a D; recibo R2 solo existe como fila inventada. Captura no identifica operador humano.
Especificaciones visuales
Cronología de permisos P→R1 autorización→R2 movimiento con importes separados 10/1000/400 y canal de identidad desconocida. Sin URLs activas ni instrucciones ejecutables de aprobación.
Caption: Secuencia ficticia saneada; autorización y movimiento completado son registros distintos.
SPECIFICATION_ONLY — el visual renderizado no se ha producido ni revisado de forma independiente.
Lo que demuestra la evidencia
En el ejemplo, R1 cambia permiso y R2 registra movimiento de 400 unidades. Texto de reclamación de 10 unidades contradice alcance de permiso de 1000 unidades.
Lo que no demuestra la evidencia
No prueba sitio real de phishing, firma real, pérdida real, identidad de operador ni intención criminal. R1 solo no establece movimiento; revocación posterior no desharía R2.
Errores comunes
Llamar transferencia a aprobación; usar permiso ilimitado como prueba de fraude; inventar recibo ausente; pedir firma para probar.
Ejercicio práctico
Construya cuatro columnas para P,R1,R2 e identidad. Calcule asignación restante según reducción simple estipulada e indique cambio de conclusión sin R2.
Mostrar corrección detallada
P: representación ficticia atribuida de reclamación de 10 unidades. R1: permiso ficticio 1000 T a S. R2: movimiento ficticio exitoso de 400 T a D. Identidad: desconocida. Según reducción ordinaria estipulada, restante=1000−400=600; implementaciones reales pueden diferir y requieren inspección. Sin R2, solo exposición de autorización y discrepancia de representación, no pérdida completada. Aun con R2, movimiento técnico no identifica operador ni establece intención independientemente. Sin interacción de cartera.
Lista de verificación
- Separar representación, aprobación y movimiento.
- Vincular cada fila a activo/propietario/gastador/red.
- No inventar ejecuciones ausentes.
- Usar datos saneados sin conexión sin firmas ni fondos.
Resumen
Análisis de abuso de aprobación exige permiso y pruebas de movimiento; representación e identidad se evalúan separadamente.
Resumen
- Aprobación no es transferencia.
- Gasto posterior puede establecer movimiento dentro de su alcance.
- Autorización técnica no identifica persona ni prueba intención.
Lección siguiente
P13-L03
Herramientas
Utilice la herramienta BlockAssay indicada solo como contexto de lectura de evidencia. Esta lección no crea ninguna salida de herramienta, sesión de cuenta ni derecho de acceso. Ejercicio sin conexión; no firme, despliegue, apruebe ni financie nada.
Fuentes y límites de las afirmaciones
- ERC20: Estándar ERC-20 — Interfaz del token y semántica de autorizaciones; el estándar no establece identidad del emisor ni permisos seguros. Límite: Solo documentación del mecanismo; los valores ilustrativos originales están estipulados, no son observaciones. Los registros históricos tienen procedencia congelada por separado y lagunas de recopilación explícitas.
Clasificaciones de evidencia
ILLUSTRATIVE — entradas sin conexión totalmente ficticias; ninguna observación actual.
Fecha de observación
null — ninguna observación real
Versión del contenido
1
Fecha de revisión
null
Estado de revisión
needs_review
Especificaciones visuales
P13-L02-V01
Reconstruir secuencia saneada de aprobación maliciosa
Secuencia ficticia saneada; autorización y movimiento completado son registros distintos.
Cronología de permisos P→R1 autorización→R2 movimiento con importes separados 10/1000/400 y canal de identidad desconocida. Sin URLs activas ni instrucciones ejecutables de aprobación.
Cronología de permisos P→R1 autorización→R2 movimiento con importes separados 10/1000/400 y canal de identidad desconocida. Sin URLs activas ni instrucciones ejecutables de aprobación.
A 390 px, apile observaciones, supuestos, lagunas y conclusión; conserve los IDs completos y un equivalente textual completo. Las tablas anchas se desplazan localmente.
La prosa puede seguir RTL; los IDs, cantidades y ejes temporales permanecen LTR. Preserve la dirección de las dependencias.
P13-L02-ILLUSTRATIVE-v1
Fuentes y límites de las afirmaciones
ERC20 · PRIMARY_DOCUMENTATION
Estándar ERC-20
- Afirmación respaldada
- Interfaz del token y semántica de autorizaciones; el estándar no establece identidad del emisor ni permisos seguros.
- Límite de verificación
- Solo documentación del mecanismo; los valores ilustrativos originales están estipulados, no son observaciones. Los registros históricos tienen procedencia congelada por separado y lagunas de recopilación explícitas.
- Fecha de verificación
- 2026-10-02
https://eips.ethereum.org/EIPS/eip-20
Procedencia de datos
id: P13-L02-ILLUSTRATIVE-v1
dataStatus: ILLUSTRATIVE
observedAt: null
source: Original offline scenario in realOrHistoricalExample
scope: Fictional stipulated labels and values. No wallet, deployment, transaction, token launch or production observation.