Я потратил некоторое время на чтение руководства по обновлению протокола Newton и снова и снова возвращался к одному важному моменту: новые переменные хранилища всегда добавляются к существующей структуре хранилища, вместо того чтобы вставляться в неё
Звучит почти тривиально
Я не думаю, что это так. Я видел, как обновляемые контракты ломались из-за того, что кто-то недооценил структуру хранилища. Обновление через прокси проходит — тесты выглядят нормально — а затем через несколько недель кто-то обнаруживает, что переменная была перезаписана, потому что изменился порядок хранения. Это настоящий беспорядок. Контракт не обязательно ломается сразу. Иногда он просто начинает вести себя иначе, что гораздо сложнее диагностировать
Протокол Newton избегает этой ловушки, рассматривая макет хранения как то, что нужно сохранять, а не перестраивать. Мне нравится такой подход, потому что он учитывает хрупкость обновляемых прокси
Ещё одна деталь, которая бросилась в глаза, — флаг newtonPolicyClientInitialized. Его назначение простое. Пост-обновлённая инициализация может произойти только один раз. Протокол Newton также рекомендует тестировать обновления на форке и использовать timelock или multisig при выполнении транзакции инициализации. Мне это не показалось заготовленным советом. Скорее это выглядело как признание того, что обновление ещё не завершено, когда развёрнута новая реализация. Инициализация является частью процесса обновления
Пока этот шаг не будет завершён, логика авторизации может уже существовать внутри контракта, но policy client всё ещё не подключён к правильному TaskManager или не назначен предполагаемому владельцу policy-client. Если хотя бы одно из этих значений неверное, слой авторизации может не сработать, даже несмотря на то, что само развертывание выглядело успешным
Вот почему я считаю, что одноразовый флаг инициализации действительно важен
Это предотвращает повторный запуск инициализации кем-то, но не защищает от ошибки при первом выполнении. Если в начальной конфигурации есть недочёты, то «запереть» их за одноразовым флагом не помогает магически. Это лишь делает первое выполнение одним из самых чувствительных моментов во всём развертывании. Я также заметил, что протокол Newton не замораживает навсегда каждую конфигурацию после инициализации. Владелец policy client по-прежнему может обновлять настройки политики, менять адрес контракта политики и позже передавать владение. Я на самом деле предпочитаю это тому, чтобы притворяться, будто системам никогда не потребуется меняться. Изменения инфраструктуры. Изменения в управлении. Требования меняются. Задача — убедиться, что эти разрешения остаются хорошо контролируемыми со временем
Совместимость по хранению создаёт совершенно другую категорию риска. Одна вещь, которую я ценю в протоколе Newton, — это то, что он позволяет командам внедрять принудительное соблюдение политики, не перестраивая их приложение с нуля. Это практичный выбор дизайна. Но при этом обновление прокси всё равно должно идеально сохранять совместимость по хранению. Вставьте одну переменную не на то место — и слой авторизации может выглядеть полностью здоровым, в то время как связанное состояние приложения незаметно и тихо будет повреждено
Я видел достаточно обновляемых систем, чтобы понимать, что это не надуманная проблема. Ещё одна деталь, на которую, как мне кажется, не стоит не обращать внимания — это поток выполнения. Добавление новой защищённой Newton функции не означает автоматически, что более старая функция, которая выполняет то же действие, тоже будет защищена. Каждый путь, который должен обеспечивать авторизацию, всё равно должен вызывать validateAttestation или validateAttestationDirect до запуска защищённой бизнес-логики. Пропустите один путь выполнения — и вы создадите несогласованные гарантии безопасности, даже не осознавая этого
Наверное, именно это я нашёл самым интересным в протоколе Newton
Архитектура разделяет NewtonPolicyClient и бизнес-логику приложения, вместо того чтобы заставлять разработчиков переделывать всё вокруг нового фреймворка. Я в целом предпочитаю такой модульный подход, потому что большие системы редко переписывают с нуля — они развиваются шаг за шагом, через каждое отдельное обновление
В то же время. Я всё время думаю, исчезает ли вообще этот риск
Или просто ли он перемещается
Протокол Newton делает авторизацию проще для интеграции в существующие обновляемые контракты. Я думаю, это действительно ценно. Но это также означает, что обновление прокси, миграция хранения и самый первый вызов инициализации становятся точками, где сосредоточен почти весь операционный риск
Я не вижу в этом слабости дизайна. Я воспринимаю это как напоминание о том, что хорошая архитектура не устраняет сложные решения — обычно она лишь делает их легче распознать
#NEW $NEWT @NewtonProtocol #Newt
Каждое обновление меняет код, но не каждое обновление усиливает безопасность. Для меня протокол Newton показывает, что самые маленькие детали реализации часто оказывают наибольшее влияние на построение устойчивых смарт-контрактов
#GillibrandCallsForDigitalAssetEthicsBan #NHHB639ProtectsDigitalAssetSelfCustody #BitcoinReboundsAbove$61K