Несколько недель назад я одобрил(а) «лимит расходов» для yield-бота, который тестировал(а) на мейннет-контракте, находящемся рядом с тестнетом. Всё стандартно: кликнул(а) approve, и пошёл(ла) дальше по своим делам. За исключением того момента, когда я вернулся(лась) проверить: оказалось, что это был вовсе не лимит расходов. Это было неограниченное разрешение (allowance). Бот никогда не злоупотреблял этим. Ничего плохого не произошло. Но я сидел(а) и смотрел(а) на это одобрение и понял(а), что в ту секунду, когда нажал(а) «confirm», я вообще не имел(а) представления, что именно только что разрешил(а). Транзакция выполнилась. Проверить, стоило ли ей выполняться, по сути, никто не проверял.
Этот небольшой, слегка неловкий момент в итоге и стал основной причиной, почему я начал уделять Newton Protocol более пристальное внимание.
Большинство людей, которых я видел, описывают приземление Newton в той же рамке: «это протокол для ИИ-агентов». Агенты торгуют за вас, ребалансируют за вас, делают для вас всю DeFi-рутинную работу, а Newton следит за тем, чтобы это было «проверяемо» и «безопасно». Это не неверно, но это лишь поверхность. Если смотреть только так, в итоге начинаешь сравнивать Newton со всеми остальными проектами в нише «ИИ + крипто» из лидерборда, споря о том, чьи агенты умнее или быстрее.
Вот какая часть наконец «щелкнула» для меня: Newton на самом деле не продаёт агентов. Он продаёт отсутствие.
Почти любая система автоматизации в крипто сегодня — боты, сейфы, агенты, что угодно — работает примерно так же, как и моя. Запрашивается действие, а затем цепочка просто выполняет его, потому что так работают смарт-контракты: они запускают переданный им код. У цепочки нет понятия «подождите, это тот тип действия, который этому кошельку разрешено?» Этот оценочный момент, если он вообще существует, живёт вне цепочки — обычно в UI-предупреждении, которое вы, скорее всего, просто пропустили.
Фактическая ставка инфраструктуры Newton — перенести этот оценочный момент on-chain и поставить его до расчёта, а не после. Используя определения политик, построенные на стандарте OPA/Rego — на той же открытой исходной среде, которую многие команды облачной инфраструктуры уже используют для контроля доступа, разработчики и пользователи могут писать явные правила о том, что агент, бот или контракт имеет право делать. Эти правила исполняются децентрализованной сетью операторов, обеспеченной restaking на EigenLayer, поэтому решение в формате «да/нет» не сидит на сервере одной компании. Это распределённая проверка политики, которая должна пройти, прежде чем транзакция вообще будет разрешена к расчету.
Это действительно другая категория, чем «более умные ИИ-агенты». Скорее это похоже на on-chain-слой разрешений — что-то вроде OAuth или ролей IAM, концепций, которые уже обеспечивают половину бэкенд-инфраструктуры интернета, только применённых к кошелькам и смарт-контрактам вместо приложений и API. Сюда добавляются TEE и доказательства с нулевым разглашением: агент может доказать, что он действовал в рамках правил, не раскрывая приватную логику, лежащую в основе решения.
Распространённое предположение состоит в том, что риск в on-chain-автоматизации — это агент: он глупый, им манипулируют, он злонамеренный. То, что я наблюдал в собственном «разборе полётов» с моими разрешениями, на самом деле другое: риск находится раньше. Он в разрыве между «что я имел в виду, когда хотел разрешить» и «что цепочка фактически позволит сделать». Инфраструктура Newton направлена прямо на этот разрыв, а не на то, чтобы сделать агента умнее.
Я скажу прямо о своём сомнении: принудительное применение политики до транзакции имеет значение только если люди реально настраивают свои политики, а большинство пользователей не задумываются о разрешениях, пока не случится что-то плохое. По крайней мере, я не задумывался — пока это почти не произошло. Ворота полезны только тогда, когда кто-то потрудился задать на них правила. Насколько строители и обычные пользователи будут внедрять детальные политики в стиле Rego, а не просто кликать «разрешить всё» так, как мы кликаем через баннеры cookie, — пока для меня абсолютно неясно.
Я также сомневаюсь, что это уже можно назвать закреплённым преимуществом над конкурентами. Децентрализованные проверки политики через сеть AVS звучат убедительно на бумаге, но любой дополнительный этап верификации перед расчётом — это тоже дополнительная задержка и дополнительная площадь атаки для того, чтобы что-то пошло не так со стороны оператора. Мне не хватило реальных данных по пропускной способности, чтобы понять, как этот компромисс проявляется под нагрузкой.
Ничто из этого не является сигналом купить NEWT или любой другой токен, и это не финансовый совет — хорошо спроектированная инфраструктура не автоматически конвертируется в ценовую динамику, и множество хорошо сделанных протоколов в коммерческом плане никуда не пришли. Если идея уровня разрешений для on-chain-автоматизации вам интересна, стоит прочитать собственную документацию Newton про policy engine и составить своё мнение. Я всё ещё формирую своё — честно говоря, в основном потому, что я до конца не простил себе ту безлимитную выдачу разрешений.