@NewtonProtocol Я поймал себя на мысли о том, как легко полезное разрешение может превратиться во что-то большее, чем пользователь собирался дать.
Не потому, что пользователь намеревался передать контроль.
Поскольку большинство криптосистем заставляют делегирование ощущаться как небольшое одобрение, даже когда это одобрение может впоследствии определять, как будут перемещаться средства.
Вот где начинается проблема для меня. Пользователь может захотеть приложение, которое выполняет повторяющееся действие, агента, который реагирует на меняющиеся условия, или менеджера хранилища, который следует мандату без того, чтобы каждый раз запрашивать ручное одобрение. Удобство понятно. Никто не хочет бесконечно подтверждать каждое мелкое действие.
Но как только другая система может действовать от имени пользователя, вопрос меняется.
Это больше не только «у кого есть доступ?»
Это превращается в вопрос: «что именно разрешено делать с этим доступом?»
Именно вокруг этой границы, похоже, и работает протокол Newton. Само по себе не так важно, чтобы была автоматизация. Важнее — контрольная точка перед выполнением. Прежде чем защищённое действие будет завершено, намерение транзакции можно проверить по политике. Операторы оценивают эту политику, возвращают подписанное заверение (attestation), а встроенный смарт-контракт может проверить это доказательство, прежде чем разрешить дальнейшее выполнение.
От этого меняется форма делегирования.
Вместо того чтобы давать системе широкие полномочия и надеяться, что она будет вести себя правильно, разрешение можно привязать к правилу. Политика Rego может проверять намерение транзакции, настроенные параметры и данные времени выполнения из оракулов PolicyData. Это означает, что решение может зависеть от условий, лимитов, внешнего контекста или требований, специфичных для приложения, а не только от наличия действительной подписи.
Вот почему название для меня важно.
Делегирование само по себе не является автоматически опасным.
Неопределённое делегирование — это.
Одобрение кошельком или автоматизированное разрешение может выглядеть безобидно, когда пользователь впервые с этим соглашается. Реальный риск часто проявляется позже, когда система начинает действовать за пределами ожиданий пользователя, или когда исходные условия больше не применимы. В криптосфере люди часто предоставляют доступ вначале, а истинную границу понимают только после того, как уже что-то выполнилось.
Ньютон пытается сдвинуть эту границу раньше.
Но это не убирает сложную часть.
Подписанное заверение (attestation) может доказать, что политика была соблюдена для конкретного действия. Но оно не доказывает, что сама политика была разумной. Правило всё равно кто-то определяет. Лимиты всё равно кто-то задаёт. Всё равно кто-то решает, какой источник данных важен, и что должно происходить, когда данные отсутствуют, задерживаются или оказываются неверными.
Вот в чём напряжение (тема спора).
Сильная политика может удерживать делегированные системы в чётко заданном диапазоне работы. Слабая политика может заставить то же делегирование выглядеть безопаснее, чем оно есть на самом деле. Путь принуждения может быть чище, но вынесение суждения, заложенное в правило, всё равно имеет значение.
Поэтому я не вижу Ньютона как простую историю про автоматизацию.
Более серьёзный вопрос в том, могут ли приложения, агенты и сейфы действовать от имени пользователей, не превращая делегированный доступ в слепое доверие.
Это тонкая грань.
Делегирование полезно, когда граница ясна.
Это становится уступкой (surrender), когда система может действовать без неё.
