Cómo saber si un equipo todavía puede cambiar el contrato

La pregunta debajo de la pregunta

“¿Puede el equipo cambiar el contrato?” son en realidad tres preguntas, y mezclarlas es la razón de que las respuestas que la gente recibe resulten confusas.

• ¿Puede reemplazarse el código? Eso es la actualizabilidad, y es la palanca mayor.
• ¿Puede cambiarse un valor dentro del código sin reemplazarlo? Comisiones, límites, direcciones, si las transferencias están pausadas.
• ¿Quién puede accionar cualquiera de las dos palancas, y hay algo que lo frene? Una sola llave, un multifirma, una votación, un retardo.

Un contrato puede ser inmutable y aun así permitir que una dirección vacíe la reserva, si el código lo dice. Un contrato puede ser actualizable y seguro en la práctica, si actualizarlo lleva una semana y una votación. La palabra por sí sola no dice nada.

Comprobación uno: ¿está el código publicado y coincide?

En el explorador de bloques, un contrato no verificado muestra bytecode y nada más. Verificado significa que alguien subió un código fuente que compila exactamente a ese bytecode. Si el código no está verificado, pare: no puede comprobar nada más, y le están pidiendo que confíe en una captura de pantalla.

El código verificado es necesario, no suficiente. Lo publicado puede ser honesto y aun así dar al desplegador poderes que usted no aceptaría.

Comprobación dos: ¿es un proxy?

Un proxy guarda sus fondos y reenvía cada llamada a un segundo contrato que contiene la lógica. Cambie esa segunda dirección y el comportamiento cambia por completo mientras la dirección con la que usted interactuó sigue igual. Así funcionan la mayoría de las actualizaciones, y también la mayoría de los fraudes que sobreviven a una auditoría.

• Los exploradores suelen etiquetarlo: una pestaña “Read as Proxy”, o una nota de que la dirección es un proxy.
• En el código, busque una función que fije una dirección de implementación: el nombre varía, la forma no.
• Si es un proxy, la única pregunta que importa es quién puede llamar a esa función y con qué rapidez surte efecto.

Comprobación tres: ¿qué puede hacer un propietario?

Lea en el código las funciones protegidas por un rol de propietario o administrador, y léalas como una lista de cosas que pueden ocurrirle a usted sin su consentimiento. Los nombres cambian entre proyectos; las formas son las mismas en todas partes:

• Acuñación. ¿Pueden crearse unidades nuevas fuera de la regla publicada? Un límite de oferta en un documento no es un límite; en el código sí lo es.
• Retirada. ¿Hay alguna vía por la que el colateral salga sin que un usuario lo pida?
• Pausa. ¿Pueden detenerse las transferencias o los rescates? ¿Quién los reanuda?
• Comisiones. ¿Hay un tope en el código, o la tasa puede fijarse en cualquier valor?
• Listas. ¿Puede bloquearse a una dirección para que no venda? Así es como un token se convierte en una puerta de un solo sentido.

Para cada una, la pregunta útil no es “¿lo harían?”, sino “¿qué se lo impide?”. La respuesta es una regla en el código, o no es nada.

Comprobación cuatro: quién tiene la llave y qué lo frena

Una única cuenta externa significa una persona, un correo de phishing, una firma forzada. Un multifirma es mejor y los números importan: tres de cinco es un comité, uno de tres es un punto único disfrazado. Un retardo no impide una acción; le da aviso, que es justamente el objetivo: usted puede marcharse antes de que surta efecto.

La gobernanza por votación de tokens desplaza la pregunta otra vez: ahora se trata de quién tiene los tokens. Si un puñado de direcciones puede aprobar cualquier cosa, la votación es una formalidad con pasos añadidos.

Qué resuelve una auditoría y qué no

Una auditoría comprueba si el código hace lo que sus autores pretendían y si un atacante puede romperlo. No le dice si el diseño pretendido es uno que usted quiera. Un contrato puede pasar una auditoría limpiamente y contener una función de propietario que vacía la reserva, porque esa función era intencionada y estaba declarada. Lea el informe por su alcance: qué se revisó, en qué commit y qué quedó excluido.

El orden que ahorra tiempo

• ¿Código verificado? Si no, pare.
• ¿Proxy? Si sí, averigüe quién puede cambiar la implementación y con qué rapidez.
• Funciones de propietario: acuñar, retirar, pausar, comisión, bloquear. Anote cada una.
• Quién tiene la llave: llave única, multifirma con números reales, o votación.
• Retardo: ¿hay un timelock y es lo bastante largo para reaccionar?
• Solo entonces lea la auditoría, y lea su alcance antes que su conclusión.