Saltar al contenido
Financial Context Wiki

Contrato proxy

Un contrato proxy reenvía llamadas al código de implementación mientras conserva la dirección y el estado del proxy. Conoce su funcionamiento y los riesgos de actualización, almacenamiento y administración.

Actualizado

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

Respuesta directa

Un contrato proxy es un contrato intermediario que reenvía llamadas a otro contrato, normalmente denominado contrato de implementación o de lógica. En un diseño común de la EVM, el proxy usa delegatecall, de modo que el código de la implementación se ejecuta en el contexto del proxy, mientras el estado y los saldos permanecen en la dirección del proxy.

Esta capa de indirección permite que un sistema conserve una dirección estable de cara al usuario mientras cambia su implementación. También puede reducir el costo de despliegue cuando muchos proxies comparten código. Un proxy no es actualizable de forma automática: algunos proxies mínimos apuntan permanentemente a una implementación, mientras que los actualizables añaden una forma controlada de cambiar la implementación o el beacon.

Por ello, los usuarios deben evaluar tanto la implementación activa como la autoridad capaz de cambiarla. Verificar únicamente el bytecode del proxy no determina qué código se ejecutará mañana.

Cómo funciona

Cuando una llamada llega al proxy, su ruta de respaldo copia o reenvía los datos de la llamada a una implementación. Con delegatecall, address(this) es el proxy, las lecturas y escrituras de almacenamiento afectan al proxy y se conservan los valores originales de msg.sender y msg.value. Después, el proxy devuelve los datos de la implementación o revierte junto con ella.

Como los metadatos del proxy comparten el espacio de almacenamiento del proxy con el estado de la aplicación, las ranuras estandarizadas ayudan a evitar colisiones accidentales. ERC-1967 define ranuras para una dirección de implementación, una dirección de beacon y un administrador opcional, y recomienda emitir eventos cuando esos valores cambian. El estándar facilita la inspección de proxies, pero por sí solo no vuelve segura una actualización.

Los diseños habituales sitúan la autoridad de actualización en distintos lugares:

  • Proxy transparente: el proxy distingue las llamadas administrativas de las llamadas ordinarias de usuarios, normalmente mediante un contrato de administración separado.
  • Proxy UUPS: la lógica de actualización reside en la implementación, que debe autorizar los cambios y seguir siendo compatible con la interfaz de actualización prevista.
  • Proxy beacon: el proxy consulta su implementación a un beacon; cambiar un beacon puede afectar a todos los proxies que lo siguen.
  • Clon mínimo: muchos proxies pequeños delegan en código compartido, a menudo sin ninguna ruta de actualización.

Ejemplo

Supongamos que un proxy de bóveda conserva los saldos de usuarios y delega en la implementación A. Los usuarios depositan a través de la dirección del proxy, y el código de A actualiza los registros de saldo en el almacenamiento del proxy.

Más adelante, la gobernanza cambia la ranura de implementación ERC-1967 a la implementación B. La dirección del proxy y los saldos registrados no se mueven, pero las llamadas futuras ejecutan el código de B. Si B conserva la disposición del almacenamiento y aplica las reglas previstas, los usuarios observan un comportamiento nuevo en la misma dirección.

Si B reordena variables de almacenamiento, omite una comprobación de autorización o añade una ruta de retiro controlada por quien actualiza, la misma actualización puede corromper la contabilidad o exponer activos. Por tanto, la cuestión operativa no es solo si el contrato es un proxy, sino quién puede cambiar su ruta de ejecución, con qué demora y bajo qué verificación.

Riesgos

  • Compromiso de la clave de actualización: un administrador, una multifirma o un proceso de gobernanza puede instalar código malicioso o defectuoso.
  • Incompatibilidad de la disposición del almacenamiento: cambiar el orden, los tipos o la herencia de las variables puede hacer que el código nuevo lea mal o sobrescriba el estado existente.
  • Fallo de inicialización: los constructores no inicializan el almacenamiento del proxy; una protección ausente o reutilizable puede permitir que otra cuenta reclame funciones privilegiadas.
  • Sorpresas en el enrutamiento de llamadas: las colisiones de selectores, las rutas exclusivas del administrador o un beacon inesperado pueden hacer que la ejecución difiera de la interfaz visible.
  • Amplio alcance de una actualización compartida: una decisión sobre un beacon o una implementación puede cambiar muchas instancias de contratos a la vez.

Antes de depositar activos o conceder autorizaciones, hay que resolver en cadena la implementación o el beacon actual, identificar la autoridad de actualización y cualquier bloqueo temporal, revisar el código fuente verificado y la compatibilidad del almacenamiento, e inspeccionar los eventos recientes Upgraded, BeaconUpgraded y AdminChanged cuando corresponda. El seguimiento sigue siendo necesario tras la primera revisión porque la ruta de ejecución puede cambiar.

Errores comunes

  • «El proxy no almacena un estado relevante». Con delegatecall, el estado de la aplicación y, a menudo, los activos pertenecen al proxy aunque la lógica proceda de otra dirección.
  • «Una implementación verificada vuelve al sistema carente de confianza». Las claves de actualización, la gobernanza, los beacons, la inicialización y las implementaciones futuras siguen formando parte del modelo de confianza.
  • «Todos los proxies se pueden actualizar». Los clones y otros proxies fijos pueden delegar permanentemente; la capacidad de actualización depende del diseño concreto y del código de autorización.

Temas relacionados

Fuentes

Navegación

Buscar en la wiki...