Congelación, propiedad y autoridad

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

Una insignia de «propiedad renunciada» puede coexistir con un rol activo de pausa o un controlador de actualización. Una autoridad de emisión eliminada puede coexistir con autoridad de congelación. Cada declaración puede ser verdadera mientras la conclusión amplia «nadie tiene control» es falsa.

Esta lección enseña un mapa de control por capas. Conectará cada privilegio con su objeto, titular actual, condición y posible vía de administración. El resultado es un registro de evidencia, no una puntuación de seguridad ni una acusación.

Defina el objeto controlado

No use propietario sin un sustantivo. El propietario de programa de una cuenta de datos Solana, una autoridad de cuenta de tokens, un propietario Ownable EVM y un propietario de posición NFT son campos distintos. Sus nombres se parecen, pero gobiernan mecanismos diferentes. Escriba campo y objeto junto al valor.

Separe control del saldo de tokens, restricciones a nivel de mint, roles de aplicación y autoridad que cambia código. Un hallazgo sobre una capa no puede borrar un permiso en otra. Por ejemplo, un mint puede carecer de autoridad de emisión mientras una aplicación que interactúa con el token sigue siendo actualizable. Revise por separado el rol de la aplicación en lugar de asumir que gobierna el propio Token Program estándar.

Un mapa de control es un grafo de capacidades, no de identidades humanas. Una autoridad listada puede ser una cuenta de usuario o una dirección mediada por programa. Las etiquetas públicas de cuentas no establecen quién tiene las claves ni si varias cuentas comparten controlador.

Entienda la congelación como restricción de estado

El mecanismo de congelación de Solana conserva propietario de cuenta de tokens, mint y saldo mientras impide las operaciones documentadas de recepción, transferencia y quema hasta descongelar [S08-FREEZE]. No es una eliminación de saldo ni transferencia a la autoridad de congelación.

Estado y autoridad deben registrarse por separado. Una autoridad de congelación puede existir mientras una cuenta está actualmente sin congelar. A la inversa, una observación de estado congelado no dice que un humano concreto lo causó. Solicite la operación exitosa y su autorización si la atribución importa.

La revocación elimina un rol seleccionado de autoridad, no una colección universal de poderes [S08-SET]. No asuma que revocar el rol de emisión cambió el estado de congelación. Las cuentas ya congeladas y posibles vías de recuperación/descongelación necesitan examen propio; evite describir una revocación acotada como prueba de que todas las cuentas son transferibles.

Inspeccione roles de aplicación más allá de Ownable

La renuncia de OpenZeppelin Ownable deshabilita funciones protegidas por su comprobación de propietario, mientras los permisos basados en roles son un patrón separado [S08-ACCESS]. Si un token desplegado combina estos patrones es una pregunta de código y estado. Si permanece un rol de pausa, la renuncia del propietario por sí sola no puede eliminarlo.

Construya una tabla de propiedad, pausa, otorgamiento/revocación de roles y actualizaciones. Para cada fila registre comprobación real, autoridad presente, vía de administración e incertidumbre. Un nombre de rol es solo descriptivo hasta vincularlo con una operación alcanzable. «PAUSER» en metadatos no prueba una función de pausa.

Un control puede depender de demora temporal o multifirma. Verifique contrato relevante, umbral, demora y condiciones de elusión en lugar de aceptar una insignia. Una demora es una condición temporal, no desaparición de control. Un umbral multifirma describe firmas, no necesariamente humanos independientes.

Trace control de proxy e implementación

Para proxies de estilo ERC-1967 distinga el enlace de implementación o beacon del slot opcional de administrador. Un beacon resuelve lógica para proxies asociados; la autorización de estilo UUPS puede residir en la lógica de implementación, así que un slot de administrador vacío por sí solo no es una conclusión completa [S08-PROXY; S08-UUPS].

La dirección de un proxy orientada al usuario puede mantenerse cuando cambian sus reglas. Fije la implementación al contexto revisado y luego inspeccione la vía que puede cambiarla. No audite una página de implementación verificada dejando sin comprobar el enlace del proxy. Una implementación posterior puede invalidar supuestos previos de comportamiento.

Esta lección no enseña ejecución de actualizaciones. Enseña a describir de solo lectura la vía de autorización suministrada. Si no están disponibles las reglas internas del controlador, márquelas desconocidas aunque se conozca la dirección de autoridad externa.

Distinga actualizaciones de programas Solana de roles de mint

Bajo loader-v3 de Solana, las actualizaciones de programas dependen de la autoridad de actualización del programa; eliminar esa autoridad hace inmutable ese programa [S08-DEPLOY]. No es el campo de autoridad de emisión del mint. Se aplica al programa y mecanismo de loader revisados, no a todo contrato conectado ni servicio fuera de cadena.

Un mint gobernado por un Token Program estándar no debe describirse despreocupadamente como actualizable de forma independiente solo porque lo usa una aplicación personalizada. Nombre el programa personalizado y explique su relevancia. En el conjunto de datos PROGRAM-X es una aplicación auxiliar, no el Token Program propietario de MINT-F.

La inmutabilidad está acotada al objeto de código. No prueba usuarios honestos, metadatos inmutables, liquidez suficiente ni sistemas circundantes seguros. Asimismo, una autoridad activa de actualización prueba una capacidad bajo condiciones, no que el código vaya a cambiar maliciosamente.

Informe de un resultado por capas

Una frase defendible nombra contexto y límites: «En S0 se ha renunciado al campo de propietario, mientras PAUSER permanece asignado y se suministra el controlador de actualización del proxy, pero su umbral interno es desconocido». Es más informativa que una etiqueta categórica de «descentralizado».

Pregunte si una afirmación puede refutarse con una fila restante. «Sin controles privilegiados» queda contradicho por una capacidad activa probada. Una afirmación acotada como «el rol de propietario Ownable está ausente» puede seguir respaldada aunque falle la declaración amplia. Conserve ambas.

• Estado de congelación: restricción de operaciones de una cuenta de tokens.
• Propietario Ownable: autoridad bajo un patrón concreto de comprobación de propietario.
• Titular de rol: cuenta que satisface una comprobación específica de pertenencia.
• Controlador de actualización: autoridad que gobierna una vía de cambio de código.
• Beacon: mecanismo de enlace de lógica de proxy.
• Demora temporal: condición que impone retraso a operaciones especificadas.

ILLUSTRATIVE — FIX-P08-04. Objetos ficticios separados en S0.

PROGRAM-X no es el Token Program que gobierna MINT-F. El conjunto de datos no suministra los efectos de código que conectan esta aplicación auxiliar al mint.

OBSERVED en el conjunto de datos: F permanece, V está congelada, P/G permanecen y C/U son autoridades de actualización suministradas.

INFERRED: «Todos los controles eliminados» queda contradicho por estas capacidades separadas. Propietario renunciado es una declaración respaldada más acotada sobre P2.

UNKNOWN: Reglas internas de C, controladores humanos, quién congeló V y efectos exactos de aplicación de PROGRAM-X.

INSUFFICIENT EVIDENCE: Congelación no significa que se destruyó el saldo de V. Un propietario ausente no prueba ausencia de roles o actualizaciones. U no prueba que el Token Program estándar esté controlado por U.

Usar propietario sin su objeto; confundir saldo congelado con cero; asumir que un slot vacío de administrador de proxy excluye todas las actualizaciones; interpretar una etiqueta multifirma como control independiente verificado; y fusionar autoridad de programa auxiliar con autoridad de mint.

Produzca cuatro capas de control: estado de cuenta, roles de mint, roles de aplicación EVM y vías de cambio de implementación. Reescriba «se ha renunciado a toda propiedad, así que todo es inmutable». Enumere la siguiente evidencia necesaria para C y V.

• Nombre el objeto de cada campo de propietario.
• Separe autoridad de estado actual.
• Inspeccione roles tras renuncia de propiedad.
• Resuelva lógica y vías de actualización en el mismo contexto.
• Verifique umbrales/demoras en lugar de etiquetas.
• Acote inmutabilidad al objeto revisado.

El control tiene capas. Un rol eliminado establece un hecho acotado; roles activos y vías de cambio de código necesitan revisión separada.

Congelación es restricción, no eliminación. Renuncia del propietario no es renuncia a todo control. Autoridades de proxy, programa y mint son distintas.

Mapa de permisos de cuatro carriles con referencias F1–F3,P1–P3,X1; muestre el saldo congelado 50 sin cambios. Dibuje PROXY-Q→LOGIC-Q y el controlador C separado; PROGRAM-X/U aislado de MINT-F. Marque la configuración de C como desconocida.

Controles por capas ilustrativos; ausencia de propietario es una afirmación acotada.

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.

• OpenZeppelin 5.x Proxy — Mecanismos de actualización transparentes, beacon y UUPS basados en implementación; la autorización real necesita inspección. Revisado 2026-09-30.
• Solana: congelar cuenta — Restricciones del estado de cuenta distintas de la cantidad o propiedad. Revisado 2026-09-30.
• Solana: establecer autoridad — Cambios y revocación específicos de roles; no un veredicto global de seguridad. Revisado 2026-09-30.
• OpenZeppelin 5.x: control de acceso — Patrones de privilegios Ownable y basados en roles; inspeccionar la autorización efectivamente desplegada. 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.
• Solana: despliegue de programas — Autoridad de actualización de programas loader-v3; no un rol de mint de tokens. 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-L05 después de revisar el ejercicio resuelto y el cuestionario.