Я начал уделять более пристальное внимание протоколу Newton, когда заметил, что большая часть трения внутри системы возникала не во время выполнения. Оно появлялось еще до того, как выполнение вообще разрешали. Звучит очевидно, пока вы не проведете время, наблюдая, как запросы проходят через протокол, и не поймете, что сложный вопрос больше не в том, можно ли выполнить действие. Сложный вопрос — следует ли выполнять его вообще.
Протокол Newton снова возвращается к мысли о том, что авторизация становится базовой сущностью, а не функцией. После того как я потратил время на изучение того, как система обрабатывает разрешения, делегирование и права на выполнение, я думаю, что понимаю, почему.
Блокчейн-транзакция уже доказывает, что что-то произошло. Но естественным образом она не доказывает, имел ли исполнитель соответствующие полномочия для начала этого действия при изменяющемся наборе условий. Эта разница кажется небольшой, пока автономные системы не начнут принимать решения за пользователей.
Одна формулировка постоянно возвращалась ко мне, пока я обдумывал дизайн Newton:
Выполнение подтверждает действие. Авторизация подтверждает намерение.
Внутри протокола Newton это различие порождает операционные последствия повсюду.
Простой пример — делегированное выполнение. Представьте, что ИИ‑агент управляет кошельком с правом ребалансировать позиции только в заранее заданных пределах. Сложная задача — не разместить сделку. Современная инфраструктура уже умеет это делать. Сложная задача — не дать агенту постепенно накапливать разрешения, которых у него вообще не должно было быть.
В традиционном рабочем процессе проверки разрешений часто превращаются в разовое событие: пользователь один раз подписывает, и система предполагает, что будущие действия останутся приемлемыми. Newton, похоже, рассматривает авторизацию как то, что должно выдерживать непрерывную верификацию, а не как единый контрольный пункт.
Это добавляет трения.
Больше проверок — больше задержек. Больше валидации означает больше путей, по которым запросы могут задерживаться или отклоняться.
Но эти трения ложатся на другой уровень, чем ожидает большинство людей.
Вместо того чтобы заставлять пользователей вручную проверять каждое действие, протокол пытается «впитать» эту нагрузку в сам процесс авторизации. Пользователь позже сталкивается с меньшим числом экстренных решений, потому что больше ограничений оценивается заранее.
Я мысленно проверил это на другом сценарии.
Предположим, что автономный агент получает десять возможностей выполнить действие в коротком окне рынка. Восемь соответствуют делегированной политике. Две превышают допустимый порог риска.
Легкая система выполняет все десять и задает вопросы потом.
Система с приоритетом авторизации блокирует двух участников еще до того, как выполнение становится возможным.
Цена очевидна. Некоторые возможности исчезают.
Польза сложнее заметить, потому что ничего не происходит: нет эксплойта. Нет случайного превышения полномочий. Нет неожиданного расширения прав.
Предотвращенные сбои редко попадают в заголовки.
Еще один механический пример появляется, когда цепочки авторизации становятся многоуровневыми. Запрос может потребовать валидации относительно пользовательских прав, прав агента и правил на уровне протокола, прежде чем выполнение будет разрешено.
Три проверки вместо одной на бумаге кажутся неэффективными.
Но при этом режим отказа меняется радикально.
Атакующему больше не нужно взламывать один единственный путь выполнения. Ему нужно удовлетворить одновременно нескольким условиям авторизации. Поверхность атаки смещается от генерации транзакций к доказуемости легитимности авторизации — это во многих случаях значительно более сложная задача.
При этом я не до конца уверен, что каждый слой авторизации действительно создает чистую ценность.
Здесь есть реальный компромисс.
Когда авторизация становится инфраструктурой, механизм контроля может незаметно исчезнуть из поля зрения. Системы начинают отдавать предпочтение тем исполнителям, которые лучше других понимают структуры разрешений. Открытое участие остается технически доступным, но на практике некоторые пользователи получают преимущества просто потому, что знают, как эффективнее ориентироваться в среде авторизации.
Думаю, это один из самых интересных тестов для протокола Newton.
Если у двух агентов одинаковые возможности, но разное качество авторизации, кто из них стабильно выигрывает?
Если скорость выполнения вырастает на 50%, но точность авторизации падает на 5%, система на самом деле становится лучше?
Если пользователь делегирует полномочия на тридцать дней вместо тридцати минут, где именно накапливается риск?
Эти вопросы для меня важнее, чем метрики пропускной способности транзакций.
Причина в том, что авторизация, похоже, переходит от функции безопасности к функции распределения ресурсов.
Кто получает доступ.
Кому достается приоритет.
Кому делегируются полномочия.
Кто может действовать в условиях неопределенности.
Эти решения все чаще формируют исходы еще до того, как выполнение даже начнется.
И именно здесь токен начинает обретать больше смысла.
Сначала я рассматривал токен через привычную призму участия и стимулов. Но после того как я присмотрелся к траекториям авторизации, требованиям к стейкингу и структурам ответственности, токен стал казаться менее похожим на экономический аксессуар и больше — на механизм, который привязывает последствия к делегированным полномочиям.
Без последствий авторизация становится дешевой.
Когда авторизация становится дешевой, за ней следует разрастание прав.
Когда происходит разрастание полномочий, границы доверия ослабевают.
Эта последовательность выглядит простой, но в итоге с ней сталкиваются многие системы.
Моя умеренная предвзятость в том, что, вероятно, я ценю ограничительную авторизацию больше, чем средний пользователь. Я видел достаточно систем, ставших хрупкими из‑за того, что разрешения расширялись быстрее, чем осуществлялся надзор. Другой человек мог бы разумно утверждать, что чрезмерные контролы авторизации создают ненужную сложность и снижают экспериментирование.
Возможно, они правы.
Что удерживает меня в протоколе Newton, так это то, что он рассматривает авторизацию как активную вычислительную задачу, а не как статический список разрешений. Протокол кажется менее заинтересованным в том, чтобы доказывать факт совершения действий, и больше — в том, чтобы доказывать, что действия оставались в допустимых границах полномочий ровно в тот момент, когда они были совершены.
Звучит тонко.
На практике это меняет то, где живет доверие.
И как только смещается доверие, остальная архитектура обычно начинает следовать за ним — хотел того систему или нет.