Я потратил некоторое время на чтение руководства по обновлению протокола Newton и снова и снова возвращался к одной детали реализации: новые переменные хранилища всегда добавляются в существующую структуру хранилища вместо того, чтобы вставляться в неё.
Похоже почти тривиально
Я так не думаю
Я видел, как обновляемые контракты ломались из-за того, что кто-то недооценил структуру хранилища. Обновление через прокси проходит тесты, всё выглядит нормально, а затем спустя недели кто-то обнаруживает, что переменная была перезаписана, потому что изменился порядок хранения. Это беспорядок. Контракт не обязательно выходит из строя сразу. Иногда он просто начинает вести себя иначе — а это намного сложнее диагностировать.
Протокол Newton избегает этой ловушки, относя разметку хранилища к тому, что нужно сохранять, а не перестраивать. Мне нравится этот подход, потому что он учитывает хрупкость апгрейдируемых прокси
Ещё одна деталь, которая бросилась в глаза, — флаг newtonPolicyClientInitialized. Его назначение простое: пост-апгрейд инициализация может произойти только один раз. Протокол Newton также рекомендует тестировать апгрейды на форке и использовать timelock или multisig при выполнении транзакции инициализации. Для меня это не похоже на шаблонный совет. Это звучало как признание того, что апгрейд не завершён в момент, когда новая реализация уже развёрнута
Инициализация — часть апгрейда
Пока этот шаг не будет завершён, логика авторизации может быть уже встроена в контракт, но клиент политик всё ещё не подключён к правильному TaskManager или не назначен предполагаемому владельцу policy-client. Если одно из этих значений будет неверным, слой авторизации может не сработать, даже если само развёртывание выглядит успешным
Вот почему я думаю, что важен флаг одноразовой инициализации
Это не даёт кому-то запустить инициализацию ещё раз, но не защищает от ошибки в первом выполнении. Если в исходной конфигурации есть ошибки, то сокрытие её за одноразовым флагом не исправляет их “волшебным образом”. Оно лишь делает первое выполнение одним из самых чувствительных моментов во всём развёртывании
Я также заметил, что Протокол Newton не замораживает навсегда каждую конфигурацию после инициализации. Владелец policy client всё ещё может обновлять настройки политики, менять адрес контракта политики и позже передавать право собственности. Я даже предпочитаю это подходу, где притворяются, что системам никогда не нужно развиваться. Изменения инфраструктуры. Изменения в управлении. Изменяются требования. Сложность — убедиться, что эти разрешения со временем остаются хорошо контролируемыми. Совместимость с хранилищем создаёт совершенно другую категорию риска
Одна вещь, которую мне нравится в Протоколе Newton, — он позволяет командам внедрять принудительное применение политик без того, чтобы перестраивать своё приложение с нуля. Это практичный выбор дизайна. Но апгрейд прокси всё равно должен идеально сохранять совместимость с хранилищем. Вставьте одну переменную не в то место — и слой авторизации может выглядеть полностью здоровым, в то время как несвязанное состояние приложения тихо будет повреждено под капотом
Я видел достаточно систем с апгрейдами, чтобы знать, что это не гипотетическая проблема
Еще одна деталь, которую, я думаю, нельзя упускать, — это поток выполнения. Добавление новой защищённой функции Newton не обеспечивает автоматически безопасность более старой функции, выполняющей то же действие. Каждый путь, который должен обеспечивать авторизацию, всё равно должен вызывать validateAttestation или validateAttestationDirect до того, как начнётся защищённая бизнес-логика. Если вы пропустите хотя бы один путь выполнения, вы создадите несогласованные гарантии безопасности, даже не осознавая этого
Наверное, именно это я нашёл самым интересным в Протоколе Newton
Архитектура разделяет NewtonPolicyClient
вместо того чтобы заставлять разработчиков переделывать всё вокруг нового фреймворка. Я в целом предпочитаю такой модульный подход, потому что крупные системы редко переписываются с нуля. Они развиваются — один апгрейд за другим
При этом. Я всё время задаюсь вопросом, действительно ли этот риск исчезает
Или просто переносится
Протокол Newton делает авторизацию проще для интеграции в существующие контракты, поддерживающие апгрейды. Я считаю это ценным. Но это также означает, что апгрейд прокси, миграция хранилища и самый первый вызов инициализации становятся теми точками, где сосредоточены почти все операционные риски
Я не считаю это слабым местом дизайна
Я воспринимаю это как напоминание о том, что хорошая архитектура не устраняет сложные решения. Она обычно делает их проще заметить
Каждый апгрейд меняет код, но не каждый апгрейд усиливает безопасность. Для меня Протокол Newton показывает, что именно самые небольшие детали реализации часто оказывают наибольшее влияние на построение устойчивых смарт-контрактов