При изучении документации
@NewtonProtocol можно заметить важную особенность архитектуры. Хотя Newton часто воспринимают как единую систему проверки транзакций, документация последовательно разделяет два самостоятельных компонента: Gateway и сеть операторов AVS. Каждый из них выполняет собственную функцию и не дублирует работу другого.
Практически любая проверка начинается с Gateway.
Согласно документации RPC API, приложения взаимодействуют с Newton через интерфейс JSON-RPC 2.0 по протоколу HTTPS. Все запросы отправляются в Gateway через конечную точку /rpc, а не напрямую операторам сети. Каждый запрос использует UUID в качестве идентификатора, а доступ к API осуществляется только после проверки API-ключа, передаваемого в заголовке Authorization.
После получения запроса Gateway не принимает решение о разрешении или запрете операции.
Его задача заключается в создании задачи (Task) и её передаче в сеть операторов Newton AVS. Уже операторы независимо выполняют PolicyData, получают необходимые внешние данные, запускают Rego Policy и формируют собственные результаты проверки. Таким образом, Gateway обеспечивает передачу задачи, а не её оценку.
Этот процесс подробно показан и в Integration Guide.
После отправки Intent через SDK запрос сначала поступает в Gateway. Затем Gateway передаёт задачу операторам сети. После завершения проверки агрегированная BLS-аттестация возвращается приложению, которое отправляет её вместе с транзакцией в PolicyClient смарт-контракта. Gateway не выполняет транзакции в блокчейне и не изменяет состояние сети.
Документация также показывает, что через Gateway проходят основные сервисы протокола.
Через RPC API выполняются создание задач проверки, симуляция Policy и PolicyData, управление зашифрованными секретами, получение результатов проверки и другие операции. Для этих методов используются различные уровни разрешений API-ключей, включая RpcRead и RpcWrite. Для части методов Gateway дополнительно проверяет владельца PolicyClient, обращаясь непосредственно к функции getOwner() смарт-контракта, а не используя собственное внутреннее состояние.
Это означает, что Gateway не является источником доверия для принятия решения.
Даже если запрос проходит через него, итоговая оценка формируется распределённой сетью операторов Newton. При работе с секретами Gateway дополнительно сверяет права доступа с ончейн-состоянием PolicyClient, поэтому проверка полномочий основывается на данных блокчейна.
Сравнение Dashboard, CLI и SDK показывает ещё одну особенность архитектуры.
Все три инструмента используют один и тот же набор возможностей протокола. Dashboard предоставляет графический интерфейс, CLI работает из командной строки, а SDK предназначен для интеграции в приложения. Независимо от выбранного способа работы все они взаимодействуют с одним и тем же Gateway через единый RPC API. Меняется только интерфейс для разработчика, тогда как сама архитектура протокола остаётся одинаковой.
После завершения проверки Gateway возвращает приложению агрегированную BLS-аттестацию сети. Затем приложение самостоятельно отправляет транзакцию вместе с этой аттестацией в PolicyClient. Смарт-контракт проверяет криптографическое подтверждение и только после успешной проверки выполняет защищённую операцию. Gateway не участвует в исполнении транзакции и не может самостоятельно разрешить её выполнение.
Именно поэтому документация
@NewtonProtocol разделяет функции компонентов. Gateway предоставляет единый интерфейс доступа к протоколу, принимает RPC-запросы и маршрутизирует задачи в сеть операторов. Сеть операторов выполняет проверку Policy и формирует агрегированную BLS-аттестацию. PolicyClient проверяет эту аттестацию в блокчейне перед исполнением защищённой операции. Благодаря такому разделению
$NEWT распределяет доступ к системе, процесс проверки и исполнение транзакции между независимыми уровнями архитектуры
#Newt , а не объединяет их в одном компоненте.