Я потратил некоторое время на размышления о том, за что на самом деле отвечают @NewtonProtocol операторы, когда задача политики проходит через сеть.
Сначала ответ казался простым.
Операторы оценивают политику.
Они проверяют необходимые условия.
Они вносят подписи в итоговое доказательство.
Просто.
Но чем больше я смотрел на поток выполнения Ньютона, тем труднее становилось считать одобрение политики и операционную ответственность одним и тем же.
Потому что архитектура Ньютона, похоже, очень тщательно разделяет их.
Задача политики может пройти оценку.
Дальнейшее действие все еще может завершиться неудачей.
Это различие имеет гораздо большее значение, чем я сначала осознал(а).
Задокументированный процесс Ньютонa разделяет оценку политики и выполнение транзакции между несколькими компонентами. Операторы извлекают необходимые данные, выполняют оценку политики Rego и добавляют подписи BLS к агрегированному доказательству, подтверждающему, что вычисленные условия были выполнены.
Тогда PolicyClient может проверить агрегированное доказательство, прежде чем разрешить защищенную транзакцию или операцию продолжить выполнение.
На первый взгляд легко мысленно сжать весь этот поток в одну идею:
«Сеть одобрила действие».
Но такое framing тихо скрывает важную границу.
Сеть операторов оценивает, были ли выполнены заданные условия политики на момент оценки.
Она автоматически не берет на себя ответственность за все, что произойдет позже.
Это звучит очевидно, пока вы не проследите жизненный цикл выполнения более внимательно.
Дальнейший контракт все еще может откатиться.
Внешняя зависимость все еще может отказать.
Транзакция все еще может исчерпать газ.
Требуемый сервис может все еще временно стать недоступным.
Оценка политики может оставаться действительной, пока операционный результат где-то позже в цепочке выполнения все еще не сломается.
Бросилось в глаза не наличие отказа.
Распределенные системы всегда содержат границы отказа.
Бросилось в глаза то, где Ньютон, похоже, размещает ответственность за такие сбои.
Сеть политик доказывает, что операторы оценили заданный набор правил и коллективно согласились с результатом оценки.
Но операционная ответственность все равно частично остается в окружающей среде приложения, в реализации PolicyClient, в downstream-контрактах, в зависимостях инфраструктуры, предположениях выполнения и в логике, связывающей все это вместе.
Это создает более чистое разделение, чем я изначально ожидал(а).
Коллективная оценка не автоматически централизует операционную ответственность.
Я снова и снова возвращаюсь к этому различию.
Потому что современные инфраструктурные системы часто размывают эти границы вместе.
Пользователи видят одобренное действие и предполагают, что доверять полностью всему сквозному рабочему процессу теперь можно от начала до конца.
Но архитектура Ньютона, кажется, продумана аккуратнее, чем это.
Слой оценки доказывает, что заданные условия политики были выполнены во время оценки.
Она не гарантирует, что каждая downstream-зависимость, среда выполнения или внешняя система будет продолжать вести себя корректно после этого.
Это разные вопросы безопасности.
И честно говоря, их разделение в долгосрочной перспективе может быть более здоровым для инфраструктурных систем.
Поскольку как только оценка политики, среды выполнения, внешние зависимости и логика приложения начинают взаимодействовать непрерывно, притворяться, что у них одинаковые границы ответственности, может создать еще больше путаницы.
Особенно когда адаптивные системы начинают координировать действия быстрее, чем люди могут вручную проверять каждый операционный шаг в реальном времени.
Корректный результат политики все еще может попасть в нездоровую среду выполнения.
Корректно оцененная задача все еще может зависеть от ненадежной downstream-инфраструктуры.
Одобренная операция все еще может завершиться неудачей, потому что окружающие условия изменились после того, как произошла оценка.
Сеть может проверять условия.
Она не может “заморозить” реальность вокруг них.
Похоже, это одно из самых важных различий, скрытых внутри архитектуры Ньютона.
И это также меняет то, как ответственность, возможно, придется сообщать пользователям, которые строят поверх этих систем.
Поскольку консенсус по операторским оценкам может подтвердить, что политика была оценена корректно.
Это автоматически не объясняет, куда смещается операционная ответственность, когда выполнение выходит за границу оценки и переходит к более широкому жизненному циклу приложения.
Это не обязательно является недостатком.
Во многих отношениях это может быть более честная модель инфраструктуры.
Распределенная оценка политики может снизить предположения о доверии вокруг решений по авторизации, не притворяясь, что криптографическое согласие магически устраняет операционные риски из остальных частей системы.
Тем не менее, разделение создает важные вопросы по инфраструктуре.
Если зависимость внизу цепочки завершится неудачно после одобрения политики, как приложения должны объяснить это различие пользователям?
Где должна жить ответственность за повторные попытки?
Сколько операционного доверия все еще остается за пределами оцененной границы политики?
И когда автономные финансовые системы начнут непрерывно координировать действия в нескольких средах, пользователи ясно поймут, какой слой на самом деле дал сбой?
Архитектура Ньютона, похоже, отвечает на один вопрос очень внимательно:
были ли условия политики коллективно оценены и подтверждены.
Более сложный вопрос может начаться потом.
Куда именно фактически смещается операционная ответственность после того, как подтвержденное выполнение попадает в реальный мир?