Что, если транзакция могла бы доказать, что соответствует вашим правилам, еще до того, как ваш смарт-контракт вообще к ней прикоснется?
@NewtonProtocol продолжает продвигать идею о том, что авторизация должна происходить до выполнения, а не после. Это звучит незначительно, но меняет то, где разработчики размещают доверие. Вместо того чтобы помещать каждое условие прямо в контракт, Ньютон позволяет политике решать, заслуживает ли транзакция того, чтобы продвинуться дальше.
Практическое противоречие $UP
Большинство смарт-контрактов остаются неизменными после развертывания.
Бизнес-правила не соблюдаются.
Лимит расходов меняется. Изменяется требование соответствия. Меняется статус кошелька. Каждый раз обновлять Solidity — медленно и дорого. Ньютон подходит к этому иначе: отделяет правила транзакций от логики контракта.
Что выделяется
•Факт: Newton оценивает намерения транзакций до выполнения через workflow политики, а не проверяет все внутри Solidity.
•Факт: Политики могут использовать внешнюю информацию, предоставляемую через оракулы данных WebAssembly (WASM), прежде чем принять решение.
•Факт: Операторы возвращают криптографические аттестации, которые перед выполнением подтверждаются on-chain компонентом PolicyClient.
•Мнение: Интересная часть — не в языке политики. А в том, чтобы уменьшить количество причин, по которым контракту нужно повторно развертываться, когда меняются бизнес-правила.
Одно наблюдение, к которому я постоянно возвращаюсь
#Newt не пытается сделать контракты более сложными.
Он пытается сделать их менее ответственными.
Контракт в основном проверяет аттестацию. Само решение уже было оценено в другом месте на основе заранее заданных правил.
Это создает более чистое разделение между выполнением и авторизацией.
Станет ли это преимуществом — зависит от приложения.
Цифры, на которые стоит обратить внимание
•Примерно 30 минут, чтобы собрать WASM-оракул данных.
•Примерно 20 минут, чтобы написать политику Rego.
•Примерно 15 минут на развертывание через CLI.
•Примерно по 30 минут на интеграцию смарт-контракта и интеграцию frontend SDK.
Это оценки из документации, а не гарантии. В реальных проектах обычно требуется больше времени в зависимости от тестирования и проверок безопасности.
Evtakeaway
•Newton позволяет разработчикам развертывать политики отдельно от контрактов.
•Newton поддерживает внешние входные данные при оценке политики.
•Newton проверяет аттестации, подписанные BLS, в сети перед выполнением.
•Развертывание политики в основной сети требует белого списка (allowlisting), а не полностью безразрешительного (permissionless) развертывания.
Эти детали предполагают, что Newton ожидает, что инфраструктура авторизации будет критичной для продакшена, а не необязательной функцией.
Почему, на мой взгляд, Newton становится интересным
Представьте казначейство с ежедневным лимитом на переводы.
Завтра совет принимает решение об изменении лимита.
Без Newton разработчикам, возможно, придется пере развертывать контракты или добавлять сложность в управление.
С Newton изменения политики происходят, пока контракт выполнения остается тем же.
Это не убирает управление.
Это меняет то, где происходит управление.
Небольшое различие.
Потенциально важное по смыслу.
Что я бы проверил перед тем, как строить на Newton
•Откуда на самом деле берутся внешние данные?
•Кто управляет источником данных?
•Как часто обновляется эта информация?
•Может ли логика политики изменяться, не затрагивая существующие допущения?
•Кто контролирует обновления политики?
•Насколько просто проводить независимый аудит аттестаций?
•Получала ли реализация PolicyClient независимые проверки безопасности?
•Что будет, если оценка политики станет временно недоступной?
Эти вопросы важнее того, кажется ли SDK удобным.
Риски, которые стоит держать в поле зрения
•Риск смарт-контракта: Даже если Newton корректно валидирует аттестации, контракт(ы) приложения все равно могут содержать ошибки реализации.
•Риск внешней зависимости: решения по политике опираются на off-chain оценку и доступность данных. Если поддерживающая инфраструктура выходит из строя, авторизация транзакций может быть задержана.
•Операционный риск: Управление обновлениями политики становится важным допущением безопасности.
•Оценки по документации: Времена интеграции — это ориентиры, а не сроки производственного запуска.
Сбалансированные конструкции редко устраняют риск.
Обычно они переносят это в другое место.
Мой вывод $ARX
$NEWT похоже меньше на еще один набор инструментов для смарт-контрактов и больше на попытку отделить того, кто принимает решения, от того, кто выполняет. Такое разделение может упростить некоторые приложения, но при этом привнести новые операционные допущения. Стоит ли такой компромисс того — вероятно, зависит меньше от самого Newton и больше от того, насколько ваш проект ожидает, что его правила авторизации будут меняться после развертывания. Вот эту часть я бы продолжал внимательно отслеживать.