Cuando empecé a indagar sobre la autorización programable, asumí que cambiar una regla implicaría cambiar el contrato inteligente que la hace cumplir. Eso parecía inevitable.
Si una bóveda redujera su exposición máxima, añadiera una dirección restringida, modificara una puntuación de riesgo aceptable o introdujera una nueva condición de cumplimiento, con toda seguridad el contrato que protege la bóveda tendría que reescribirse y desplegarse nuevamente.
Cuanto más analizaba @NewtonProtocolMainnet Beta, más esa suposición empezaba a sentirse al revés. Newton separa la aplicación que se protege de la política que decide lo que la aplicación tiene permitido hacer.
Cómo evalúa una Política de Newton la Intención de una Transacción
Una política de Newton evalúa la intención de una transacción usando tres tipos diferentes de información:
La transacción en sí
Valores configurables bajo "data.params
Información en vivo devuelta por oráculos de datos bajo "data.wasm"
Por lo tanto, la política puede comparar la misma acción solicitada contra umbrales cambiantes, listas de permitidos, resultados de identidad, precios o señales de riesgo, sin empujar toda esa lógica directamente al contrato de la aplicación.
¿Qué se mantiene permanente?
Esa distinción suena técnica. En realidad cambia lo que tiene que permanecer permanente.
El límite de aplicación puede seguir conectado a la aplicación mientras las reglas detrás de ese límite continúan evolucionando. La propia documentación de Newton describe las políticas como actualizables sin requerir que el contrato protegido se redeploye, mientras que el anuncio de Mainnet Beta ofrece ejemplos como un umbral revisado o un nuevo requisito de sanciones que entran en efecto sin reescribir el contrato de la aplicación.
Lo que llamó mi atención es que Newton no está eligiendo realmente entre código inmutable y políticas flexibles. Está intentando darle a cada uno un trabajo diferente:
El Contrato de la Aplicación: define dónde debe ocurrir la autorización.
La Política: define qué condiciones deben cumplirse actualmente.
Datos del Oráculo: pueden ser distintos para cada transacción.
Pero el oráculo, la política y el smart contract no necesitan cambiar todos al mismo tiempo. El smart contract en sí puede permanecer en su lugar durante años. Un umbral de riesgo podría cambiar el próximo mes. Un resultado de sanciones o una señal de salud del mercado podría cambiar antes de que llegue la siguiente transacción. Codificar las tres cosas en el mismo contrato haría que la parte más lenta del sistema sea responsable de información que cambia mucho más rápido.
Newton los separa. Eso podría importar más de lo que parece al principio.
Un problema de gobernanza más preciso
En el diseño tradicional de smart contracts, la actualizabilidad a menudo se trata como un problema a nivel de contrato. O el contrato es fijo, o alguien tiene permiso para actualizarlo.
Newton introduce otra capa entre esas dos opciones. La aplicación protegida puede permanecer estable mientras las condiciones de autorización que rodean acciones específicas se ajustan por separado.
Así que la pregunta deja de ser: ¿Este contrato se puede actualizar?
Y se convierte en: qué partes del proceso de autorización se permite que cambien, quién controla esos cambios y qué partes permanecen permanentemente conectadas a la ejecución?
Ese es un problema de gobernanza mucho más preciso.
El intercambio de la flexibilidad
La flexibilidad no siempre significa más seguridad. Una política que se actualiza rápidamente puede adaptarse a nuevas leyes, cambios de mercado o amenazas de seguridad. Pero también puede cambiar las reglas que los usuarios aceptaron originalmente.
Bajar un límite de riesgo puede proteger el capital.
Ampliar silenciosamente una lista de permitidos o debilitar un requisito de seguridad podría hacer lo contrario.
El peligro no desaparece porque la política esté separada del contrato; se desplaza hacia la gobernanza de la política.
¿Quién tiene permitido actualizar los parámetros?
¿Qué tan visible es el cambio?
¿Los usuarios pueden inspeccionar la política que protege actualmente a una aplicación?
¿Las versiones anteriores siguen siendo entendibles después de que una nueva las reemplaza?
Esas preguntas se vuelven igual de importantes que la lógica de Rego en sí misma. Esa es la parte a la que sigo regresando.
Conclusión: permanencia en la aplicación
Newton no está haciendo permanentes las reglas financieras. Los requisitos reales de cumplimiento, las tolerancias de riesgo y las condiciones de seguridad cambian con demasiada frecuencia como para que eso sea realista.
Lo que intenta hacer permanente es el requisito de que las acciones protegidas deben pasar por la autorización en todo momento
La regla puede cambiar
Los datos pueden cambiar.
El umbral puede cambiar.
Pero la aplicación no puede dejar de pedir permiso en silencio.
Para mí, esa es una forma de consistencia más interesante que codificar para siempre cada regla. Newton no está congelando la política. Está fijando el punto en el que la política tiene que importar.
