Когда я только начал разбираться в программируемой авторизации, я предположил, что изменение правила означает изменение смарт-контракта, который его обеспечивает. Казалось, это неизбежно.
Если бы хранилище снизило свою максимальную подверженность, добавило ограниченный адрес, изменило приемлемый риск-показатель или ввело новое условие соответствия, то контракт, защищающий хранилище, наверняка пришлось бы переписать и развернуть заново.
Чем больше я разбирался в @NewtonProtocolMainnet Beta, тем сильнее начинало казаться, что это предположение неверно. Newton разделяет приложение, которое защищают, и политику, определяющую, что этому приложению разрешено делать.
Как политика Newton оценивает намерение транзакции
Политика Newton оценивает намерение транзакции, используя три разных типа информации:
Сама транзакция
Настраиваемые значения под "data.params
Живая информация, возвращаемая оракулами данных под "data.wasm"
Поэтому политика может сравнивать одно и то же запрошенное действие с меняющимися порогами, allowlist, результатами идентичности, ценами или сигналами риска, не помещая всю эту логику напрямую в контракт приложения.
Что остается постоянным?
Такое различие звучит технически. На самом деле оно меняет то, что должно оставаться постоянным.
Граница принуждения может оставаться подключенной к приложению, пока правила за этой границей продолжают развиваться. Собственная документация Newton описывает политики как обновляемые без требования повторно разворачивать защищенный контракт, а анонс Mainnet Beta приводит примеры вроде измененного порога или нового требования к санкциям, которые вступают в силу без переписывания контракта приложения.
Меня привлекло то, что Newton на самом деле не выбирает между неизменяемым кодом и гибкой политикой. Он пытается дать каждому из них свою задачу:
Контракт приложения: определяет, где должна происходить авторизация.
Политика: определяет, какие условия должны быть выполнены в данный момент.
Данные оракула: могут отличаться для каждой транзакции.
Но оракул, политика и смарт-контракт не обязательно должны меняться одновременно. Сам смарт-контракт может оставаться на месте годами. Порог риска может измениться в следующем месяце. Результат по санкциям или сигнал о состоянии рынка может измениться до прихода следующей транзакции. Если захардкодить все три в один и тот же контракт, самая медленная часть системы возложит ответственность за информацию, которая меняется гораздо быстрее.
Newton разъединяет их. Это может быть важнее, чем сначала кажется.
Более точная проблема управления
В традиционном дизайне смарт-контрактов расширяемость часто рассматривают как проблему уровня контракта. Либо контракт фиксирован, либо у кого-то есть разрешение на его обновление.
Newton вводит еще один уровень между этими двумя выборами. Защищенное приложение может оставаться стабильным, пока условия авторизации вокруг конкретных действий корректируются отдельно.
Так что вопрос перестает быть таким: можно ли обновить этот контракт?
И становится таким вопросом: какие части процесса авторизации могут меняться, кто контролирует эти изменения и какие части остаются постоянно связанными с исполнением?
Это гораздо более точная проблема управления.
Компромисс гибкости
Гибкость не всегда означает больше безопасности. Политика, обновляющаяся быстро, может адаптироваться к новым законам, изменениям на рынке или угрозам безопасности. Но она также может изменить правила, которые пользователи изначально приняли.
Снижение лимита риска может защитить капитал.
Тихое расширение allowlist или ослабление требования безопасности может дать противоположный эффект.
Опасность не исчезает только потому, что политика отделена от контракта; она смещается в сторону управления политикой.
Кому разрешено обновлять параметры?
Насколько заметно изменение?
Могут ли пользователи изучить политику, которая сейчас защищает приложение?
Понятны ли предыдущие версии после того, как их заменит новая?
Эти вопросы становятся не менее важными, чем сама логика Rego. Именно к этой части я снова и снова возвращаюсь.
Вывод: постоянство принуждения
Newton не делает финансовые правила постоянными. Требования реального соответствия, уровни допустимого риска и условия безопасности меняются слишком часто, чтобы это было реалистично.
То, что он пытается сделать постоянным, — это требование, чтобы защищенные действия всегда проходили авторизацию
Правило может измениться
Данные могут меняться.
Порог может измениться.
Но приложение не получает возможности тихо перестать запрашивать разрешение.
Для меня это более интересная форма согласованности, чем бесконечное хардкодирование всех правил. Ньютон не замораживает политику «навсегда». Он фиксирует точку, где политика должна иметь значение.
