Originalmente pensé que @NewtonProtocol trataba principalmente de la conformidad programable. Después de pasar más tiempo con la arquitectura, me encontré prestando menos atención a políticas individuales y más atención a dónde realmente viven esas políticas. Ese cambio alteró la forma en que miré el protocolo.
El diseño separa la autorización de la ejecución de la aplicación en lugar de incrustar las reglas de negocio directamente dentro de cada contrato inteligente. Las políticas escritas en Rego definen la lógica de autorización, mientras que las aplicaciones individuales aportan sus propias restricciones operativas mediante la configuración de PolicyClient. Los límites de gasto, los destinatarios aprobados, las restricciones jurisdiccionales y requisitos similares se convierten en una configuración estructurada de tiempo de ejecución en lugar de quedar codificados de forma permanente como lógica de políticas.
Esa distinción se siente más significativa de lo que parece a primera vista. Una sola política puede seguir siendo reutilizable mientras diferentes aplicaciones operen dentro de distintos límites de autorización simplemente cambiando la configuración. La política describe el proceso de decisión. La aplicación proporciona el contexto. Esas responsabilidades son intencionalmente independientes.
Pero algo seguía rondándome.
La reutilización solo funciona si la autorización permanece vinculada a las suposiciones exactas que la produjeron. Newton lo aborda generando un nuevo identificador de política cada vez que cambia la configuración de PolicyClient. Las atestaciones producidas bajo una configuración anterior ya no se aplican una vez que cambia el identificador de política al que se hace referencia. Por lo tanto, la autorización queda vinculada no solo a la lógica de la política, sino también a la configuración precisa que existía cuando se generó la aprobación.
El diseño cambia el límite.
En lugar de modificar el código de la aplicación cada vez que evolucionan los requisitos operativos, los desarrolladores ajustan las políticas o la configuración manteniendo la lógica de la aplicación. Eso puede simplificar el mantenimiento entre múltiples aplicaciones, pero también traslada la responsabilidad hacia la gestión de políticas. La configuración en sí se convierte en parte del modelo de seguridad en lugar de ser un detalle de despliegue. La información externa introduce otra capa de responsabilidad. PolicyData Oracles se ejecutan como componentes WASM aislados, devolviendo datos de ejecución estructurados que las políticas evalúan de forma determinista. El entorno de ejecución restringe intencionalmente el acceso a la red, y los fallos se tratan de manera diferente según dónde ocurren. Los errores estructurados de la aplicación siguen siendo visibles para la evaluación de la política, mientras que los fallos de ejecución se convierten en eventos DataProviderError que detienen la autorización por completo en lugar de producir una decisión normal.
No elimina la confianza. La traslada.
La caducidad de la atestación introduce otra decisión operativa. Ventanas de aprobación cortas reducen las oportunidades de repetición (replay), mientras que ventanas más largas brindan a los usuarios más flexibilidad antes de la ejecución. Ninguna de las dos opciones son ventanas de caducidad que equilibren la resistencia al replay con la usabilidad. En última instancia, los usuarios interactúan con atestaciones cuya validez refleja tanto la versión de la política como el contexto de ejecución, en lugar de depender únicamente del estado del contrato.
Visto de esta manera, Newton parece menos centrado en reemplazar la lógica de los contratos inteligentes que en reubicar dónde evoluciona la autorización a medida que cambian los requisitos de la aplicación.
¿Mover la evolución de la política fuera de los contratos desplegados simplifica la seguridad a largo plazo, o simplemente crea otra capa donde se acumula complejidad operativa?
$NEWT #Newt $SUI $ETH