@NewtonProtocol Я возвращаюсь к одной идее, которая проходит через всю архитектуру Newton. Авторизация происходит до выполнения, а не после. Сначала это звучит как улучшение безопасности. Но чем больше я об этом думал, тем меньше я верю, что это и есть реальный аргумент, который приводит протокол. Я думаю, что он пытается изменить нечто куда более фундаментальное: не то, как отслеживаются транзакции, а то, где вообще существует ответственность.
Большинство блокчейн-приложений по-прежнему рассматривают авторизацию как нечто, принадлежащее отдельным продуктам. Каждая команда пишет свою собственную логику прав, свои правила выполнения и свои собственные исключения. Реализация меняется от приложения к приложению, но базовый вопрос почти никогда. Кто должен быть уполномочен выполнять это действие, при каких условиях и в соответствии с какой политикой? Архитектура Newton начинается с другого предположения. Вместо того чтобы просить каждое приложение отвечать на эти вопросы независимо, она спрашивает, не должна ли сама авторизация стать переиспользуемой инфраструктурой.
Это убедительная идея, но, на мой взгляд, в ней есть скрытое допущение. Общая инфраструктура становится ценной только тогда, когда независимые разработчики решают, что решать одну и ту же задачу отдельно стало дороже, чем решать ее вместе. Это не технический этап. Это решение экосистемы.
Разница важна, потому что предэкзекьюционное разрешение автоматически не начинает иметь значение просто потому, что оно работает. Оно становится важным, когда приложения начинают проектировать, исходя из ожидания, что авторизация уже существует как общий слой. Это две совершенно разные стадии. Одна доказывает, что протокол технически способен. Другая доказывает, что экосистема начала перестраиваться вокруг этой способности.
Конечно, есть и другое прочтение, которому стоит уделить такое же внимание. Разработчики годами встраивали авторизацию непосредственно в свои собственные системы. Эти внутренние решения могут быть не самыми изящными, но они привычны, глубоко протестированы и подогнаны под конкретные продукты. Заменить их — это не только техническая миграция. Это еще и решение доверить еще один слой, который находится под критической логикой приложения. Это гораздо более высокий барьер, чем добавление еще одной библиотеки или SDK для разработчиков.
Вероятно, поэтому я думаю, что главная задача Ньютона — не убедить людей, что авторизация важна. Большинство серьезных разработчиков уже это понимают. Труднее убедить их в том, что авторизация создает больше ценности, когда становится общим инфраструктурным элементом, а не просто конкурентной функцией. История показывает, что общие стандарты редко побеждают потому, что они теоретически лучше. Они побеждают потому, что со временем поддерживать отдельные системы становится тихо менее рациональным выбором.
Это меняет то, как я интерпретирую дорожную карту Ньютона. Новая инфраструктура, расширенные возможности политики и дополнительные интеграции, конечно, признаки прогресса, но это не конечная цель. Они важны только в той мере, в какой постепенно меняют поведение разработчиков. Дорожная карта измеряет то, что протокол способен предоставить. Экосистема измеряет то, что люди решают перестать создавать для себя. Это не один и тот же сигнал, и я подозреваю, что второй будет всегда значить больше, чем первый.
Я также думаю, что это объясняет, почему инфраструктурные проекты в первые годы часто сбивают с толку рынок. Видимые метрики легко измерить. Невидимые решения — нет. Мы можем считать транзакции, кошельки и цену токена каждый день. Но мы не можем так же легко измерить количество инженерных команд, которые тихо пришли к выводу, что пересобирать еще одну систему авторизации больше не имеет смысла. И все же эти невидимые решения в конечном итоге могут сформировать будущее протокола куда сильнее, чем видимые.
Я не знаю, станет ли Ньютон в итоге тем слоем, который разработчики естественно ожидают видеть еще до того, как напишут хоть одно собственное правило авторизации. Протокол все равно должен доказать, что общая авторизация дает достаточно долгосрочной ценности, чтобы оправдать изменение глубоко укоренившихся привычек разработки. Это строгий стандарт, и нет гарантии, что экосистема до него дойдет. Но я также думаю, что это самый важный вопрос. Рынки обычно вознаграждают инфраструктуру после того, как она становится видимой благодаря внедрению. Самый интересный момент может наступить гораздо раньше — когда разработчики тихо перестают спрашивать, как самим построить авторизацию, и начинают спрашивать, зачем им вообще это было нужно.
