После проведения исследования того, как децентрализованный протокол может снизить риск актуальных обновлений времени выполнения, я пришёл к выводу, что самая критическая уязвимость в децентрализованных смарт-контрактах — это возможность для третьей стороны изменять активные правила через ключи управления. Вот как Newton Protocol по замыслу решает именно эту проблему способом, не требующим переписывать целиком систему бэкенда.
Одной из фундаментальных проблем, связанных с бессрочно разрешённой ончейн-автоматизацией, является возможность со временем обновлять правила игры. Если контракт управления или мультисиг-аккаунт, отвечающий за принятие этих решений, действует недобросовестно и изменяет ограничения времени выполнения, это создаёт «вектор обновления политики» для атаки.
Например, злоумышленник, имеющий доступ к такой учетной записи, может увеличить лимит расходов прямо перед тем, как транзакция пройдет, или ослабить некоторые механизмы контроля соответствия. Протокол Newton смягчает этот вектор атаки, требуя, чтобы переходы состояния были подписаны криптографическим доказательством, связывающим их с конкретным историческим корневым состоянием.
Чтобы понять, почему это решение необходимо, нужно обсудить проблему, которую Newton пытается решить. Любая система, которая требует от оператора обновлять политики в режиме реального времени, сталкивается с серьезной проблемой масштабируемости из-за огромного числа возможных переходов состояния. Например, каждый раз, когда оператор хочет изменить что-то, система должна убедиться, что корректность нового состояния соответствует ограничениям всех предшествующих состояний. Это может оказаться чрезвычайно обременительным для сети, если предложение содержит целую серию сложных пограничных случаев. Этого накладного расхода можно избежать с помощью Newton, используя корень состояния: каждое изменение политики фиксируется как единая атомарная операция, которая проверяется сетью с помощью проверки Linear Temporal Logic. Идея состоит в том, что вместо того, чтобы спрашивать у сети, является ли новый код корректным или нет, вы просите ее проверить набор конкретных изменений как логическое продолжение текущего корневого состояния.
Когда предложение об изменении правила или обновлении политики рассылается по сети, валидаторы начинают процесс агрегирования подписей, который позволяет им определить, есть ли достаточная поддержка для принятия новых правил. Если переход корректен, это означает, что большинство валидаторов одобряет изменение, и оно будет добавлено в блокчейн как новое корневое состояние при ближайшей доступной возможности.
С другой стороны, если узлы-валидаторы не могут успешно выполнить переход из-за недостаточного количества подписей или математических несоответствий с существующим корневым состоянием, обновление будет откатено. По сути, любые изменения в системном контракте, которые не проходят строгую криптографическую проверку, отклоняются сразу же, не допуская атак с недобросовестным flash-governance, которые пытаются временно ослабить ограничения, а затем вернуть их на место.
Требуя, чтобы каждое изменение в системном контракте включало подписанный переход от текущего корневого состояния, Newton предотвращает атаки, направленные на подрыв целостности разрешенных on-chain систем. В этой модели разработчикам не нужно встраивать расширенные меры безопасности непосредственно в основной контракт, чтобы обеспечить надежность предложений по управлению. Вместо этого они могут сосредоточиться на создании эффективных, детерминированных смарт-контрактов, а более волатильные ограничения обрабатываются отдельно — в виде обновлений политик.
