Diseño de autoridades y actualizaciones

«Renunciado» describe incompletamente los controles si quedan administrador proxy, rol separado de emisión o autoridad de pausa. Un mapa de permisos necesita función afectada y todas las vías pertinentes.

Inventaríe capacidades: emisión, quema, pausa, lista negra o restricciones de transferencia, actualización de metadatos, cambio de comisiones y actualización de implementación. Algunas pueden no existir; su ausencia requiere pruebas de implementación, no un botón faltante. Nombre rol o autoridad que invoca cada vía, su delegación/recuperación y condiciones de cambio.

Una revocación se limita a una capacidad concreta. Eliminar propiedad del token no elimina por sí mismo administrador de actualización del proxy ni otro rol privilegiado. Las ranuras proxy normalizadas localizan ciertos campos de implementación/admin, pero diseños personalizados requieren pruebas propias. Multisig y demoras pueden cambiar condiciones de ejecución; no prueban independencia de firmantes ni eliminan todo riesgo de compromiso.

Para cada control retenido propuesto, declare consecuencia práctica y motivo. Para cada transferencia o revocación, enumere vías residuales y verificación necesaria. No convierta una declaración aparentemente irreversible en puntuación de seguridad. La lección no cambia roles ni ejecuta transacciones.

Capacidad: acción privilegiada accesible mediante una vía concreta.

Revocación de rol: eliminación de una relación de autorización.

Vía de actualización: mecanismo que puede cambiar comportamiento de implementación.

Control residual: capacidad restante tras un cambio declarado.

ILLUSTRATIVE mapa Cedar: rol de emisión M; rol de pausa P; administrador proxy U; editor de metadatos D. Un cambio propuesto revoca M pero retiene P, U, D. U se describe como 2-of-3 con demora de 24 horas; independencia de firmantes y aplicación desplegada no están probadas.

Mapa de permisos con nodos M, P, U, D antes/después de revocar M de forma propuesta. Mantenga U/P/D como vías sólidas retenidas; anote2-of-3/24h como supuestos de diseño no verificados.

Leyenda: Revocación ficticia de un rol concreto; las vías retenidas de actualización y pausa siguen visibles.

SPECIFICATION_ONLY — el visual renderizado no se ha producido ni revisado de forma independiente.

El mapa ficticio muestra que la revocación propuesta del rol de emisión deja tres capacidades declaradas. El 2-of-3 y la demora son solo afirmaciones de diseño.

No existe estado de rol desplegado, multisig verificado, revocación real, garantía permanente de oferta ni prueba de firmantes independientes. U podría cambiar comportamiento si lo permite la implementación propuesta.

Llamar a revocar M «eliminar todo control»; suponer que multisig prueba personas independientes; tratar una demora como auditoría; ignorar vías de metadatos o comisiones.

Elabore filas de capacidades antes/después y reformule «Cedar ha renunciado a todo y no puede cambiar». Indique dos comprobaciones necesarias antes de afirmar revocación real.

• Inventariar cada vía privilegiada material.
• Describir revocación específica y control residual.
• Calificar supuestos de firmantes y demora.
• Separar afirmaciones de diseño y estado desplegado.

La declaración de controles es específica de cada capacidad; retirar un rol no prueba un activo inmutable ni sin autoridad.

• Una revocación tiene un alcance.
• Vías de actualización y delegación pueden conservar control.
• Una etiqueta multisig no prueba independencia de firmantes.

P12-L04

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.

• PROXY: Ranuras de almacenamiento del proxy ERC-1967 — Ranuras normalizadas de implementación/admin; renunciar a un rol no demuestra que todas las vías de actualización estén desactivadas. 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.
• 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.

ILLUSTRATIVE — entradas sin conexión totalmente ficticias; ninguna observación actual.

null — ninguna observación real

1

null

needs_review