На что я постоянно возвращался — это насколько разной является авторизация и исполнение. Блокчейны стали очень хороши в доказательстве того, что транзакция произошла. Newton Protocol задаёт другой вопрос: кому вообще было разрешено совершить эту транзакцию в первую очередь? Именно это различие становилось всё более важным по мере того, как я углублялся в документацию.
В теории Newton пытается построить уровень авторизации, который находится между намерением пользователя и исполнением onchain. Вместо того чтобы полагаться только на приватные ключи или простые списки разрешений, он вводит программируемые политики, которые могут определять, когда действие разрешено, кто может его одобрить и какие условия должны быть выполнены перед исполнением. Долгосрочное видение шире, чем безопасность кошелька. Оно распространяется на AI-агентов, автоматизированные рабочие процессы и приложения, которым нужно гибкое принятие решений без передачи неограниченных полномочий.
Но вот в чём дело…
Интересная часть — не сама по себе идея. В том, как архитектура разделяет ответственность на несколько слоёв, вместо того чтобы просить один компонент делать всё.
Создание политик начинается с Rego — языка политик, который позволяет разработчикам выражать правила авторизации. Эти политики можно хранить в реестрах IPFS, чтобы они оставались адресуемыми по содержимому и независимо проверяемыми, а не прятались за централизованным сервером.
Исполнение отделено от оценки.
Когда запрос приходит, децентрализованные операторы, работающие через EigenLayer, вычисляют эти политики. Внешнюю информацию можно предоставлять через data-oracles на базе WASM, позволяя политикам учитывать условия реального мира, а не только состояние блокчейна. Если операторы приходят к одному и тому же выводу, они формируют BLS-аттестации, которые можно эффективно агрегировать ещё до того, как запрос попадёт в блокчейн.
Лишь тогда начинается применение.
Контракты проверяющего валидируют эти аттестации, а смарт-контракты PolicyClient определяют, может ли запрошенная транзакция действительно продолжиться. Иными словами, определение политики, её оценка и её применение — каждая из этих стадий живёт в разных частях системы, а не объединяется в единую точку доверия.
Такое разделение кажется намеренным.
Это уменьшает количество слепого доверия, возлагаемого на любого одного участника.
При этом есть важное отличие между архитектурным дизайном и живой верификацией.
Некоторые компоненты уже описаны достаточно ясно, чтобы понять их роль. Смарт-контракты, форматы политик и сценарии авторизации можно изучить. Другие части остаются ориентированными на будущее. Децентрализованная сеть операторов, эволюция управления, спрос, зависящий от комиссий, распределение вознаграждений, участие сообщества и в конечном итоге роль NEWT в стейкинге, делегировании и безопасности протокола — это всё ещё элементы, которые формируются, а не полностью зрелые системы.
Это не совсем критика.
Это просто то, как протокол, судя по всему, выглядит сегодня.
Управление тоже занимает интересное положение. Дорожная карта указывает на более широкое участие сообщества со временем: ожидается, что NEWT поддержит стейкинг, голосование и стимулы протокола. Однако остаются вопросы о том, как быстро полномочия смещаются от основной команды, как держатели токенов влияют на будущие решения и насколько прозрачен становится этот переход. Эти ответы важны, потому что системы авторизации в конечном итоге зависят от доверия к людям и процессам, которые формируют правила.
Хмм…
Сильнейшая сторона Ньютона, возможно, заключается не в какой-то отдельной технологии. Дело в многослойной философии дизайна. Политики Rego, хранилище IPFS, операторы EigenLayer, BLS-аттестации, контракт проверяющего и контракты PolicyClient — каждый из этих компонентов решает конкретную задачу, а не пытается стать одним универсальным источником истины.
Будет ли это устойчивой инфраструктурой, зависит меньше от элегантных диаграмм и больше от наблюдаемого исполнения.
Потому что в конечном счёте доверие не возникает от того, что политики просто существуют.
Она появляется тогда, когда любой может проверить, кто их написал, кто их оценил, кто их применил, и как эти ответственности постепенно становятся общими, а не контролируются кем-то одним. Возможно, именно этот вопрос в конечном счёте определит, станет ли Newton ещё одним протоколом или настоящим уровнем авторизации для onchain-систем.