#newt $NEWT @NewtonProtocol #Newt
i раньше думал, что политики протокола — это по сути статичные справочники правил. Загрузил один раз, проверил один раз — и всё. Чем больше я читал про Newton Protocol, тем сильнее понимал, что это предположение было совсем не точным.
Меня особенно заинтересовало то, как Newton Protocol разделяет повторно используемую логики политик Rego и динамическую конфигурацию, прикреплённую к PolicyClient. Вместо того чтобы переписывать код политик для каждого сценария, одну и ту же логику можно переиспользовать, а параметры вроде порогов, лимитов экспозиции и утверждённых allowlist передаются через data.params в виде плоского JSON.
Это напомнило мне о простом из реальной жизни. Моя семья использует одни и те же правила дома для всех, но у моего младшего двоюродного брата лимиты другие, чем были у меня в таком же возрасте. Правила не менялись. Менялась конфигурация. Принцип оставался неизменным, а границы адаптировались.
Newton следует похожей философии, но с гораздо более жёсткими гарантиями. Одна деталь, которая показалась мне особенно интересной — expireAfter. Она задаёт окно исполнения блока для аттестации, а не момент, когда сами параметры «истекают». Сделай слишком коротко — и валидные исполнения могут не пройти, потому что окно закрывается слишком быстро. Сделай слишком долго — и возрастает риск повторного воспроизведения (replay) или отложенного исполнения. Ни один вариант автоматически не является правильным. Важен контекст.
Ещё одно тонкое дизайнерское решение: обновление параметров через setPolicy(PolicyConfig) создаёт совершенно новый policyId. Предыдущая конфигурация сразу становится устаревшей, создавая чёткую границу между старым и новым состояниями политики вместо того, чтобы молча менять допущения о доверии.
Мой главный вывод был не про гибкость. Он был про ответственность. Rego задаёт логику, но параметры определяют люди — их нужно проверять, и в конечном итоге именно они формируют результат.
Так где рецензентам стоит уделять больше всего внимания: повторно используемому коду политик или настройкам, скрытым внутри data.params? Эта архитектура делает правила безопасно переиспользуемыми или же переносит самые важные допущения о доверии в конфигурации, которые многие пользователи не будут проверять?
i раньше думал, что политики протокола — это по сути статичные справочники правил. Загрузил один раз, проверил один раз — и всё. Чем больше я читал про Newton Protocol, тем сильнее понимал, что это предположение было совсем не точным.
Меня особенно заинтересовало то, как Newton Protocol разделяет повторно используемую логики политик Rego и динамическую конфигурацию, прикреплённую к PolicyClient. Вместо того чтобы переписывать код политик для каждого сценария, одну и ту же логику можно переиспользовать, а параметры вроде порогов, лимитов экспозиции и утверждённых allowlist передаются через data.params в виде плоского JSON.
Это напомнило мне о простом из реальной жизни. Моя семья использует одни и те же правила дома для всех, но у моего младшего двоюродного брата лимиты другие, чем были у меня в таком же возрасте. Правила не менялись. Менялась конфигурация. Принцип оставался неизменным, а границы адаптировались.
Newton следует похожей философии, но с гораздо более жёсткими гарантиями. Одна деталь, которая показалась мне особенно интересной — expireAfter. Она задаёт окно исполнения блока для аттестации, а не момент, когда сами параметры «истекают». Сделай слишком коротко — и валидные исполнения могут не пройти, потому что окно закрывается слишком быстро. Сделай слишком долго — и возрастает риск повторного воспроизведения (replay) или отложенного исполнения. Ни один вариант автоматически не является правильным. Важен контекст.
Ещё одно тонкое дизайнерское решение: обновление параметров через setPolicy(PolicyConfig) создаёт совершенно новый policyId. Предыдущая конфигурация сразу становится устаревшей, создавая чёткую границу между старым и новым состояниями политики вместо того, чтобы молча менять допущения о доверии.
Мой главный вывод был не про гибкость. Он был про ответственность. Rego задаёт логику, но параметры определяют люди — их нужно проверять, и в конечном итоге именно они формируют результат.
Так где рецензентам стоит уделять больше всего внимания: повторно используемому коду политик или настройкам, скрытым внутри data.params? Эта архитектура делает правила безопасно переиспользуемыми или же переносит самые важные допущения о доверии в конфигурации, которые многие пользователи не будут проверять?