Раньше, когда мы понимали взаимодействие в блокчейне, мы в основном обращали внимание на то, успешно ли прошла сама транзакция. Транзакция отправлена, подтверждение в блоке получено, активы изменились — этот процесс прост и прямолинеен. Но когда приложения начали усложняться, начали проявляться настоящие проблемы. За одной транзакцией может стоять несколько протоколов, одна стратегия может включать несколько шагов, а одна автоматизированная программа может требовать долгосрочной работы. В такой момент успешный результат не обязательно означает, что процесс действительно соответствовал изначальной цели.
Именно поэтому я позже и начал следить за Newton Protocol.
Многие, говоря о Newton, относят его к нарративу AI Agent или автоматизации, но, на мой взгляд, он решает гораздо более базовую задачу: как заставить автоматические действия в блокчейне работать по четко заданным правилам. Потому что вопрос будущего не в том, могут ли машины выполнять действия, а в том, понимают ли они границы, следуют ли условиям и могут ли доказать, что их поведение соответствует ожиданиям.
Ключевая конструкция в white paper Newton как раз и построена вокруг этого.
Предложенный им Authorization Layer — это не просто добавление кнопки разрешения, а создание слоя механизмов проверки правил между приложением и исполнением. Раньше смарт-контракты в основном решали вопрос «как исполняется код», а Newton хочет дополнить его вопросом «в каких случаях это следует исполнять».
Это различие очень важно.
В традиционной модели пользователь, авторизуя действие, обычно фактически передаёт приложению некую возможность. Но в сложных сценариях этого недостаточно. Стратегии автоматизации может потребоваться ограничение по сумме, системе управления активами — выполнение определённых условий, ончейн-программе — соблюдение заданной логики. Если все проверки жёстко зашиты внутри приложения, последующая настройка обойдётся очень дорого.
Policy Framework в Newton как раз и абстрагирует эти сложные условия в программируемые правила.
Это позволяет разработчикам определять разные типы логики исполнения, включая то, какие действия разрешены, какие ограничены, при каких условиях запускается операция и какие требования должны быть соблюдены в процессе исполнения. Так приложение уже не просто вызывает фиксированный контракт, а может комбинировать разные стратегии в зависимости от сценария.
Я считаю, что в этом и состоит главное отличие Newton от обычных инструментов автоматизации.
Он не просто помогает пользователю сократить число шагов, а пытается сформировать новый режим исполнения: чтобы система могла выполнять задачи в рамках заданных правил.
Это связано с дизайном Automation Intent.
Раньше взаимодействие в сети было больше похоже на то, как пользователь говорит системе: «Я хочу сделать вот такое действие». Например, обменять активы, перевести средства, вызвать какой-то протокол. Но в более сложных будущих сценариях пользователя может больше интересовать результат, а не каждый отдельный шаг.
Например, пользователь хочет, чтобы активы сохранялись в определённом состоянии, чтобы стратегия корректировалась в зависимости от рыночных изменений, чтобы какая-то задача работала автоматически длительное время.
В таком случае системе нужно понимать именно цель, а не отдельную команду.
Newton пытается через Intent дать пользователю возможность выразить цель, а затем, в сочетании с ограничениями Policy, направлять путь исполнения, чтобы процесс автоматизации лучше соответствовал заданной логике.
Конечно, после определения целей и правил возникает ещё один ключевой вопрос: как доказать, что процесс исполнения не отклонился от заданного пути.
Именно в этом заключается ценность Verifiable Automation в архитектуре Newton.
Благодаря Operator Network выполнение задач больше не полностью зависит от одного исполнителя, а формирует механизм координации и проверки. В сочетании с технологиями TEE и ZK система может не только обеспечивать доверенную среду исполнения, но и делать результаты проверяемыми.
Проще говоря, TEE решает проблему среды исполнения, позволяя вычислениям происходить в доверенных условиях; ZK решает проблему доказательства, позволяя системе доказать, что определённые результаты соответствуют требованиям, не раскрывая все детали.
Что мне кажется особенно интересным в этой конструкции, так это то, что Newton делает акцент не на том, чтобы «сделать автоматизацию быстрее», а на том, чтобы «сделать автоматизацию надёжнее».
Потому что когда в будущем on-chain-системы начнут работать в действительно крупном масштабе, эффективность, конечно, важна, но важна и надёжность.
С точки зрения рынка я считаю, что многие проекты сосредоточены на том, как создавать новые приложения, а Newton — на том, как обеспечить долгосрочную работу всё более сложных приложений. Такая инфраструктура обычно не привлекает внимание так быстро, как проекты прикладного уровня, но она решает более базовые задачи.
Конечно, Newton пока ещё нуждается в рыночной проверке. Архитектура в white paper — это лишь начало; по-настоящему важно, появится ли в будущем больше интеграций приложений, будут ли реальные сценарии использовать эти возможности и сможет ли вся сеть сформировать экосистему с устойчивой работой.
Что касается $NEWT, меня больше интересует не краткосрочное изменение цены, а то, сможет ли он стать базовым модулем в системе ончейн-автоматизации.
Раньше блокчейн решал проблему перевода активов, а смарт-контракты — проблему исполнения правил. Newton же исследует, как в мире, где всё больше задач автоматически выполняется системой, заставить эти действия постоянно двигаться к чётко определённой цели.
Если в будущем ончейн-мир действительно войдёт в стадию высокой автоматизации, то инфраструктура, способная связывать цели, правила и исполнение, может стать очень важным слоем.