При изучении архитектуры @NewtonProtocol большинство внимания обычно уделяют Rego Policy, PolicyData или BLS-аттестациям. Однако технический Whitepaper подробно описывает ещё один важный компонент системы, который практически не обсуждается, хотя именно он помогает сети $NEWT быстро согласовывать результаты проверки. Речь идёт о системе потоковой передачи сообщений NATS Streaming.
Чтобы понять её роль, сначала стоит посмотреть, как обычно взаимодействуют распределённые сервисы.
Во многих архитектурах используется модель RPC. Один сервис отправляет запрос другому, ожидает ответ, затем получает ответы от остальных участников и только после этого может продолжить обработку. Даже если несколько запросов выполняются параллельно, инициатор всё равно должен принимать и обрабатывать большое количество отдельных ответов.
В архитектуре #Newt обмен сообщениями организован иначе.
Когда приложение отправляет Intent на проверку, Gateway не начинает последовательно обращаться к каждому оператору. Вместо этого он публикует одну задачу (Task) в поток сообщений NATS, после чего все подключённые операторы получают её практически одновременно.
Это означает, что вся сеть начинает выполнять проверку параллельно.
Каждый оператор независимо загружает необходимую Policy, выполняет Rego Policy, при необходимости получает внешние данные через WASM-компоненты и формирует собственный результат проверки. Эти вычисления происходят одновременно, а не по очереди.
Технический Whitepaper отдельно подчёркивает, что между Gateway и операторами используется non-blocking pipelined communication. Другими словами, агрегатор начинает получать ответы сразу после их появления и не ждёт завершения работы всей сети, прежде чем приступить к обработке результатов.
Следующим элементом архитектуры становится механизм Early Quorum Exit.
Для подтверждения результата Newton не требуется получить ответы от всех операторов. Как только агрегатор получает достаточное количество корректных BLS-подписей, соответствующее необходимому кворуму, он может завершить формирование итоговой аттестации. Более поздние ответы уже не задерживают выполнение операции.
Это особенно важно в распределённой сети.
Если часть операторов отвечает медленнее из-за сетевых задержек или более длительного получения внешних данных, остальные участники не обязаны ждать завершения всех вычислений. Авторизация продолжается сразу после достижения необходимого уровня подтверждения.
Документация также описывает ещё одну функцию агрегатора. Помимо объединения BLS-подписей, он использует медианный консенсус при обработке числовых результатов, если между ответами операторов возникают допустимые различия. После этого формируется одна компактная BLS-аттестация, которую уже проверяет смарт-контракт.
Благодаря такой архитектуре поток сообщений не превращается в последовательную очередь ожидания.
Gateway публикует задачу один раз. Все операторы начинают обработку одновременно. Результаты поступают агрегатору по мере готовности. После достижения кворума формируется единая BLS-аттестация, а смарт-контракту больше не требуется проверять множество отдельных подписей.
Именно поэтому технический Whitepaper рассматривает NATS Streaming не как вспомогательный транспортный механизм, а как один из ключевых элементов архитектуры @NewtonProtocol . Вместе с параллельной обработкой задач, Early Quorum Exit, медианным консенсусом и BLS-агрегацией он позволяет сети $NEWT достигать подтверждения результатов менее чем за секунду, сохраняя воспроизводимость проверки и децентрализованный характер процесса авторизации в #Newt .