Написание смарт-контрактов — это только половина задачи. Проектирование того, как они принимают решения, становится столь же важным.
Я ожидал, что Ньютон заставит меня думать о более умных смарт-контрактах. Вместо этого он заставил меня думать о системах разрешений. Скрытый вызов заключается не в написании кода, а в определении условий, при которых этот код должен выполняться. Операционная система не просто исполняет каждое приложение, которое запрашивает ресурсы. Она проверяет разрешения, подтверждает личности, применяет политики и решает, что должно быть разрешено, прежде чем выполнять код. Моя тезис заключается в том, что DeFi приближается к такому же архитектурному переходу. Следующее конкурентное преимущество не будет получено за счёт написания более сложных смарт-контрактов. Оно будет получено за счёт разделения выполнения и авторизации.
Сначала я предположил, что разработка инструментов будет продолжаться благодаря более совершенным виртуальным машинам, более дешёвому исполнению и более выразительным языкам программирования. Углубившись, я понял: эти улучшения решают вопросы вычислений, а не принятия решений. Главный узкий момент — то, что я называю Decision Debt (долгом решений): каждый протокол снова и снова перестраивает собственную логику авторизации для лимитов расходов, мультиподписных одобрений, санкционного скрининга, разрешений кошелька и риск-менеджмента. Код работает, но слой принятия решений остаётся фрагментированным.
Эта фрагментация создаёт стимулы, которые большинство разработчиков недооценивает. Каждый протокол закладывает чуть разные предположения по безопасности, правила управления и проверки политики. Каждая проверка (аудит) становится дороже, потому что логика авторизации по-разному встраивается в приложения. Любое обновление несёт риск появления несогласованного поведения. Скрытая стоимость — не в исполнении, а в поддержании тысяч независимых policy-движков, которые пытаются решать почти одинаковые задачи координации.
SDK Vault от Newton предлагает иную архитектуру. Вместо того чтобы встраивать правила авторизации напрямую в каждый смарт-контракт, разработчики задают программируемые политики, которые оцениваются внешне до исполнения. Смарт-контракт остаётся ответственным за расчёт, а авторизация становится выделённым инфраструктурным слоем. Это похоже на то, как облачная инфраструктура отделила управление идентификацией от логики приложения через сервисы вроде IAM, вместо того чтобы заставлять каждое приложение реализовывать собственный фреймворк аутентификации.
Техническое следствие оказывается более значительным, чем сначала кажется. Хранилище (vault) может требовать лимиты на транзакции, назначенных подписантов, проверок санкций, временных задержек, подтверждения аппаратным кошельком или пользовательских политик организации до выполнения. Сеть авторизации Newton оценивает эти условия и формирует криптографический результат авторизации, который контракты могут проверить. Вместо замены смарт-контрактов это снижает объём policy-специфичного кода, который разработчикам приходится снова и снова поддерживать.
Сценарии реального применения делают это различие понятнее. Казначейство DAO может требовать разные пороги одобрения в зависимости от размера транзакции. Эмитент стейблкоина может нуждаться в санкционном скрининге перед переводами. Институциональный провайдер кастоди может применять географические ограничения и окна торговли. Семейный офис способен ограничивать ежедневные снятия средств, при этом требуя несколько одобрений выше определённых порогов. Сегодня эти правила часто пересобираются независимо друг от друга. Newton пытается сделать их переиспользуемой инфраструктурой.
Этот компромисс заслуживает столь же пристального внимания. Вынесение авторизации наружу добавляет ещё одну зависимость. Если инфраструктура политики станет критичной, управление изменениями политик, стимулы валидаторов и доступность окажутся не менее важными, чем сама безопасность смарт-контрактов. Кроме того, лучшая модульность может создать новые риски координации, если правила авторизации будут развиваться иначе, чем логика приложения.
По сравнению с альтернативами, это представляет собой другую философию. Традиционные библиотеки контроля доступа по-прежнему размещают авторизацию внутри прикладного кода. Мультиподписные кошельки решают задачу коллективного одобрения, но не динамическую оценку политики. Провайдеры комплаенса часто работают полностью внечейн, заставляя учреждения доверять централизованному принуждению. Newton пытается создать проверяемый слой авторизации, где сами решения политики становятся наблюдаемыми и криптографически подтверждаемыми до расчёта (settlement).
Больше всего меня интересует поведенческий сдвиг, который эта архитектура поощряет. Разработчики перестают думать исключительно о написании исполняемого кода и начинают проектировать системы принятия решений. Команды по безопасности переходят от реакции на эксплойты к формированию превентивных политик. Учреждения получают программируемое управление, не переписывая ключевые приложения. Ответственность смещается с «Может ли этот контракт выполнить операцию?» на «При каких условиях он должен выполнить операцию?»
Если эта модель получит распространение, DeFi может тихо перейти из мира, где каждый протокол придумывает собственные предположения по безопасности. Открытый вопрос в том, примут ли разработчики ещё один инфраструктурный слой в обмен на меньшую сложность. Будущее может принадлежать не самым умным смарт-контрактам, а системам, которые принимают самые умные решения по авторизации ещё до того, как выполнится хотя бы одна строка кода контракта.