Saltar al contenido
Financial Context Wiki

Cómo monitorear las actualizaciones de contratos proxy

Monitorea cambios de implementación, beacon y control en proxies actualizables, y verifica después el código, la compatibilidad del almacenamiento, la inicialización, los permisos y el comportamiento crítico.

Actualizado

Solo con fines educativos; no constituye asesoramiento de inversión. Invertir puede ocasionar pérdidas.

Respuesta directa

Monitorea la ruta de control de un sistema actualizable además de su dirección proxy. Una alerta debe identificar quién puede autorizar y ejecutar una actualización, cualquier demora obligatoria, las implementaciones anterior y nueva, y los calldata de inicialización. Tras la ejecución, lee de forma independiente la configuración en cadena y prueba el comportamiento crítico.

La dirección proxy y sus saldos pueden permanecer iguales mientras el código delegado cambia permisos, comisiones, contabilidad, pausas o lógica de retiro. Una auditoría anterior no cubre automáticamente una implementación nueva ni su inicialización.

Cómo funciona

Primero identifica el patrón de proxy. ERC-1967 define ranuras de almacenamiento distintas para eip1967.proxy.implementation, eip1967.proxy.beacon y la ranura opcional eip1967.proxy.admin. Los cambios directos de implementación deberían emitir Upgraded; los cambios de dirección del beacon, BeaconUpgraded; y los cambios de la ranura de administrador, AdminChanged. En un proxy beacon también hay que llamar a implementation() del beacon, porque este puede cambiar su implementación sin alterar la ranura beacon del proxy.

No deduzcas el modelo de autoridad completo a partir de la ranura de administrador. Un proxy Transparent puede estar controlado mediante un ProxyAdmin, mientras que la autorización de actualización UUPS se implementa en el contrato lógico actual mediante _authorizeUpgrade. Rastrea propietarios, roles, umbrales multifirma, timelocks, gobernadores, rutas de emergencia y la capacidad de cambiar esos controles.

Combina suscripciones a eventos con lecturas periódicas del estado. ERC-1967 recomienda los eventos, pero no obliga a todas las implementaciones a emitirlos. Registra la cadena, el bloque, la transacción, el proxy, la implementación o el beacon, el hash del código en ejecución, el ejecutor y el estado de control pertinente desde endpoints RPC independientes. Alerta sobre operaciones programadas, canceladas y ejecutadas, y espera la política de confirmación o finalidad elegida para la cadena antes de considerar definitivo el estado.

Ejemplo

Un proxy de préstamos está controlado por una multifirma 3 de 5 mediante un timelock de 24 horas. Al programarse una actualización, el monitor registra el identificador de la propuesta, el destino, los calldata, la hora mínima de ejecución, la implementación actual, la propuesta y el estado de verificación del código fuente. Los revisores comparan el código y los diseños de almacenamiento, inspeccionan la llamada de inicialización y revisan cambios en roles, llamadas externas, comisiones, reglas de pausa y rutas de retiro.

Tras la ejecución, el monitor vuelve a leer la ranura ERC-1967 pertinente, verifica el código desplegado en ejecución y comprueba condiciones posteriores como la versión de implementación, los administradores o titulares de roles, el estado de pausa, la contabilidad de activos y una vista previa de retiro de solo lectura. Se dispara otra alerta si la dirección o el hash observados difieren de la propuesta revisada, o si el sondeo periódico descubre un cambio que ningún evento comunicó.

Riesgos

  • Riesgo de control: Una multifirma nominal puede ser eludida por otro propietario, rol, módulo, gobernador, clave de emergencia o timelock modificable. Sigue cada ruta hasta sus firmantes finales y su demora.
  • Riesgo de código y almacenamiento: El código sin verificar, los diseños de almacenamiento incompatibles, una inicialización insegura o una dependencia modificada pueden corromper el estado u otorgar autoridad no prevista. Valida el artefacto desplegado exacto, no solo una rama del repositorio o el nombre de una auditoría.
  • Riesgo de monitoreo: Un único RPC, un indexador que solo mira eventos, una interfaz o un explorador de bloques pueden retrasarse o equivocarse. Concilia eventos con almacenamiento, bytecode, recibos de transacción y estado del protocolo en fuentes independientes.
  • Riesgo de respuesta: Una alerta sin responsable ni procedimiento probado puede llegar demasiado tarde. Define quién revisa, pausa integraciones, comunica o sale durante la demora, y reconoce que las aprobaciones apresuradas y los enlaces de recuperación no oficiales añaden riesgo.

Procedimiento mínimo:

  1. Inventaría cada proxy, beacon, implementación, administrador, rol y punto de entrada de actualización en cada cadena.
  2. Guarda una referencia válida de ranuras, hashes de código, estado de control y resultados críticos de solo lectura.
  3. Alerta antes de la ejecución cuando la programación de gobernanza o timelock lo permita, y de nuevo al ejecutar o cancelar.
  4. Compara el destino, los calldata, la implementación, el bytecode, el diseño de almacenamiento y el estado posterior ejecutados con la propuesta revisada.
  5. Escala los cambios inesperados, las condiciones posteriores fallidas, la falta de verificación del código o una demora acortada o eludida; no uses la dirección proxy sin cambios como prueba de seguridad.

Errores comunes

  • Mito 1: “Basta con vigilar Upgraded”. Los cambios de implementación del beacon y los proxies no estándar pueden exigir monitorear otro contrato o sondear el estado; los eventos deben conciliarse con lecturas directas.
  • Mito 2: “La ranura de administrador revela quién controla cada actualización”. La ranura es opcional, y los diseños Transparent, UUPS, beacon, de gobernanza y personalizados ubican la autoridad en contratos y funciones distintos.
  • Mito 3: “El código verificado o una auditoría anterior prueban que la actualización es segura”. Verifica el bytecode desplegado, los supuestos del compilador y constructor, la compatibilidad del almacenamiento, la inicialización, la configuración y el comportamiento de la versión exacta.

Temas relacionados

Fuentes

Navegación

Buscar en la wiki...