Tengo el hábito de que probablemente me hace perder tiempo más de lo que debería. Cada vez que leo una explicación técnica de algo y no logro averiguar qué problema está resolviendo en realidad, me detengo y vuelvo al principio. Me niego a avanzar hasta que el problema esté claro. Porque si no entiendo qué está roto, no puedo evaluar si la solución realmente funciona.
Así que permítanme hacerlo aquí con el diseño de consenso de dos fases de Newton. Primero el problema. Luego la solución.
El Problema del que Nadie Habla lo Suficiente
Aquí tienes algo que no pensé con claridad hasta que empecé a profundizar en cómo funcionan realmente las redes de políticas distribuidas. Cuando una transacción se comprueba contra datos en vivo antes de que se liquide, esa comprobación no se está realizando contra una única fuente de verdad limpia y única. Está ocurriendo a través de una red de operadores, y cada uno de esos operadores podría estar mirando información ligeramente diferente en ese mismo momento.
¿Qué significa realmente “datos en vivo” en la práctica? Se actualiza una lista de sanciones. Se marca una dirección de billetera. Un feed de precios marca un cambio (tick). Estas actualizaciones no llegan a todos los operadores exactamente al mismo tiempo. Un operador podría tener la lista de sanciones actualizada dos segundos antes que otro. Uno podría estar ejecutando un feed de precios que va ligeramente atrasado debido a un retraso de enrutamiento en algún punto de la red.
Ahora entra una transacción para evaluación. El operador A la comprueba con datos que incluyen la última actualización de sanciones. El operador B comprueba la misma transacción con datos que aún no tienen esa actualización. Uno dice que la transacción pasa. El otro dice que hay que bloquearla. La red está en desacuerdo y nadie diseñó una manera fundamentada de resolverlo.
Quiero ser claro sobre algo aquí porque creo que se pasa por alto con demasiada facilidad. Esto no es un caso extremo ni un escenario de peor caso. Es la condición normal de cualquier sistema distribuido que trabaja con datos en tiempo real. Los datos llegan en momentos distintos a nodos distintos. Así es como se comportan las redes. La pregunta es si tu sistema está diseñado para manejar eso con honestidad o si simplemente espera en silencio que el momento nunca importe.
Por qué los datos financieros hacen esto más difícil
La razón por la que me resulta particularmente incómodo este problema en el contexto de Newton es cuál es realmente el dato en vivo. No hablamos de datos en los que una inconsistencia de dos segundos sea inofensiva. Hablamos de listas de sanciones, feeds de precios y umbrales de riesgo.
Las listas de sanciones se actualizan sin aviso. Aparece una nueva entidad y, a partir de ese momento, cualquier transacción que involucre esa entidad debería bloquearse. Si un operador tiene esa actualización y el otro no, la misma transacción podría pasar por un lado de la red y bloquearse por el otro. Eso no es una falla técnica. Es un fallo de cumplimiento.
Los feeds de precios se mueven rápido. Una transacción que superó un umbral de riesgo según el precio actual podría verse bien frente a un feed que está treinta segundos atrasado. Los números son distintos. La decisión es distinta. Y nadie fuera del sistema puede saber qué operador tenía los datos correctos.
Esto es con lo que seguí topándome cuando intentaba entender qué es lo que realmente resuelve el diseño de dos fases de Newton. No es solo conseguir que los operadores se pongan de acuerdo en general. Es conseguir que se pongan de acuerdo específicamente sobre qué datos estaban usando cuando tomaron su decisión. Esa distinción importa muchísimo.
Qué hace realmente el consenso de dos fases
Cuando por fin entendí el diseño, la lógica me pareció obvia en retrospectiva. Lo cual suele ser una señal de que alguien resolvió algo correctamente.
Newton divide el proceso de evaluación en dos pasos separados, en lugar de ejecutarlo todo a la vez. El primero se llama fase de Preparación. El segundo se llama fase de Evaluación.
Esto es lo que hizo que encajara para mí. La fase de Preparación no evalúa nada. Solo acuerda. Antes de que cualquier operador toque las comprobaciones reales de la política, la red alcanza consenso sobre exactamente qué datos utilizará cada operador para la evaluación. No datos aproximadamente iguales. No cualquier cosa que cada operador tenga localmente en ese momento. La misma instantánea exacta, acordada y fijada antes de que comience la evaluación.
Ese único movimiento elimina el problema. La inconsistencia entre operadores existía porque cada uno evaluaba con su propia versión local de los datos en vivo. La fase de Preparación reemplaza todas esas diferentes vistas locales por una única instantánea compartida en la que todos los operadores de la red están de acuerdo.
Luego se ejecuta la fase de Evaluación. Cada operador comprueba la transacción frente a esa instantánea acordada. Como las entradas son idénticas, los resultados son comparables. La red puede alcanzar un consenso real sobre el resultado porque ya no hay un desacuerdo de datos debajo de la decisión.
Dónde encaja NATS en todo esto
La coordinación entre operadores a través de ambas fases se ejecuta sobre NATS. Cuando por primera vez me encontré con NATS en este contexto tuve que buscarlo porque lo asocié más con ingeniería de infraestructura que con sistemas en cadena. Esa asociación es correcta. NATS es un sistema de mensajería construido para entornos distribuidos de alto rendimiento. Se ha usado en servicios financieros y plataformas cloud durante años. Es rápido, confiable a escala y está construido exactamente para situaciones en las que muchos nodos necesitan intercambiar mensajes con una latencia mínima.
En el diseño de Newton, NATS es el canal a través del cual se ejecuta la fase de Preparación. Los operadores lo usan para establecer la instantánea compartida de datos antes de que comience la evaluación. La coordinación es lo bastante rápida como para que no añada un retraso significativo al proceso, pero está lo bastante estructurada como para que el acuerdo sea verificable y no simplemente asumido.
Lo que valoro de esta elección es lo mismo que valoro de que Newton use Rego para el lenguaje de políticas: es infraestructura probada con trayectoria en sistemas de producción. A nadie se le pide confiar en una capa de mensajería personalizada que nunca se haya sometido a pruebas de estrés a escala. NATS lo ha sido.
Cómo se ve desde fuera
Desde fuera, si solo estás viendo que se evalúa una transacción, el diseño de dos fases es invisible. La transacción entra. Vuelve un resultado. Pasa o se bloquea.
Lo que no puedes ver es que, antes de ejecutarse las comprobaciones de la política, toda la red acordó los datos contra los que esas comprobaciones se ejecutarían. Listas de sanciones, feeds de precios, parámetros de riesgo: todo quedó fijado a una única instantánea en cada operador participante. El resultado que regresa no es la visión de un solo operador basada en lo que le tocó tener localmente. Es un resultado de consenso basado en entradas que la red verificó junta.
Por qué esta es la parte que hace que el cumplimiento sea real
Vuelvo a una sola cosa cuando pienso en por qué este diseño importa más allá de su elegancia técnica.
Una comprobación de cumplimiento que podría producir resultados diferentes dependiendo de qué operador la ejecute, en realidad no es una comprobación de cumplimiento. Es algo más parecido a una suposición con pasos extra. Si la salida varía según qué nodo haya tenido los datos más recientes, entonces la salida no significa nada de manera consistente. No puedes basar un compromiso regulatorio en algo que es inconsistente.
Al resolver el problema del acuerdo sobre los datos antes de que comience la evaluación, Newton hace que la fase de Evaluación sea algo en lo que realmente puedes confiar. El resultado significa lo mismo sin importar a qué operador le preguntes, porque todos trabajaron con las mismas entradas. Esa consistencia es lo que convierte una comprobación de políticas preestablecida en un mecanismo de cumplimiento real, en lugar de solo una demostración de desempeño.
La versión simple
Dos operadores no deberían poder estar en desacuerdo sobre una transacción porque uno tenga una lista de sanciones más nueva que el otro. Newton lo resuelve haciendo que los operadores se pongan de acuerdo sobre los datos exactos que usarán antes de que se ejecute cualquier evaluación. La fase de Preparación fija los datos. La fase de Evaluación ejecuta las comprobaciones. NATS maneja la coordinación entre medio.
El resultado es una comprobación de cumplimiento que es consistente en toda la red, no solo consistente con quien recibió primero la actualización más reciente. En un sistema donde la salida final es una prueba en cadena (on-chain) de que una transacción fue verificada correctamente, esa consistencia no es un “detalle agradable de tener”. Es todo el punto.
#SKHynixSaysFundsEyeUpTo$7BInADRs #AsianPCBStockSlideOnNvidiaAIServerDelay #AsianPCBStockSlideOnNvidiaAIServerDelay #Newt $NEWT