Haseeb Ghiffari

Я постоянно видел слово «маркетплейс», прикрепленное к Newton's Model Registry, и некоторое время воспринимал это буквально: конкурирующие операторы, система репутации, пользователи, которые просматривают библиотеку агентов и выбирают того, который подходит под их стратегию. Затем я стал смотреть, что на самом деле указано в этом реестре сегодня, и картина оказалась куда меньше, чем язык вокруг него.
Прямо сейчас реестр работает на одном действующем агенте — Recurring Buy Agent (агенте регулярных покупок). Дорожная карта при этом явно описывает переход к компонуемой экосистеме из нескольких агентов как шаг, который еще впереди, а не как уже реализованную вещь. Цель — развить компонуемую экосистему проверяемых агентов, двигаясь дальше от первоначального единственного агента — Recurring Buy Agent. Между тем общее описание маркетплейса, которое встречается в независимых публикациях, говорит о системе на базе стакана заявок (order book): пользователи подают запросы на автоматизацию с прикрепленными комиссиями, а операторы конкурируют, чтобы выполнять их эффективно и проверяемо.
Протокол работает как маркетплейс на базе стакана заявок: он сопоставляет запросы пользователей на автоматизацию с операторами, которые конкурируют за то, чтобы выполнять задачи эффективно и проверяемо, а валидаторы проверяют доказательства выполнения до того, как финализировать переходы состояний. Это действительно хорошая схема, но это схема, которой нужна «множественность» (плюрализм), чтобы работать так, как описано. Конкуренция и репутация — понятия относительные. Они имеют смысл только тогда, когда есть больше одного варианта, с которым можно конкурировать, или с кем/чем можно выстраивать репутацию.

Забавная история случилась на прошлой неделе: я восстанавливал рабочий ноутбук, который постоянно падал на secure boot после обновления BIOS — какое-то значение переключилось, и машина отказывалась доверять собственной прошивке, пока я вручную не включил эту настройку обратно. Мне понадобилось двадцать минут гугления, чтобы понять, что вообще означает «measured boot». И, конечно, раз уж моя голова, похоже, больше не умеет нормально разделять контексты, этот крюк сразу вернул меня в документацию Newton Protocol — в частности, в тот раздел, который я всякий раз пропускал, когда пробегал взглядом раньше: слой Oracle Adapter Layer.

Я почти пропустил(а) этот пункт. Он указан как «предстоящий» в дорожной карте самого Newton — легко не заметить среди более громких анонсов про сейфы и оракулы идентичности. Но идея, лежащая в основе Multichain Newton Keystore Rollup, больше, чем его описание: один zkPermissions-роллап, предназначенный для того, чтобы один раз и относительно недорого хранить программируемые разрешения, и чтобы каждая цепочка, подключающаяся к Newton, ссылалась на этот же реестр, а не развертывала и не заново проверяла ту же логику политики отдельно на каждой из них.
Проблема, которую она решает, реальна. Сейчас, если политика должна применяться в Ethereum, Base и там, куда дальше расширится Newton, где-то должна существовать такая логика, она должна вычисляться и за нее должно выполняться оплата на каждой цепочке отдельно. Это избыточные вычисления, избыточный газ и растущая площадь атаки для одной и той же политики, которая незаметно начинает расходиться при развертываниях. Роллап, созданный специально для хранения разрешений, решает эту проблему чисто. Один канонический реестр, доказательства с нулевым разглашением, подтверждающие его состояние; другие цепочки просто сверяются с ним, вместо того чтобы нести всю логику целиком.