Несколько дней назад я поболтал с другом, который занимается on-chain risk control. Одной фразой он поставил меня в тупик.
Он сказал: «Как бы хорошо ты ни делал стратегию, если данные неверные, то вся система по сути серьезно совершает ошибку».
После того как он это сказал, моя первая реакция была: звучит немного преувеличенно, но если подумать, то довольно правдиво.
Веб3-контроль рисков все эти годы постоянно конкурирует: модели, правила, параметры — но почти никто по-настоящему не решает фундаментальную проблему: откуда берутся данные и можно ли им доверять.
Дизайн этой части в Newton Protocol я начал по-настоящему понимать только когда рассмотрел его песочницу.
Это не просто подключить один API или выбрать «более надежный» источник данных — наоборот: по умолчанию считается, что все внешние данные недостоверны.
Эта идея немного дерзкая.
На стороне узла она прямо запускает код поставщика данных, а процесс получения внешних данных загоняет в песочницу для выполнения. Каждый узел сам ходит за данными, сам генерирует подписи, а затем выдает результаты для агрегации.
Суть не в том, «кто прав», а в том, что «каждый запускает у себя независимо».
Если источник данных падает или возвращает аномальные значения, это не будет так напрямую влиять на всю систему, как в традиционных системах, потому что результаты разных узлов заметно разойдутся; в конце все сойдется статистическим образом.
Если сказать прямо, это не «защита от ошибок», а такое устройство, чтобы ошибка не могла быть спрятана.
Мой друг после этого сказал одну очень точную фразу: «Разве это не значит разломать котелок на части, и пусть каждый понесет свою маленькую долю?»
Да, есть такое ощущение, но ключ в том, что добавлены три ограничения: изоляция сети, ограничения ресурсов и приватный доступ к пути.
Если перевести, то смысл такой: ты можешь зайти внутрь, но ты не можешь разгуливать как вздумается, и нельзя подсматривать чужие данные.
В этой архитектуре роль $NEWT тоже довольно прямая: это не про токен в формате «рассказываем историю».
Она берет оплату за вычисления, пропускную способность и количество запросов: кто пользуется больше — тот платит больше; по сути это «топливо для вычислительного слоя».
Эта часть на самом деле довольно важна, потому что проблема многих проектов в том, что: система есть, а реального расхода — нет.
Newton как минимум на уровне дизайна прописал «стоимость использования» в протоколе.
Конечно, проблемы тоже есть.
Например, песочница может гарантировать чистую среду выполнения, но она не может гарантировать, что «сам источник данных не несет предвзятость». Если загрязнена логика на верхнем уровне, просто она попадет в систему другим способом.
Еще одна реальная проблема: такая модель многозвенного повторного выполнения по сути покупает доверие ресурсами, поэтому стоимость точно не будет низкой.
Потом я заодно посмотрел тренды ончейн-данных.
Социальная сторона, по сути, остывает: обсуждений стало меньше, чем на ранних этапах, но интересно вот что:
Число кроссчейн-вызовов растет, активность адресов, связанных с MPC, увеличивается, а комиссии на уровне протокола постепенно тоже идут вверх.
Это немного похоже на типичное состояние инфраструктурного проекта: снаружи не шумно, зато внутри работы становится больше.
Такую структуру я в первую очередь подумал не про новый проект, а про ранние оракулы или тот пласт вещей, что был вокруг кроссчейн-мостов.
В те годы, когда Chainlink только поднимался, в твиттере тоже никого не было видно спорящих — просто интеграций в протоколе становилось все больше.
Поэтому теперь, глядя на Newton, я скорее готов воспринимать ее как эксперимент по созданию «доверенного вычислительного слоя», а не просто как сюжетный проект в стиле DeFi или AI.
Она решает не вопрос «насколько данные точны», а вопрос «как сделать так, чтобы данные на блокчейне нельзя было тихо изменить».
Если этому направлению удастся пройти, то его важность может оказаться больше, чем краткосрочная цена.
Но если это так и не заработает, то это будет просто еще один сложный системный проект.
В конце концов, я снова повторю: по таким проектам не спешите делать выводы — сначала смотрите на объем вызовов и на то, как они реально используются.