сначала я думал, что в основном про программируемую комплаенс-проверку. Но после того, как я потратил больше времени на изучение архитектуры, я заметил, что стал меньше обращать внимания на отдельные политики и больше — на то, где эти политики реально находятся. Этот сдвиг изменил то, как я смотрю на протокол.

Дизайн разделяет авторизацию и выполнение приложения, вместо того чтобы встраивать бизнес-правила прямо в каждый смарт-контракт. Политики, написанные на Rego, определяют логику авторизации, тогда как отдельные приложения предоставляют свои собственные операционные ограничения через конфигурацию PolicyClient. Лимиты расходов, одобренные получатели, ограничения по юрисдикциям и подобные требования становятся структурированной конфигурацией времени выполнения, а не навсегда закодированной логикой политик.

Эта разница кажется более значимой, чем поначалу может показаться. Одна политика может оставаться повторно используемой, даже если разные приложения работают в разных границах авторизации, просто меняя конфигурацию. Политика описывает процесс принятия решения. Приложение предоставляет контекст. Эти обязанности намеренно независимы.

Но меня все продолжало что-то беспокоить.

Повторное использование работает только тогда, когда авторизация остается привязанной к точным предпосылкам, которые ее породили. Ньютон решает это, генерируя новый идентификатор политики всякий раз, когда меняется конфигурация PolicyClient. Аттестации, полученные при более ранней конфигурации, больше не применяются после изменения указанного идентификатора политики. Поэтому авторизация связывается не только с логикой политики, но и с точной конфигурацией, которая существовала на момент выдачи одобрения.

Дизайн меняет границу.

Вместо того чтобы изменять код приложения всякий раз, когда меняются операционные требования, разработчики корректируют политики или конфигурацию, сохраняя неизменной логику приложения. Это может упростить сопровождение сразу нескольких приложений, но при этом переносит ответственность в сторону управления политиками. Сама конфигурация становится частью модели безопасности, а не просто деталью развертывания. Внешняя информация добавляет еще один уровень ответственности. ПолитикаData Oracles выполняются как изолированные компоненты WASM, возвращая структурированные данные времени выполнения, которые политики оценивают детерминированно. Время выполнения намеренно ограничивает доступ к сети, а сбои обрабатываются по-разному в зависимости от того, где они произошли. Структурированные ошибки приложения остаются видимыми для оценки политикой, в то время как сбои выполнения становятся событиями DataProviderError, полностью останавливающими авторизацию, а не приводящими к обычному решению.

Это не устраняет доверие. Оно просто переносит его.

Истечение аттестации добавляет еще одно операционное решение. Короткие окна одобрения уменьшают возможности для повторного использования, в то время как более длинные окна дают пользователям больше гибкости перед выполнением. Ни один из вариантов — не «окна истечения», которые уравновешивают устойчивость к повтору и удобство. В конечном итоге пользователи взаимодействуют с аттестациями, действительность которых отражает и версию политики, и контекст выполнения, а не только состояние контракта.

Если смотреть на это с такой точки зрения, Ньютон выглядит менее сосредоточенным на замене логики смарт-контрактов, чем на переносе того места, где эволюционирует авторизация, по мере изменения требований приложения.

Перенос эволюции политик из развернутых контрактов упрощает долгосрочную безопасность или же просто создает иной уровень, где накапливается операционная сложность?

$NEWT #Newt $SUI $ETH