Когда я впервые столкнулся с Newton Protocol, мне показалось, что это в первую очередь очередной криптопроект, ориентированный на автоматизированную торговлю.
Это было моё первое впечатление.
Я всё время натыкался на термины, связанные с этим: например, финансовые агенты, программируемые разрешения, защищённая инфраструктура, rollup-технологии и ончейн-маркетплейс. Идея звучала интересно, но при этом казалась слишком широкой. Я не мог сразу понять, что именно Ньютон на самом деле создавал и какая часть проекта была наиболее важной.
Поэтому я начал копать глубже.
Я изучил его документацию, открытые репозитории, структуру токена и более свежие обновления проекта. Пока я читал, моё понимание постепенно менялось.
Сначала я думал, что Ньютон в основном предназначен для того, чтобы помогать автоматизированным системам торговать, управлять портфелями и выполнять финансовые задачи. Позже я понял, что его более важная цель — контролировать то, что этим системам разрешено делать.
Это различие стало главной причиной, почему я счёл проект достойным изучения.
Автоматизация в крипто уже распространена. Боты могут размещать сделки, хранилища могут перемещать средства между стратегиями, кредитные платформы могут управлять залогом, а смарт-аккаунты могут выполнять транзакции без того, чтобы кто-то вручную одобрял каждый шаг.
Это может быть полезным.
Это также может быть опасно.
Если я дам сервису разрешение использовать мои средства, как мне убедиться, что он останется в пределах тех ограничений, которые я задумал?
Обычные права кошелька могут быть слишком широкими. Я могу захотеть, чтобы сервис ребалансировал часть моего портфеля, но не всё, что у меня есть. Я могу разрешить ему торговать несколькими выбранными токенами, но не взаимодействовать с незнакомыми контрактами. Я могу захотеть, чтобы он останавливался после достижения дневного лимита убытков или приостанавливался, когда рынок становится нестабильным.
Приватный ключ не понимает всего этого.
Это лишь доказывает, что у кого-то или чего-то было разрешение подписать транзакцию. Оно не знает, почему это разрешение было выдано. Оно не понимает границы, которые, как предполагалось, должны были сопровождать это разрешение.
Ньютон пытается решить эту проблему, добавляя программируемые правила до того, как транзакция будет завершена.
Самый простой способ, который я нашёл, чтобы понять проект, — рассматривать его как контрольно-пропускной пункт разрешений (permission checkpoint).
Прежде чем защищённая транзакция будет пропущена, Ньютон может проанализировать предлагаемое действие и сравнить его с политикой. Эта политика может включать лимиты расходов, одобренные активы, доверенные адреса, требования к идентичности, рыночные условия, проверки комплаенса или предупреждения о безопасности.
Если транзакция следует правилам, её можно одобрить.
Если это нарушит их, то транзакцию можно отклонить до того, как средства переместятся.
Мне это показалось гораздо более практичным, чем просто называть Ньютон платформой для автоматизированных финансов. Сама по себе автоматизация — не самая сложная часть. Более сложная проблема — убедиться, что автоматизированная система не сможет действовать за пределами полномочий, которые ей были выданы.
Я представил себе простой пример, пытаясь понять, как Ньютон может работать на практике.
Допустим, я управляю казначейским кошельком и использую автоматизированный сервис для рутинных платежей. Я могу быть готов разрешить этому сервису вести регулярные расходы, но я всё равно хочу ограничения.
Ни один платёж не должен превышать определённую сумму.
Ежедневные траты должны иметь лимит.
Следует использовать только выбранные токены.
Платежи должны поступать только на одобренные адреса.
Транзакции с участием помеченных кошельков должны отклоняться.
Сервис должен остановиться, когда поставщик безопасности сообщает о необычном риске.
Платёжная система всё равно могла бы выполнять свою работу, но при этом у неё не было бы неограниченного контроля.
Это та часть, которая показалась мне наиболее интересной.
Ньютон — это не только про предоставление доступа. Это про предоставление доступа при определённых условиях.
Процесс начинается с того, что Ньютон называет intent (намерением). Intent — это описание того, что приложение хочет сделать. Он может включать отправителя, получателя, сумму, блокчейн-сеть, адрес контракта и вызываемую функцию.
Затем этот запрос проверяется относительно политики.
Некоторые правила можно оценивать, используя информацию, уже включённую в транзакцию. Другие правила могут зависеть от внешних данных, таких как списки санкций, рыночные цены, результаты по идентичности, отчёты proof-of-reserve, сигналы о мошенничестве или скоринги безопасности.
Операторы Ньютон оценивают запрос и формируют решение.
Когда запрос одобрен, система может создать криптографическую аттестацию. Принимающий смарт-контракт может проверить эту аттестацию перед тем, как завершить действие.
Эта часть выделялась для меня.
Контракту не нужно доверять простому сообщению с частного сервера о том, что всё в порядке. Он может проверить, что требуемый процесс авторизации действительно произошёл.
Важно и время.
Многие инструменты безопасности обнаруживают подозрительные транзакции после того, как они произошли. Они могут отправить оповещение, отметить адрес или сформировать отчёт. Эта информация может быть полезной, но она не предотвращает потерю, как только транзакция уже подтверждена.
Ньютон предназначен для проверки правил перед выполнением.
Для меня это одна из самых сильных частей проекта.
Профилактика обычно ценнее, чем объяснение после того, как ущерб уже нанесён.
Сейчас Ньютон использует язык политик под названием Rego. Я раньше не уделял ему много времени, но базовую идею было легко понять.
Вместо того чтобы писать длинную программу для каждой возможной ситуации, разработчики могут описать условия, которые должны быть истинными до того, как действие будет принято.
Правило может разрешать перевод только тогда, когда сумма остаётся ниже фиксированного лимита. Другое могло бы отклонять платеж, когда адрес получателя находится в списке ограниченных. Торговое правило могло бы разрешать активность только для выбранных активов.
Более строгая политика могла бы приостанавливать транзакции, когда волатильность поднимается слишком сильно.
Такой подход кажется естественным для финансового контроля, потому что компании и организации уже думают в терминах условий.
Бизнес может разрешить сотрудникам тратить до определённой суммы без дополнительного одобрения. Казначейство может разрешать платежи только одобренным вендорам. Торговый стол может устанавливать лимиты на размер позиции, проскальзывание или дневные убытки.
Ньютон пытается выразить такие типы правил в форме, которую можно проверить до того, как onchain-действие будет завершено.
Мне также нравится разделение между приложением и политикой.
Торговая система может сосредоточиться на выборе и размещении сделок. Политика может сосредоточиться на определении того, какие сделки считаются приемлемыми.
Платёжное приложение может сосредоточиться на отправке средств. Политика может определить, сколько можно отправить, куда это может уйти и какие условия должны быть соблюдены.
Так правила легче проверять и обновлять.
Но при этом есть очевидный риск.
Политика полезна ровно настолько, насколько полезен человек, который её пишет.
Ньютон может корректно применить правило, но это не означает, что само правило разумно. Плохо спроектированная политика могла бы блокировать легитимных пользователей или одобрить что-то опасное. Правило, которое работает в нормальных рыночных условиях, может вести себя плохо во время экстремального события.
Это означает, что разработчики всё равно несут на себе много ответственности.
Политики нужно тестировать, пересматривать, мониторить и обновлять со временем.
Изучая со стороны разработчика, я нашёл симуляцию как одну из самых полезных функций. Разработчики могут отправить пример транзакции и увидеть, одобрила бы её политика или отклонила, не используя реальные средства.
Это важно, потому что системы авторизации могут провалиться в двух направлениях.
Они могут быть слишком слабыми и допускать опасную активность.
Но они также могут быть слишком строгими и мешать обычным пользователям завершать обычные транзакции.
Тестирование даёт разработчикам возможность найти обе проблемы до того, как будут задействованы реальные деньги.
Разработческий процесс также прояснил для меня кое-что ещё. Сейчас Ньютон не выглядит как простой потребительский апп. Похоже, это в первую очередь инфраструктура для разработчиков, протоколов, провайдеров платежей, казначейств и организаций.
Обычный пользователь может вообще никогда не взаимодействовать с Ньютон напрямую.
Вместо этого он мог бы работать «за кошельком», через платёжный сервис, торговую платформу или смарт-контракт. Пользователь в основном увидит результат, когда транзакция будет одобрена, ограничена или заблокирована.
Ньютон использует сеть операторов, подключенную к EigenLayer. Эти операторы оценивают политики и помогают формировать аттестации, которые используются смарт-контрактами.
Цель — снизить зависимость от одного частного сервера авторизации.
Если бы одна компания контролировала каждое одобрение, пользователям пришлось бы доверять этой компании, что она останется безопасной, доступной и честной. Скомпрометированный сервер мог бы одобрять вредоносные транзакции, отклонять легитимные или полностью перестать работать.
Сеть операторов может снизить этот риск.
Но я бы не стал предполагать, что система сильно децентрализована только потому, что в ней задействовано несколько операторов.
Я всё равно хотел бы понимать, сколько операторов активны, кто их контролирует, насколько они независимы и что происходит, когда они не согласны. Я бы также хотел понять, как новые операторы присоединяются и становится ли участие более открытым со временем.
Похоже, что структура операторов Ньютон на этом этапе остаётся permissioned (с ограниченным доступом).
Это может быть разумно, пока сеть развивается, но это также означает, что проект должен быть чётким в отношении уровня децентрализации, который он сейчас предоставляет.
Ещё одна важная часть Ньютон — это использование внешних данных.
Некоторые политики могут работать целиком с onchain-информацией. Другие нуждаются в данных из внешних источников.
Политика платежей может нуждаться в актуальном результате по санкциям. Кредитная политика может нуждаться в рыночных ценах. Бизнес может захотеть проверить статус идентичности. Эмитент стейблкоина может нуждаться в информации о юрисдикции или комплаенсе.
Ньютон позволяет политикам использовать оракулы данных для этих проверок.
Это делает систему более гибкой, но при этом создаёт ещё один источник риска.
Операторы могут корректно прийти к результату, даже если сами исходные данные неверны или устарели.
Криптография может доказать, что решение было произведено и подписано. Она не может гарантировать, что внешний провайдер предоставил точную информацию.
Это не только проблема Ньютон. Это затрагивает почти каждую систему в блокчейне, которая зависит от данных из реального мира.
Для сильной реализации может понадобиться несколько провайдеров, чёткие времена истечения, правила на случай отказа (fallback) и аккуратная обработка, когда информация становится недоступной.
Правильный ответ может также зависеть от типа транзакции.
Небольшой платёж может быть задержан и повторён.
Крупный перевод казначейства может потребовать отклонения, пока не появятся надёжные данные.
Эти решения должны быть встроены в политику, а не оставлены на волю случая.
Чем больше я исследовал Ньютон, тем больше замечал, что его публичная идентичность менялась со временем.
Ранние описания сильно фокусировались на автоматизированных агентах, безопасной rollup-технологии, программируемых аккаунтах, регистрации модели, торговых инструментах и глобальном маркетплейсе.
Проект казался строящим широкую среду, в которой разработчики смогут предлагать автоматизированные финансовые сервисы, а пользователи — давать этим сервисам контролируемый доступ к своим средствам.
Текущее направление кажется более узким.
Также ощущается, что всё стало более сфокусированным.
Сейчас Ньютон в основном представляет себя как слой авторизации для onchain-транзакций. Его более новый материал уделяет больше внимания политикам, операторам, аттестациям, проверкам комплаенса, контролю платежей и ограничениям на выполнение в рантайме.
Я не вижу старые и новые версии как полностью отдельные.
Автоматизированным торговым агентам всё равно нужны разрешения.
Финансовым сервисам всё ещё нужны лимиты расходов.
Маркетплейс автоматизированных инструментов всё равно нуждается в способе остановить эти инструменты, если они начнут делать больше, чем пользователи намеревались.
Слой авторизации мог бы поддерживать более раннее видение.
Однако некоторые части исходного плана сейчас менее заметны. Похоже, что маркетплейс модели и более широкая экономика агентов не являются такими центральными для текущего опыта разработчика, как система политик.
Я думаю, что сужение фокуса может быть разумным шагом.
Создание агентов, торговых систем, маркетплейса, безопасного rollup, токен-инцентивов и слоя авторизации одновременно было бы крайне сложно.
Задача — коммуникация.
Тот, кто исследует Ньютон, всё ещё может найти более старый материал, описывающий его в основном как проект по автоматизированной торговле или маркетплейсу моделей. Более новая документация может представлять другое.
Команде нужно объяснить, какие части активны, какие изменились и какие остаются идеями на более долгий срок.
Автоматизированная торговля всё ещё даёт полезный пример того, как Ньютон может быть использован.
Допустим, я разрешаю сервису ребалансировать часть моего портфеля.
Я мог бы разрешить ему торговать только выбранными активами. Я могу ограничить, сколько можно разместить в одной позиции. Я могу отклонять сделки с высоким проскальзыванием. Я могу блокировать взаимодействия с контрактами, которые не были одобрены.
Я также могу потребовать, чтобы сервис останавливался, когда дневные убытки достигают фиксированной суммы.
Торговый сервис всё равно выбирал бы сделки.
Ньютон определял бы вокруг них ограничения.
Это различие важно.
Ньютон не обязательно решает, какое именно финансовое действие следует предпринять. Он проверяет, что предлагаемое действие остаётся в рамках правил.
Платежи могут быть ещё более сильным вариантом использования.
Платёжной компании могут понадобиться лимиты переводов, проверки на мошенничество, скрининг по санкциям, ограничения для мерчантов или региональные контроли. Эти проверки часто управляются через частные системы, которые пользователи не могут просмотреть.
Ньютон мог бы позволить часть этих правил записывать как политики и связывать напрямую со смарт-контрактом.
Бизнес может разрешать небольшие выплаты поставщикам автоматически, но требовать более сильного одобрения для крупных переводов.
Сервис платежей может отклонять транзакции, включающие адреса из ограниченных.
Эмитент стейблкоина может применять выбранные проверки перед переводом, минтом или редемпшном.
Это не убирает юридическую или операционную сложность финансового комплаенса. Оно лишь создаёт более понятный способ связать эти правила с активностью onchain.
Управление казначейством — ещё одна сфера, где я вижу практическую ценность.
Многие криптоорганизации используют кошельки с мультиподписью. Мультисиги повышают безопасность за счёт требования нескольких одобрений, но они также могут замедлять рутинную активность.
Система политик может позволять небольшие регулярные платежи в рамках утверждённого бюджета, требуя дополнительного одобрения для более крупных переводов.
Он мог бы блокировать платежи на незнакомые адреса.
Это могло бы ограничивать определённые действия только конкретными токенами и контрактами.
Это может дать организациям больше гибкости, не отдавая одному человеку или автоматизированному сервису полный контроль над казначейскими средствами.
Та же идея может применяться к сотрудникам, участникам и поставщикам услуг.
Участнику может быть разрешено оплачивать одобренных вендоров, но не перемещать резервы. Менеджеру портфеля может быть разрешено ребалансировать активы, но не выводить их. Сервису может быть разрешено взаимодействовать с одним контрактом, при этом он будет заблокирован для всего остального.
Такие типы ограниченных разрешений уже существуют в традиционных финансовых системах.
Ньютон пытается привнести похожие контроли в onchain-аккаунты.
Кредитные платформы и протоколы ликвидности также могут использовать систему как уровень безопасности.
Кредитный протокол может захотеть приостанавливать некоторые действия, когда цена оракула слишком сильно отклоняется от других рыночных цен. Пул ликвидности может отклонять операции, когда резервы падают ниже безопасного уровня. Протокол может блокировать действия, которые создают нездоровые условия залога (collateral).
Эти правила работают как автоматические предохранители (circuit breakers).
Их может не потребоваться во время спокойных периодов, но они могут стать важными, когда рынки резко меняются.
Сложность в том, чтобы задать их правильно.
Правило, которое активируется слишком быстро, может заморозить здоровую систему.
Правило, которое реагирует слишком медленно, может не предотвратить ущерб.
Снова: Ньютон может принудительно выполнить решение, но люди, разрабатывающие политику, всё равно должны выбирать правильные условия.
Токен NEWT — это ещё одна часть проекта, которую я внимательно изучал.
NEWT стартовал с максимальным предложением в один миллиард токенов. Планируемые применения включали стейкинг, безопасность сети, комиссии, governance и платежи, связанные с более ранней идеей маркетплейса.
Стейкинг всё ещё имеет смысл в рамках текущей архитектуры. Операторы, оценивающие политики и производящие аттестации, нуждаются в стимулах и последствиях.
Со временем управление (governance) тоже может стать важнее, особенно если сообщество получит большее влияние на обновления, правила операторов, решения казначейства и настройки сети.
Некоторые другие применения токенов сегодня менее понятны.
Ранее ожидалось, что прошлый маркетплейс будет использовать NEWT для регистрации и выплат роялти. Поскольку сейчас этот маркетплейс не является самой заметной частью продукта, я бы хотел получить обновлённые доказательства, прежде чем считать эту утилиту активной.
Я также уделил внимание вестингу токенов.
Только часть общего предложения находилась в обращении на момент запуска. Остальные распределения были зарезервированы для участников, бэкеров, фондов экосистемы, фонда, сетевых наград и связанных целей.
Эти токены выпускаются со временем.
Это означает, что циркулирующее предложение может продолжать расти.
Всем, кто изучает NEWT, стоит смотреть дальше его текущей цены. Выпуски токенов, движения казначейства, спрос сети, участие в стейкинге и реальное использование протокола — всё это может иметь значение.
Я также заметил, что публичные платформы не всегда показывают одно и то же циркулирующее предложение. Разные сервисы могут использовать разные определения для токенов, которые разблокированы, вестятся, находятся в обращении, удерживаются казначействами или активно торгуются.
Поэтому я бы сравнивал несколько источников вместо того, чтобы доверять одному числу.
Более важно то, что я бы сохранил токен отдельно от лежащей в основе технологии.
Ньютон мог бы построить полезную инфраструктуру, но токен при этом может работать плохо.
Этот токен может привлечь внимание рынка ещё до того, как протокол получит реальное внедрение.
Эти истории связаны, но они не идентичны.
Самая сильная часть Ньютон, с моей точки зрения, — это его фокус на остановке вредных действий до выполнения.
Криптобезопасность часто слишком сильно зависит от того, что пользователи принимают идеальные решения. Как только транзакция подписана и подтверждена, может не быть реалистичного способа отменить её.
Ньютон добавляет ещё одну проверку между разрешением и выполнением.
Транзакция может быть технически валидной, но всё равно будет отклонена, потому что нарушает лимит на расходы, использует не одобренный контракт, не проходит правило комплаенса или пересекает порог риска.
Мне также нравится идея сделать политики видимыми и пригодными для тестирования.
Когда правила существуют только внутри частного сервиса, пользователи могут не знать, как принимаются решения. Записанная политика может быть проверена, протестирована, обновлена и аудирована.
Гибкость тоже полезна.
Та же структура может поддерживать контролли казначейства, правила для стейблкоинов, торговые ограничения, лимиты платежей, требования к идентичности и защитные меры в кредитовании (lending safeguards).
При этом я бы не игнорировал проблемы.
Система технически сложна. Разработчикам нужно понимать смарт-контракты, дизайн политик, операторов, аттестации, внешние данные и обработку отказов.
Слабая интеграция может создать видимость безопасности, не обеспечивая при этом реальной защиты.
Сеть операторов всё ещё должна демонстрировать более широкую независимость. Внешние провайдеры данных остаются возможными точками отказа. Политики могут содержать ошибки или стать устаревшими.
Проверки авторизации также должны быть достаточно быстрыми, чтобы они не делали приложения раздражающе трудными в использовании.
Меняющаяся идентичность проекта — ещё одна сложность.
Ньютону нужно ясно объяснить свой текущий фокус, чтобы люди не продолжали сравнивать более старое видение маркетплейса с новым продуктом авторизации.
Внедрение станет финальным тестом.
Инфраструктура становится ценной, когда реальные приложения её используют. Документация и технический дизайн полезны, но Ньютону понадобятся активные операторы, надёжные политики, интеграции для разработчиков и измеримая активность транзакций.
Я начал изучать Ньютон, потому что ожидал найти проект, в основном сфокусированный на автоматизированной торговле и финансовых агентах.
В итоге я увидел это иначе.
Теперь я думаю о Ньютон как о системе для ограничения полномочий приложений, кошельков и автоматизированных сервисов.
Это может звучать менее драматично, чем всемирный маркетплейс финансовых агентов, но оно решает более непосредственную проблему.
По мере того как программное обеспечение получает всё больше контроля над цифровым а
