Pasé un tiempo pensando en de qué @NewtonProtocol operadores son realmente responsables una vez que una tarea de política pasa a través de la red.
Al principio, la respuesta parecía sencilla.
Los operadores evalúan la política.
Verifican las condiciones requeridas.
Contribuyen firmas hacia la prueba final.
Sencillo.
Pero mientras más observaba el flujo de ejecución de Newton, más difícil se volvía tratar la aprobación de la política y la responsabilidad operativa como lo mismo.
Porque la arquitectura de Newton parece separarlos con mucho cuidado.
Una tarea de política puede pasar la evaluación.
La acción aguas abajo aún puede fallar.
Esa distinción importa mucho más de lo que primero me di cuenta.
El flujo documentado de Newton separa la evaluación de políticas de la ejecución de transacciones en múltiples componentes. Los operadores recuperan los datos necesarios, evalúan la política Rego y aportan firmas BLS para unificar una prueba agregada que confirma que se cumplieron las condiciones evaluadas.
Entonces, un PolicyClient puede verificar la prueba agregada antes de permitir que la transacción u operación protegida continúe.
A primera vista, es fácil comprimir mentalmente todo ese flujo en una sola idea:
«La red aprobó la acción».
Pero esa formulación oculta silenciosamente un límite importante.
La red de operadores evalúa si se cumplieron las condiciones de política definidas en el momento de la evaluación.
Tampoco asume automáticamente la responsabilidad de todo lo que ocurra después.
Eso suena obvio hasta que sigues con más detalle el ciclo de vida de la ejecución.
Un contrato aguas abajo aún puede revertir.
Una dependencia externa aún puede fallar.
Una transacción aún puede quedarse sin gas.
Un servicio requerido aún puede quedar temporalmente no disponible.
La evaluación de la política puede seguir siendo válida mientras que el resultado operativo aún se rompa en algún lugar más adelante en la ruta de ejecución.
Lo que destacó no fue la existencia del fallo.
Los sistemas distribuidos siempre contienen límites de fallo.
Lo que destacó fue dónde parece Newton ubicar la responsabilidad de esas fallas.
La red de políticas demuestra que los operadores evaluaron el conjunto de reglas definido y acordaron colectivamente el resultado de la evaluación.
Pero la responsabilidad operativa todavía permanece parcialmente con el entorno de aplicación circundante, la implementación de PolicyClient, los contratos aguas abajo, las dependencias de infraestructura, las suposiciones de ejecución y la lógica que las conecta entre sí.
Eso crea una separación más limpia de lo que yo esperaba inicialmente.
La evaluación colectiva no centraliza automáticamente la responsabilidad operativa.
Sigo volviendo a esa distinción.
Porque, a menudo, los sistemas modernos de infraestructura difuminan esos límites entre sí.
Los usuarios ven una acción aprobada y asumen que todo el flujo de trabajo en sí se ha vuelto confiable de extremo a extremo.
Pero la arquitectura de Newton parece ser más cuidadosa que eso.
La capa de evaluación demuestra que las condiciones de política definidas se cumplieron durante la evaluación.
No garantiza que cada dependencia aguas abajo, entorno de ejecución o sistema externo continúe comportándose correctamente después.
Son preguntas de seguridad diferentes.
Y, honestamente, separarlas puede ser más saludable para los sistemas de infraestructura a largo plazo.
Porque, una vez que la evaluación de políticas, los entornos de ejecución, las dependencias externas y la lógica de la aplicación comienzan a interactuar de forma continua, fingir que comparten límites de responsabilidad idénticos puede generar aún más confusión.
Especialmente cuando los sistemas adaptativos comienzan a coordinar acciones más rápido de lo que los humanos pueden inspeccionar manualmente cada paso operativo en tiempo real.
El resultado válido de la política aún puede entrar en un entorno de ejecución poco saludable.
Una tarea evaluada correctamente aún puede depender de una infraestructura aguas abajo poco confiable.
Una operación aprobada aún puede fallar porque las condiciones circundantes cambiaron después de que ocurrió la evaluación.
La red puede validar condiciones.
No puede congelar la realidad a su alrededor.
Eso se siente como una de las distinciones más importantes que se ocultan dentro de la arquitectura de Newton.
Y también cambia la forma en que la responsabilidad puede necesitar comunicarse a los usuarios que construyen sobre estos sistemas.
El consenso sobre el operador puede demostrar que una política se evaluó correctamente.
Tampoco explica automáticamente adónde se traslada la responsabilidad operativa cuando la ejecución sale del límite de evaluación y entra en el ciclo de vida más amplio de la aplicación.
Eso no es necesariamente un fallo.
En muchos sentidos, puede ser un modelo de infraestructura más honesto.
La evaluación distribuida de políticas puede reducir los supuestos de confianza en torno a las decisiones de autorización sin pretender que el acuerdo criptográfico elimine mágicamente el riesgo operativo del resto del sistema.
Aun así, la separación plantea preguntas importantes sobre la infraestructura.
Si una dependencia aguas abajo falla después de la aprobación de la política, ¿cómo deberían las aplicaciones comunicar esa distinción a los usuarios?
¿Dónde debería residir la responsabilidad de reintento?
¿Cuánta confianza operativa sigue estando fuera del límite de política evaluado?
Y una vez que los sistemas financieros autónomos empiecen a coordinar acciones de manera continua en múltiples entornos, ¿los usuarios entenderán claramente qué capa falló realmente?
La arquitectura de Newton parece responder con mucho cuidado a una pregunta:
si las condiciones de política se evaluaron y verificaron colectivamente.
La pregunta más difícil puede empezar después.
¿Adónde se traslada realmente la responsabilidad operativa cuando la ejecución verificada entra en el mundo real?