Al estudiar la arquitectura @NewtonProtocol , la mayoría de la atención suele centrarse en Rego Policy, PolicyData o las atestaciones BLS. Sin embargo, el whitepaper técnico describe con detalle otro componente importante del sistema, que prácticamente no se comenta, aunque precisamente es él el que ayuda a la red $NEWT a ponerse rápidamente de acuerdo sobre los resultados de la comprobación. Se trata del sistema de transmisión en streaming de mensajes de NATS Streaming.
Para entender su papel, primero conviene ver cómo suelen interactuar los servicios distribuidos.
En muchas arquitecturas se utiliza un modelo RPC. Un servicio envía una solicitud a otro, espera la respuesta, luego recibe las respuestas del resto de participantes y solo después puede continuar con el procesamiento. Aunque varias solicitudes se ejecuten en paralelo, el iniciador de todos modos debe aceptar y procesar una gran cantidad de respuestas individuales.
En la arquitectura #Newt, el intercambio de mensajes se organiza de otra manera.
Cuando la aplicación envía un Intent para su verificación, Gateway no empieza a contactar secuencialmente con cada operador. En lugar de eso, publica una única tarea (Task) en el flujo de mensajes NATS; después, todos los operadores conectados la reciben prácticamente al mismo tiempo.
Esto significa que toda la red empieza a ejecutar la verificación en paralelo.
Cada operador carga de forma independiente la Policy necesaria, ejecuta la Rego Policy y, si es necesario, obtiene datos externos mediante componentes WASM, para luego formar su propio resultado de verificación. Estos cálculos ocurren simultáneamente, no uno tras otro.
El Whitepaper técnico subraya por separado que entre Gateway y los operadores se utiliza una comunicación pipelined non-blocking. En otras palabras, el agregador empieza a recibir las respuestas en cuanto aparecen y no espera a que termine toda la red antes de comenzar a procesar los resultados.
El siguiente elemento de la arquitectura es el mecanismo Early Quorum Exit.
Para verificar el resultado, Newton no necesita obtener respuestas de todos los operadores. En cuanto el agregador recibe una cantidad suficiente de firmas BLS correctas que corresponda al quórum necesario, puede finalizar la formación de la atestación final. Las respuestas posteriores ya no retrasan la ejecución de la operación.
Esto es especialmente importante en una red distribuida.
Si una parte de los operadores responde más lentamente debido a latencias de red o a una obtención más prolongada de datos externos, los demás participantes no tienen que esperar a que terminen todos los cálculos. La autorización continúa inmediatamente después de alcanzar el nivel necesario de confirmación.
La documentación también describe otra función del agregador. Además de agregar firmas BLS, utiliza un consenso mediano al procesar resultados numéricos si entre las respuestas de los operadores se producen diferencias aceptables. Después de eso, se forma una única atestación BLS compacta, que ya verifica el smart contract.
Gracias a esta arquitectura, el flujo de mensajes no se convierte en una cola secuencial de espera.
Gateway publica la tarea una sola vez. Todos los operadores comienzan a procesarla simultáneamente. Los resultados llegan al agregador a medida que se van obteniendo. Tras alcanzar el quórum, se forma una única atestación BLS y ya no es necesario que el smart contract verifique una multitud de firmas individuales.
Por eso, el Whitepaper técnico considera NATS Streaming no como un mecanismo de transporte auxiliar, sino como uno de los elementos clave de la arquitectura @NewtonProtocol . Junto con el procesamiento en paralelo de tareas, Early Quorum Exit, el consenso mediano y la agregación BLS, permite que la red $NEWT alcance la confirmación de los resultados en menos de un segundo, manteniendo la reproducibilidad de la verificación y el carácter descentralizado del proceso de autorización en #Newt .