Contratos verificados, proxies y la clave de actualización que nadie menciona

En el explorador de bloques hay una marca de verificación verde que dice Código fuente del contrato verificado, y una cantidad enorme de gente la lee como «este contrato es seguro».

No significa eso. Significa algo mucho más estrecho y mucho más útil, y confundir ambas cosas es el modo en que personas cuidadosas acaban aprobando cosas que jamás habrían aceptado.

Qué certifica realmente «verificado»

Los contratos se despliegan como bytecode: instrucciones de máquina, en la práctica ilegibles. La verificación es el acto de subir el código fuente original y hacer que el explorador confirme que al compilarlo, con la versión y los ajustes del compilador declarados, se obtiene exactamente el bytecode que ya vive en esa dirección.

Esa es toda la afirmación: el código fuente que estás leyendo es genuinamente el que se ejecuta.

Es una garantía real y valiosa. Sin ella no tendrías forma de saber si el código de aspecto pulcro en el GitHub de un proyecto guarda alguna relación con aquello que tu transacción está a punto de tocar.

Pero fíjate en todo lo que no dice. La verificación no es una auditoría. Nadie ha evaluado si el código es correcto, si tiene fallos o si hace algo parecido a lo que sugieren los nombres de sus funciones. Un contrato con una función llamada claimRewards que transfiere todo tu saldo al desplegador puede estar verificado, y la verificación sería del todo honesta: certificaría con exactitud que el robo es precisamente lo que el código dice que hace.

Verificado significa legible, no digno de confianza. Desplaza la pregunta de «¿qué es esto?» a «¿entiendo lo que acabo de leer?», lo cual es un avance, pero no responde por ti a la segunda.

Lo inverso también importa. Un contrato sin verificar no es prueba de maldad: muchos despliegues legítimos nunca llegan a verificarse. Pero sí significa que nadie —ni ninguna herramienta que uses, ni ningún investigador que pudiera haberte advertido— puede leer aquello con lo que estás a punto de interactuar. Es razonable ser cauto ante eso.

Y entonces los proxies lo empeoran

Aquí se mueve el suelo, y es la parte que casi nunca se menciona.

La mayoría de los contratos no triviales con los que interactuarás no son contratos únicos. Son proxies. El proxy es la dirección que ves, y contiene todos los datos: saldos, permisos, estado. Pero casi no contiene lógica. En su lugar reenvía cada llamada a un contrato de implementación separado, y simplemente ejecuta lo que ese contrato diga.

La razón es la actualizabilidad. Los contratos inmutables no se pueden parchear, así que un fallo es permanente y una función que falta lo es para siempre. Apuntar un proxy a una nueva implementación permite a un equipo corregir errores y publicar mejoras sin pedir a cada usuario que migre. Dado cuánto valor se ha perdido por fallos irreparables, es una decisión de ingeniería defendible.

Tiene una consecuencia fácil de pasar por alto. Cuando buscas un proxy en un explorador y lo ves verificado, has verificado la lógica de reenvío, no el comportamiento. El código que de verdad decide qué le ocurre a tu dinero vive en la dirección de implementación, que el explorador puede mostrarte de forma destacada o no, y que puede reemplazarse.

Así que la pregunta real nunca fue «¿está verificado este contrato?». Es:

¿Quién puede cambiar el comportamiento de este contrato, y con qué rapidez?

La clave de administración es el verdadero modelo de seguridad

Todo contrato actualizable tiene a alguien que puede ejecutar la actualización. Esa autoridad es el modelo de seguridad, por bueno que sea el código actual.

El abanico va de alarmante a razonable:

Una única cuenta de propiedad externa. Una sola clave privada, en la máquina de alguien, puede cambiar la lógica del contrato que guarda tus fondos. Si le hacen phishing, se la roban o coaccionan a su dueño, el contrato se convierte en lo que el atacante quiera. Este arreglo es más común de lo que debería.

Un multifirma. Varios firmantes deben estar de acuerdo. Bastante mejor —elimina el punto único de fallo—, aunque conviene saber cuántos firmantes son y si son personas genuinamente independientes o cuatro portátiles del mismo equipo.

Un multifirma tras un bloqueo temporal. La actualización se anuncia en la cadena y solo puede ejecutarse tras un retardo fijo, a menudo de 24 a 72 horas. Este es el importante, porque cambia tu posición por completo: recibes aviso previo del cambio y una ventana para retirar antes de que surta efecto. Un bloqueo temporal no impide una actualización maliciosa. Hace que puedas sobrevivirla.

Ninguna vía de actualización. El contrato es inmutable. Máxima previsibilidad, ningún recurso si aparece un fallo. Es una elección legítima, tomada normalmente por protocolos suficientemente curtidos como para apostar por ella.

Ninguna de estas es automáticamente la correcta. Pero la diferencia entre «una clave» y «multifirma más dos días de retardo» es la diferencia entre confiar en que nadie se equivoque y tener tiempo de reaccionar cuando ocurra.

Por qué esto muerde justo en las aprobaciones

Esta es la parte que conecta con algo que de hecho haces con regularidad.

Cuando concedes una aprobación de tokens, estás autorizando a una dirección a mover tus tokens. No a un trozo de código: a una dirección. La aprobación queda guardada en el contrato del token y persiste indefinidamente.

Si esa dirección es un proxy actualizable, entonces la lógica facultada para mover tus tokens puede ser reemplazada después de que la aprobaras, sin que intervengas y sin ninguna firma nueva por tu parte. Auditaste una cosa y sigues expuesto a otra distinta.

Por eso el consejo habitual de revocar las aprobaciones que ya no usas pesa más de lo que parece a primera vista. No va solo de que un contrato resulte tener un fallo. Va de que un permiso ilimitado a un contrato actualizable es un permiso concedido a quien controle la clave de actualización, durante todo el tiempo que lo dejes abierto.

Es también el límite más nítido de la simulación de transacciones. Simular antes de firmar te dice qué hace una transacción contra el estado actual y la implementación actual. Es genuinamente útil y no puede decirte qué permitirá esa misma aprobación el mes que viene.

Qué te muestra SSP y dónde se detiene

Cuando SSP Key presenta una aprobación, decodifica los datos de la llamada en lugar de mostrarte hexadecimal en bruto. Reconoce los selectores ERC-20 estándar —approve, transfer, transferFrom, increaseAllowance, setApprovalForAll— y los expresa en lenguaje llano, señalando además los permisos ilimitados, definidos en el código como cualquier importe igual o superior a 2^255.

El decodificador es deliberadamente conservador. Su propia cabecera lo describe como exclusivamente de capa de presentación: nunca altera lo que se firma, y falla de forma cerrada. Un selector desconocido, una longitud equivocada, hexadecimal malformado o un relleno de dirección no estándar hacen que no devuelva nada y se repliegue a una acción genérica con el hexadecimal en bruto tras una vista «Avanzado». Prefiere admitir que no sabe antes que adivinar con aplomo y equivocarse. Los símbolos y decimales de los tokens solo se adjuntan cuando se conocen desde el registro del propio dispositivo, nunca se infieren.

Ahora la frontera honesta. El decodificador no tiene noción alguna de proxy. No hay en él ningún concepto de contrato de implementación. Puede decirte, con corrección y claridad, «estás concediendo un permiso ilimitado de USDC a 0xABC…», y no puede decirte que 0xABC es un proxy, quién tiene su clave de actualización, o que su comportamiento puede ser completamente distinto la semana que viene.

Eso no es tanto un descuido como una frontera que ningún decodificador de cartera puede cruzar. Decodificar describe la llamada que tienes delante. Si la contraparte es actualizable, y quién la gobierna, es una propiedad del mundo más amplio que hay que comprobar aparte. Preferimos enunciar la frontera antes que dejar que una pantalla de aprobación de aspecto seguro insinúe una completitud que no tiene.

Una comprobación práctica antes de aprobar algo importante

¿Está verificado? Si no, entiende que estás confiando solo en la reputación.

¿Es un proxy? Los exploradores lo etiquetan: busca un aviso de proxy o una opción «Leer como proxy». Si está ahí, la implementación es el código que importa.

¿Quién puede actualizarlo y hay retardo? Es la pregunta de mayor valor de la lista y la que casi nadie hace. Un proyecto que haya pensado en esto lo documentará. Uno que no lo haya hecho, o no quiera decirlo, ya te ha dicho algo.

¿Hace falta que la aprobación sea ilimitada? Normalmente no. Aprobar la cantidad que realmente pretendes gastar acota tu exposición exactamente a eso, sea en lo que sea que el contrato se convierta después.

Revoca cuando hayas terminado. Un permiso abierto es una autorización permanente, y sobrevive a tu atención.

El ajuste mental que merece la pena hacer es pequeño pero cambia mucho. La verificación te dice qué código se está ejecutando ahora mismo. La actualizabilidad te dice quién decide qué se ejecutará mañana. Casi todo el riesgo vive en la segunda pregunta, y casi toda la tranquilidad que se ofrece atiende únicamente a la primera.